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
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?