Hello Greenbone team,
I am seeing a discrepancy between Greenbone and other vulnerability scanners including both network as well agent based (Nessus and CrowdStrike) regarding CVE-2018-3639 (Speculative Store Bypass) on a Windows Server 2016 asset.
-
Nessus finding:
Plugin: Windows Speculative Execution Configuration Check
Nessus reports that CVE-2018-3639 is present because, while the KB for speculative execution is installed, the mitigation is not actually enabled at the system level. -
CrowdStrike finding:
Also reports CVE-2018-3639 as present on the same host. -
Greenbone finding:
Does not flag CVE-2018-3639.
The NVT that should be applicable for this OS is:
Microsoft Windows Multiple Vulnerabilities (KB4467691)
However, this NVT is not triggered, because a later cumulative KB is present which supersedes KB4467691.
The problem is that while the KB is technically present, the mitigation is not actually active, which leaves the server vulnerable. Windows Server requires both the OS patch and registry configuration/firmware updates to enable Speculative Store Bypass mitigation. Greenbone appears to be checking only KB presence, not the active mitigation state.
Note: I am using Greenbone Enterprise Feeds
Evidence
PowerShell check on the server:
Get-SpeculationControlSettings
Output excerpt:
Hardware support for Speculative Store Bypass: True
Windows OS support for Speculative Store Bypass mitigation: True
Speculative Store Bypass mitigation is enabled system-wide: False
This shows clearly that although the OS has the patch, the mitigation is disabled, which matches Nessus/CrowdStrike results but not that of Greenbone.
Question
-
Is it expected that the Greenbone NVTs (e.g., KB4467691) only check KB presence and not the actual runtime mitigation state?
-
If so, are there plans for Greenbone to implement checks similar to Nessus’s “Windows Speculative Execution Configuration Check,” which inspects system configuration and reports when mitigations are not enabled?
This is important because relying solely on superseding KB checks can result in false negatives for speculative execution vulnerabilities on Windows Server, as in this example.