My primary issue is getting false positives for vulnerabilities based on KB4592440, KB4592449, on a Windows 10 20H2 with the latest patching (KB4592438). This is based on the community feed as of yesterday’s feed (2020-12-15). However, looking into this more deeply, I uncovered two separate issues:
Summary:
- All VTs that are checking for the file version of comctl32.dll are checking for the wrong version (6.* instead of 5.*). As such, these VTs will never report accurately.
Affected:
grep -il ‘comctl32.dll’ /var/lib/openvas/plugins/2020/microsoft/* # total 8
- The latest VTs that check for comctl32.dll have deviated from past VTs, and are using the function ‘version_is_less’ instead of ‘version_in_range’. This:
a) drops the check for different Windows 10 versions which impacts accuracy between versions and
b) combined with the above incorrect version checking will always report as false positive (as of today’s date).
Affected:
/var/lib/openvas/plugins/2020/microsoft/{gb_ms_kb4592449.nasl,gb_ms_kb4592440.nasl}
Incorrect version:
The 6.* versions are SxS only, and it’s the 5.* versions that are placed within system32. This link is the only reference I could find regarding this differences in versions:
https://www.geoffchappell.com/studies/windows/shell/comctl32/history/index.htm
I have validated this against 20+ Windows 10 20H2 systems, all of which only contain the 5.* file version, while a 6.* resides within the WinSxS directory.
So checking against the 6.* file version would always be inaccurate against any comctl32.dll within system32.
Deviation using version_is_less:
The VTs for KB4592440 and KB4592449, compared to other nasl files, use ‘version_is_less’ as opposed to ‘version_in_range’. As the third value in the file version reflects the Windows 10 build number, using version_in_less will not be accurate across different builds (and also explains why only those two VTs are showing as false positives against my computers, as the others are outside the version range).
Examples that contain version_in_range: gb_ms_kb4549949.nasl, gb_ms_kb4551853.nasl, gb_ms_kb4565349.nasl, and others.
Aside:
There is one file that appears to be comparing the product version (10.0.18362.0) instead of the file version: gb_ms_kb4586786.nasl.
I can’t tell which version (file version versus product version) the function ‘fetch_file_version’ is supposed to be getting as it appears to read the structure of the file to determine the version. I would generally assume the functions checks the file version, and that this particular nasl is mistakenly checking for the wrong version type?
Remediation:
All of the nasl files comparing comctl32.dll should be changed to reflect the 5.* file versions. VTs for KB4592440 and KB4592449 should be changed to using ‘version_in_range’.
Side notes:
I don’t see any other VTs that are checking for the 20H2 version of the December Microsoft monthly patch (KB4592438)- perhaps that’s not released yet on the community feed? But if so, why are the 1903/1909 tests available?
It also seems like the actual file being checked varies- I counted 31 different DLLs when checking the gb_ms_kb*.nasl files, including user32.dll, data.dll, others. I haven’t looked too closely at this, so perhaps I’m misunderstanding some logic.
–
Finally, for my own curiosity, what is the reasoning behind the version of a file being checked to validate the system? Hotfixes can be checked using wmi, which I believe has been around since Windows XP. To me, this seems less prone to error than checking indirectly via file version (such as the above instance of using fetch_file_version losing the build.)
I can appreciate that doing a WMI check for Windows 10 version (first connecting via WMI, calling the query, etc.) is more complicated than checking a file, but I’m wondering if there’s some other consideration I’m unaware of.
There appears to be a method for getting hotfixes (“wmi_os_hotfix”), and the actual WMI query works appropriately- but that function doesn’t seem used within any of the nasl files.