2

I am using BigFix in an Enterprise Environment and noticed a recent round of Microsoft patches for 2016 have failed on a small group of assets. I was able to work around this by creating Custom Copy Fixlets, using modified relevancy, however the relevancy that I had to use was not always consistent, even though most of the files were all located in C:\Windows\Sytem32.

For example: MS16-031 - The criteria that my scanning platform is looking for, is based off of the version number for Ntdll.dll. I create a Custom Fixlet with Relevance:

((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) < VersionNumberGoesHere

This worked great, as I had created an BigFix Analysis previously looking for Ntdll.dll using relevancy:

if (exists x64 file "C:\Windows\System32\Ntdll.dll") then ((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) else "Does Not Exist"

I was able to confirm that relevancy for the Custom Fixlet was just about spot on with the Analysis. For some reason, it's not a mirror image of the two, but it's extremely close and the Custom Fixlet list's all the machines that are flagged in the scan results, so I'm happy with it.

The problem arises here: For some files in C:\Windows\System32, I have to use an entirely different syntax to get the correct version number information I'm looking for based off of scan results. That is, I can use the method listed above, but the version information it will give is not even close to what the scanner is looking for. If I were to use the above listed method, assuming the scanner is looking for something like "Version Number 6.1.7600.16385", the results I would see would instead read "1.1.11302.0". It would still be some sort of apparent version numbering, but not at all similar to the type that my scanning platform is referencing.

For example: MS16-027 - To find the file version information for mfds.dll for the analysis I had to use:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder

For the Custom Fixlet, I had to use:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder != VersionNumberGoesHere (OSServicePatch_gdr.LongStringOfNumbers)

I have done a bit of reading on Action Script syntax for BigFix and it seemed like x64 file (command) vs. file (command) can lead to different results based on the pathing for 32-bit systems vs 64-bit systems, however, I thought that would only apply for files located within C:\Program Files and C:\Program Files (x86)? Is that not the case? If so, where is the 64 bit version of System32 located and why are the results between the two so drastically different?

jgstew
  • 86
  • 9
Sawta
  • 345
  • 1
  • 4
  • 13

1 Answers1

1

Just to clarify, this is a question about BigFix relevance, not BigFix ActionScript.

I will say, that although BigFix relevance has a bit of a learning curve and makes the source of the complexity hard to figure out sometimes, the issues you are experiencing have more to do with the complexities of how files can have many different types of version information plus the way Microsoft's WindowsOnWindows redirection works.

The simple reason why file version info can be different depending on where you read it from is just that there are multiple places to put file versions, and they could match exactly, or they could be different. This is up to the creator of the file and how they want to convey the meaning of the version info.

The relevance versions of files "mfds.dll" reads one location, while the relevance values "FileVersion" of version blocks of files "mfds.dll" reads a different location.

See here:

Q: (values "FileVersion" of version blocks of it, (it as string) of versions of it) of files "mfds.dll" of (system folders)
A: 10.0.14342.1000 (rs1_release.160506-1708), 10.0.14342.1000
T: 3.677 ms
I: plural ( string, string )

I don't think the differences you are seeing are due to the differences between file and x64 file, but it is important to understand for many reasons.

For the purposes of this question assume we are talking about a 64bit windows computer, and you should assume this applies to Windows Vista or later, but may also apply to Windows XP 64bit.

Because the BigFix client is a 32bit process, all file reads that would be made to the special x64 bit locations are actually redirected by windows to the 32bit location.

What is the difference between files and x64 files in BigFix relevance? In the case of most files, use of either files and x64 files will actually read the same file. This is because use of x64 files tells BigFix to read the file with WindowsOnWindows(WoW) Redirection disabled, but this redirection only applies to reads to specific paths. One example being Program Files and another being System32, while something like C:\Windows\Temp is not affected by WoW redirection at all, so any file read to C:\Windows\Temp works the same regardless.

  • 32bit location: C:\Program Files (x86)
  • 64bit location: C:\Program Files
  • 32bit location: C:\Windows\SysWOW64
  • 64bit location: C:\Windows\System32
  • 64bit location: C:\Windows\sysnative
    • special fake path that works without disabling redirection

We have Microsoft to thank for the fact that the 64bit system location has 32 in the name, while the 32bit system location has 64 in the name. This is definitely an extremely common source of confusion.

Use this relevance to see that there are actually 2 copies of mfds.dll on the system.

(name of it, size of it) of files "mfds.dll" of (system folders; system x64 folders)

This relevance reads both locations because (system folders; system x64 folders) tells BigFix to read BOTH the C:\Windows\SysWOW64 folder as well as the C:\Windows\System32 folder.

Crazy? Confusing? Just wait, it gets weirder.

Run the following relevance in the fixlet debugger: pathnames of files "mfds.dll" of (system folders; system x64 folders)

Q: pathnames of files "mfds.dll" of (system folders; system x64 folders)
A: C:\WINDOWS\system32\mfds.dll
A: C:\WINDOWS\system32\mfds.dll
T: 1.312 ms
I: plural string

Notice how the pathnames of both files are the same, but these are NOT the same file!!!

This is how WindowsOnWindows Redirection works. It lies to the 32bit process and tells it that it read the file from the C:\Windows\System32 location, even though it read it from C:\Windows\SysWOW64 instead in the case of using the system folders relevance, so then BigFix properly reports the pathname as C:\WINDOWS\system32\mfds.dll. Then in the case of the system x64 folders relevance, BigFix (32bit process) tells Windows it would like to read the location C:\Windows\System32 with redirection disabled, in which case it actually reads the file located at C:\WINDOWS\system32\mfds.dll and properly reports the pathname as such.

I'd like to reiterate, this has nothing to do with BigFix and everything to do with Microsoft's implementation of Windows 64bit with Windows 32bit redirection.

For future BigFix questions, I would strongly recommend the very active Forums: https://forum.bigfix.com/

jgstew
  • 86
  • 9