lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
From: trik-news at gmx.de (Spiro Trikaliotis) Subject: Win32 Device Drivers Communication Vulnerabilities + PoC for Symantec Norton AntiVirus '2002 (probably all versions) Device Driver Hello, On Fri, Aug 02, 2002 at 10:39:44AM +0200, [SEC-LABS TEAM]: wrote: > > The Sec-Labs security research group found a bug in Win32 Device Drivers Communication, the white-paper for this vulnerability can > be viewed at http://sec-labs.hack.pl , the exploit code for Symantec Norton AntiVirus '2002 (probably all versions) Device Driver is also stored at our homepage. > Enjoy. from the posting at the Full-Disclosure Mailing list, I found the article on http://sec-labs.hack.pl/papers/win32ddc.php. In this article, you write: "As far as I know, Windows system is not checking if the memory location (agruments/memory pointers) is valid, and it isn't a windows vulerability? - give me a break!" For this, I want to comment the following: Each IRP on NT/2K/XP has a method argument, that is, the last 3 bits indicate which access method is used. The DDK defines the following types (see devioctl.h): #define METHOD_BUFFERED 0 #define METHOD_IN_DIRECT 1 #define METHOD_OUT_DIRECT 2 #define METHOD_NEITHER 3 The IRP you used for this proof of concept (222A87h) obviously has METHOD_NEITHER. The DDK clearly states what these methods mean: (Windows DDK/Kernel-Mode Driver Architecture/Reference/System-Defined I/O Function Codes/IRP Function Codes and IOCTRL/Defining I/O Control Codes): "METHOD_BUFFERED, if the driver transfers small amounts of data for the request With this method, IRPs containing the I/O control code will supply a pointer to the buffer into which or from which to transfer data at Irp->AssociatedIrp.SystemBuffer. Most I/O control codes for device and intermediate drivers use this TransferType value. METHOD_IN_DIRECT, if the underlying device driver will read a large amount of data for the request using DMA or PIO and must transfer the data quickly With this method, IRPs containing the I/O control code will supply a pointer to an MDL, describing the output buffer at Irp->MdlAddress. METHOD_OUT_DIRECT, if the underlying device driver will write a large amount of data to the device for the request using DMA or PIO and must transfer the data quickly With this method, IRPs containing the I/O control code will supply a pointer to an MDL, describing the data buffer, at Irp->MdlAddress. METHOD_NEITHER, if the driver can be sent such a request only while it is running in the context of the thread that originates the I/O control request Only a highest-level kernel-mode driver is guaranteed to meet this condition, so this value is seldom used for the I/O control codes passed to device drivers. With this method, the highest-level driver must determine whether to set up buffered or direct access to user data on receipt of the request, possibly must lock down the user buffer, and must wrap its access to the user buffer in a structured exception handler. Otherwise, the originating user-mode caller might change the buffered data out from under the driver or the caller could be swapped out just as the driver is accessing the user buffer." There are even more explicit texts. In fact, METHOD_NEITHER means literally what the name means: Windows does not touch or check the buffer pointer or the buffer itself in any way, does not perform any checks nor anything else. All text books I've read so far even advice not to use METHOD_NEITHER unless one knows exactly what he is doing - something the driver writer obviously did not in your example. The DDK even contains the following statement (Windows DDK/Kernel-Mode Driver Architecture/Design-Guide/Driver Programming Techniques/Driver Reliability Issues/Errors in Referencing User-Space Addresses): Errors in Referencing User-Space Addresses A driver should validate any address in user space before trying to use it. The I/O Manager does not validate such addresses, nor does it validate pointers that are embedded in buffers passed to drivers. Failure to Validate Addresses Passed in Type3 (METHOD_NEITHER) IOCTLs and FSCTLs The I/O Manager does no validation whatsoever for METHOD_NEITHER IOCTLs and FSCTLs. To ensure that user-space addresses are valid, the driver must use the ProbeForRead and ProbeForWrite routines, enclosing all buffer references in try/except blocks. So, unless you find another IOCTL with another method, I think it is not correct to call this a windows vulerability. The driver writer *explicitly* chose to shut down any tests Windows makes, but did not handle this case correctly. You can blame Microsoft for very much, but how can you blame Microsoft for this? Curious, Spiro.
Powered by blists - more mailing lists