Modern versions of Windows have very strict driver-signing requirements with regard to allowing a driver to load.Since it's rare that a malware author would need to do something that can only be done from kernel-mode, there's usually not much value in writing a malicious driver. It's more difficult to develop (malicious) kernel-mode code than it is to develop (malicious) user-mode code.Other reasons we don't see much malware in the form of drivers: The first thing that NtLoadDriver() does is check that the caller's token has SeLoadDriverPrivilege, which even administrators' tokens don't have by default. If it's that simple to load a driver in kernel mode (I'm assuming it's not) then why don't we see more malware in the form of drivers? What we typically think of as a "driver" is a kernel-mode driver. You can write a user-mode driver using the User-Mode Driver Framework, but that type of driver is effectively a user-mode service with access to some extra I/O functionality. Is it even possible for a non kernel mode driver to exist? Would this driver exist in user space, or in kernel space?
0 Comments
Leave a Reply. |