-1

Of course the effects of a compromised kernel mode driver are more disastrous, but are they harder to compromise in the first place?

closed as too broad by Steffen Ullrich, kasperd, AndrolGenhald, schroeder Nov 1 '18 at 15:13

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    This is quite broad and open to interpretation. Can you be a bit more specific? Generally speaking, things like permissions on the filesystem for those drivers will make compromise of userland or kernel-land drivers a non-issue. – h4ckNinja Oct 31 '18 at 23:59
  • 2
    I consider this question as too broad. Essentially you are comparing the compromise of an unspecific kernel driver using unspecific ways in unspecific conditions (physical access, network access, ...) against practically all other possible attacks and ask if it is harder. – Steffen Ullrich Nov 1 '18 at 5:57
1

Two Terms to get familiar with for Windows kernel mode security are Virtualization Based Security and HyperVisor-Enforced Code Integrity.

Virtualization Based Security (VBS) - VBS uses hardware virtualization features to create and isolate a secure region of memory from the normal operating system.

HyperVisor-Enforced Code Integrity (HVIC) - uses VBS to beef up code integrity policy enforcement. Kernel mode code integrity checks all kernel mode drivers and binaries pre-execution, and blocks unsigned drivers or system files from being loaded into system memory. <-- Note this does not protect the integrity of kernel mode data. Modifying key data structures can still compromise system integrity. One example of this is to intercept and drop messages from sysmon (kernel mode) to logging (user mode)

While this HVIC is great for keeping simple unsigned malicious driver attacks out of kernel mode Return Oriented Programming attacks are still quite possible in the Windows kernel mode. This if properly done and combined with a signed but vulnerable driver(there are plenty of these out there) can lead to arbitrary code execution.

The compensating control that everyone should be using is to monitor all driver loads. As a next step, blacklist all known vulnerable drivers which are not required in your environment (and heavily monitor any known vulnerable drivers which are required). Finally, if you have a mature environment, white-list only the drivers you need and sleep a bit easier.

  • Basically, anything running in supervisor mode is god. – forest Nov 1 '18 at 7:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.