

Complete the IRP operation with a success result.Modify the IRP then pass to the next driver.Pass the IRP unmodified directly to the next driver in the stack.The driver callback can then do a number of different things to the IRP. The IRP is then dispatched to the top of the device stack associated with the request.Ī filter driver registers for the IO requests it supports with a callback function which is invoked when a specific IO request type IRP is queued in the device stack. When you make a request to access a file, such as calling the NtCreateFile system call the IO Manager allocates an IO Request Packet (IRP) structure which contains the operation type and all the parameters for the operation. Filter Driver ImplementationĪ filter driver exploits the way the Windows IO Manager implements file system drivers.


With this in mind let’s start with an overview of how a filter driver works. Also I’m not claiming this to be an exhaustive description of bug hunting in filter drivers as the topic is very deep and complex. I’m assuming you have some prior knowledge on how the IO Manager works and have experience in finding security issues in non-filter drivers. The goal is to allow you to do your own research in this area. I’ll also provide some basic example code to give you a basic idea of some common coding patterns. I’m going to give an overview of how filter drivers work, how you communicate with them, some hints on reverse engineering and some of the common security issues you might discover. With the issues being fixed I thought would be a good opportunity to go into a bit more detail on how you can research file system filter drivers, specifically the kind of things I looked at to find my security vulnerabilities. This power comes with many responsibilities, and considering the complexity of the IO model on Windows it can be hard to avoid introducing subtle bugs. What this boils down to is the filter driver can inspect and modify almost any IO request sent to a file system. Typical applications for file system filter drivers include antivirus utilities, encryption programs, and hierarchical storage management systems.” Depending on the nature of the driver, filter can mean log, observe, modify, or even prevent. “A file system filter driver can filter I/O operations for one or more file systems or file system volumes. The purpose of a file system filter driver according to Microsoft is: I’ve found a number of issues in filter drivers previously, including 6 in the LUAFV driver which implements UAC file virtualization. These 4 issues were 3 local privilege escalations and a security feature bypass, and they were all present in Windows file system filter drivers. In December Microsoft fixed 4 issues in Windows in the Cloud Filter and Windows Overlay Filter (WOF) drivers ( CVE-2020-17103, CVE-2020-17134, CVE-2020-17136, CVE-2020-17139 ).
