|
|
相比起内核明星PatchGuard，HyperGuard可谓完全没有知名度。直到最近，Mark E .Russinovich才在一本新书里宣告了它的存在，并做了如下描述：On systems that run with virtualization-based security (described earlier in this chapter in the section
“Virtualization-based security”), it is no longer true that attackers with kernel-mode privileges are essentially
running at the same security boundary as a detection/prevention mechanism. In fact, such attackers
would operate at VTL 0, while a mechanism could be implemented in VTL 1. In the Anniversary
Update of Windows 10 (version 1607), such a mechanism does indeed exist, which is appropriately
named HyperGuard. HyperGuard has a few interesting properties that set it apart from PatchGuard:
■ It does not need to rely on obfuscation. The symbol files and function names that implement
HyperGuard are available for anyone to see, and the code is not obfuscated. Complete static
analysis is possible. This is because HyperGuard is a true security boundary.
■ It does not need to operate non-deterministically because this would provide no advantage
due to the preceding property. In fact, by operating deterministically, HyperGuard can crash
the system at the precise time unwanted behavior is detected. This means crash data will contain
clear and actionable data for the administrator (and Microsoft’s analysis teams), such as the
kernel stack, which will show the code that performed the undesirable behavior.
■ Due to the preceding property, it can detect a wider variety of attacks, because the malicious
code does not have the chance to restore a value back to its correct value during a precise time
window, which is an unfortunate side-effect of PatchGuard’s non-determinism.
HyperGuard is also used to extend PatchGuard’s capabilities in certain ways, and to strengthen its
ability to run undetected by attackers trying to disable it. When HyperGuard detects an inconsistency,
it too will crash the system, albeit with a different code: 0x18C (HYPERGUARD_VIOLATION). As before, it
might be valuable to understand, at a generic level, what kind of things HyperGuard will detect, which
you can see in Table 7-24.
On systems with VBS enabled, there is another security-related feature that is worth describing,
which is implemented in the hypervisor itself: Non-Privileged Instruction Execution Prevention (NPIEP).
This mitigation targets specific x64 instructions that can be used to leak the kernel-mode addresses of
the GDT, IDT, and LDT, which are SGDT, SIDT, and SLDT. With NPIEP, these instructions are still allowed
to execute (due to compatibility concerns), but will return a per-processor unique number that is not
actually the kernel address of these structures. This serves as a mitigation against Kernel ASLR (KASLR)
information leaks from local attackers.
Finally, note that there is no way to disable PatchGuard or HyperGuard once they are enabled.
However, because device-driver developers might need to make changes to a running system as part
of debugging, PatchGuard is not enabled when the system boots in debugging mode with an active
remote kernel-debugging connection. Similarly, HyperGuard is disabled if the hypervisor boots in
debugging mode with a remote debugger attached. |
|
发表于 2017-5-17 19:40:42
发表于 2017-5-17 19:44:22
