I've made a program called explochip. This program probes every hardware port on PC,at first I use it to help in building my own hardware monitoring software under win2K/XP for winbond chip in my motherboard,then to tweak my motherboard's memory controller. It works pretty good, but recently I found that the driver that I build with the program has a major security flaws, since the it uses the "old" RTLxxx function to export the driver "interface" into the user mode program to be openend by DeviceIoControl function. I uses this approach since at the time I'm building the explochip, that's the only way I know of :stupid: . I've read somewhere on the net that to be safe we have to use something related to GUID stuff,I'm a real noobie in this GUID stuff, I know that it's something related to COM (component object model),but how exactly to implement it? The flaw when using RTLxxx approach is that a cracker can enumerate the "device object name" that is exported to usermode by enumerating the object names in the operating system namespace and then by using CreateFile to open a handle to the driver, they can poke around in kernel mode, this is a mess :sweat:. I want to prevent it in my next revision of explochip,any suggestion :confused: .The site to download explochip is here: http://www.geocities.com/mamanzip/pinczakko.html ,it's in very early beta version and only runs on win2K/XP. I'm planning to release the source code soon if there's a demand ;)
Hi
I hated to see a potentially interesting topic disappear without some kind of reply.
As you say, if you name your device object when you call IoCreateDevice, and/or create a symbolic link name with IoCreateSymbolicLink, it is open to potentially malicious use. Programming the Microsoft WDM by Walter Oney discusses this topic a bit in Chap.2. The solution it seems is to the use the concept of a *device interface* for application <-> driver communication. The PSDK utility GUIDGEN can be used to generate a unique 128-bit GUID, which can then be registered with IoRegisterDeviceInterface. He makes the analogy of protein markers on cells to how only certain apps can then access the driver functions in a lock and key fashion.
While the driver side of creating a Device Interface is outlined, there is little mention of the application side, but seems to reside in the plug and play realm. If you look in the PSKD under Base Services/Device IO/Device Management there is a section on using Device Interface communication. APIs such as SetupDiGetDeviceInterfaceDetail are used to communicate with the device. Ultimately though, CreateFile and a symbolic link are used to access the device, so I'm not sure exactly where the extra security may come in, other than DeviceIOControl appears not to be used.
I'm not sure under what conditions you're concerned with malicious use of your driver, but there may be more general programming security steps you can take as well. If you research this further please share some of your discoveries, driver issues are always interesting.
Cheers,
Kayaker
I hated to see a potentially interesting topic disappear without some kind of reply.
As you say, if you name your device object when you call IoCreateDevice, and/or create a symbolic link name with IoCreateSymbolicLink, it is open to potentially malicious use. Programming the Microsoft WDM by Walter Oney discusses this topic a bit in Chap.2. The solution it seems is to the use the concept of a *device interface* for application <-> driver communication. The PSDK utility GUIDGEN can be used to generate a unique 128-bit GUID, which can then be registered with IoRegisterDeviceInterface. He makes the analogy of protein markers on cells to how only certain apps can then access the driver functions in a lock and key fashion.
While the driver side of creating a Device Interface is outlined, there is little mention of the application side, but seems to reside in the plug and play realm. If you look in the PSKD under Base Services/Device IO/Device Management there is a section on using Device Interface communication. APIs such as SetupDiGetDeviceInterfaceDetail are used to communicate with the device. Ultimately though, CreateFile and a symbolic link are used to access the device, so I'm not sure exactly where the extra security may come in, other than DeviceIOControl appears not to be used.
I'm not sure under what conditions you're concerned with malicious use of your driver, but there may be more general programming security steps you can take as well. If you research this further please share some of your discoveries, driver issues are always interesting.
Cheers,
Kayaker
Thx a lot :alright: . I'm still newbie on this stuff :grin: . But, I'll try to implement it and try to hack it myself if I could pass it, then there must be some security hole somewhere . :confused:
Yes, as i understand it, the GUID which is tyically used to define *specifically* each COM object's address information in the registry, is also being used to *specifcally* define a driver to the calling program, if and only if, it knows the specifc GUID value.
The value is not trivail either. Its 128 bits long, lots of room for error ;) . If your applications build the GUID value in an indirect means, it will be harder for some person to 'sniff' out the GUID number. But definitely not impossible. The security advantage here is that to the average joe, who sees this driver, can not get it going without a working application example, since the driver doesnt point to any one application. So only people with the proper copy of the driver and application software, and the patience to sniff out your GUID number, will have a chance of abusing it. Most people would give as soon as they realize they need to sniff out a secret GUID value.
Oh, ya, and incase your thinking they might be able to randomly generate their own, you can pretty well feel safe they wont. As the value is generated by both TIME and SPACE variables. This means, that a number generated 5 minutes ago, will never be generated again (in theory). Like wise, due to the chance of someone in Germany generating a number at the same time i do, their regional information is also used to help keep these numbers extremely unique in the world. Lastly, since the number is 128 bits long, it will be the year 3000 and something before it "rolls over". So you can feel safe your number wont expire either ;)
Regards,
:NaN:
The value is not trivail either. Its 128 bits long, lots of room for error ;) . If your applications build the GUID value in an indirect means, it will be harder for some person to 'sniff' out the GUID number. But definitely not impossible. The security advantage here is that to the average joe, who sees this driver, can not get it going without a working application example, since the driver doesnt point to any one application. So only people with the proper copy of the driver and application software, and the patience to sniff out your GUID number, will have a chance of abusing it. Most people would give as soon as they realize they need to sniff out a secret GUID value.
Oh, ya, and incase your thinking they might be able to randomly generate their own, you can pretty well feel safe they wont. As the value is generated by both TIME and SPACE variables. This means, that a number generated 5 minutes ago, will never be generated again (in theory). Like wise, due to the chance of someone in Germany generating a number at the same time i do, their regional information is also used to help keep these numbers extremely unique in the world. Lastly, since the number is 128 bits long, it will be the year 3000 and something before it "rolls over". So you can feel safe your number wont expire either ;)
Regards,
:NaN:
Thanx, NaN, your explanation absolutely enlightening. :grin:
Do note that older versions of windows have *very* bad GUID generation - basically a number that increments linearly with the tick counter. Recent versions (win2k, dunno about "plain NT") use a lot of different information (trace the GUID creation api function with a debugger), and iirc even runs this through a one-way hash.
But don't count on GUIDs from win9x being too unique.
But don't count on GUIDs from win9x being too unique.