Hi Everyone -
I've been looking at how the current OVAL repository content deals with scans intended for 64-bit systems, and have encountered several issues. The main concern is that the majority of the content has either A) been written without 64-bit systems in mind, or B) been written to assume a 32-bit scan. Here's a good background example:
On x64, 32-bit Office installs into
C:\Program Files (x86)\Microsoft Office
There are two registry keys that have the program files directory, and two places these keys exist:
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\ProgramFilesDir = "C:\Program Files (x86)"
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86) = "C:\Program Files (x86)"
HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir = "C:\Program Files"
HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86) = "C:\Program Files (x86)"
So for a 32-bit scan, the WOW redirection "Wow6432Node" ensures that a call to either key points to the 32-bit "C:\Program Files (x86)", while the 64-bit version of the keys allow differentiation between the directories.
Currently most Office OVAL definitions look at
HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir = "C:\Program Files"
However, with a 32-bit scan on x64 this gets redirected to
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\ProgramFilesDir = "C:\Program Files (x86)"
And thus should be finding the correct 32-bit install. This should hold true for any 32-bit items in the Program Files directory - basically, as long as it's a 32-bit software, a 32-bit interpreter will most likely be handling it appropriately. That's what WOW is for.
However, by assuming this WOW redirection there are several issues:
1) A 32-bit interpreter cannot examine 64-bit-specific items - take oval:org.mitre.oval:def:5254 (64-bit Vista SP1 is installed) - the check for Service Pack 1 (oval:org.mitre.oval:tst:2843) is the CSDVersion entry in
HKLM\Software\Microsoft\Windows NT\CurrentVersion
Which, when redirected, points to
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion
But since CSDVersion is ONLY in the original key and not present in the redirected key, a 32-bit interpreter will incorrectly return false for the definition on Vista SP1 x64 systems. This is just an example of how pervasive the issue is, since this inventory is using by at least 70 vulnerability definitions.
2) Without modifications to the content, a 64-bit interpreter ends up looking for a 32-bit item in the 64-bit directory - for the Office case above, a 64-bit interpreter will find
HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir = "C:\Program Files"
and will therefore determine that Office is NOT installed since it's really at "C:\Program Files (x86)".
So I believe that most of the existing OVAL repository is tacitly supporting a 32-bit interpretation, but by doing such it limits the accuracy of most 64-bit vulnerability detection, and switching to a 64-bit scan will actually make things worse (as seen in item 2 above) until the content gets updated.
In my mind, the correct solution would probably be to break the assumption of a 32-bit interpreter on 64-bit systems, where necessary update the existing content, and use a 64-bit interpreter,. For instance, office inventory definitions would update along the lines of
If x64 system:
Examine HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)
If x86 system:
Examine HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir
That should then work appropriately for both 32-bit scans on 32-bit systems and 64-bit scans on 64-bit systems.
Has anyone else looked into these issues using existing content on 64-bit systems? Are there any other suggestions or solutions for explicitly defining 64-bit support?
Thanks -
Todd
To unsubscribe, send an email message to
[hidden email] with
SIGNOFF OVAL-DISCUSSION-LIST
in the BODY of the message. If you have difficulties, write to
[hidden email].
