I was wondering if DC2.EXE or a similar utility exists that could do an
exhaustive test for device driver security issues on a given driver.
Specifically I have added a number of try/except and
ExAllocatePoolWithQuotaTags changes and would like to test to make sure they
are working and the exploits are covered (as per the security suggestions at
the recent WinHEC 2002 conference).
DC2 has a number of switches like /if /in /pr /sd that seem to do some
security tests but has anyone worked out the best combination of switches
for this type of testing or know of another utility?
Thanks
Allan
“Allan Smith” wrote in message news:xxxxx@ntdev…
>
> I was wondering if DC2.EXE or a similar utility exists that could do an
> exhaustive test for device driver security issues on a given driver.
>
In a word, no.
While DC2 is a very helpful little utility, there are no settings that will
perform “an exhaustive test” for driver security. In fact, there probably
isn’t any such thing. It’s just too big a space to cover.
You can run a good quick set of tests on your driver using DC’s HCT mode:
DC2 /hct /dr your-driver-name-here
This will send “many thousands” of random ioctls to your driver. You can
also specify:
DC2 /hct /fl lowF /fu highF /dl lowD /du highD /dr your-driver-name-here
where:
lowF is the LOWEST IOCTL function code to send
highF is the HIGHEST IOCTL function code to send
lowD is the lowest device type to send
highD is the highest device type to send
Ensure that your device type is between lowD and highD, and that the
functions your device supports is between lowF and highF (NOTE: MOST drivers
that we non-MS types write will support function codes of 1024 and above…
so, be sure to try those).
Lastly, the /pr switch can be pretty amusing. It randomly and continuously
changes the protection on the user data buffers sent to your driver.
Most of the “non-standard” tests in DC2, including /pr, can be revealing but
can also give you all sorts of false positives. It’s cool as a development
support utility, but it can be hard to sort out precisely what failing a few
of several hundred thousand IOCTLs sent to your driver, due to the buffer
being set to read-only, really MEANS.
Hope that’s at least a little helpful.
Peter
OSR
Thank you for the information Peter.
Yes the number of things to test for can be huge and that is why I was
looking for the easy way out and hoping there was a utility that would do
the bulk of the work for me.
Our primary concern is protecting against bad IOCTL calls in the form of bad
codes, buffers etc along with the capping the ExAllocatePool call memory use
is working. Of course a utility that uncovered as many security holes as
possible would aid us greatly in our software quality verification.
Thanks again for the info
Allan
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Viscarola
Sent: June 18, 2002 6:52 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Automated testing of my driver for Driver security
exploits?
“Allan Smith” wrote in message news:xxxxx@ntdev…
>
> I was wondering if DC2.EXE or a similar utility exists that could do an
> exhaustive test for device driver security issues on a given driver.
>
In a word, no.
While DC2 is a very helpful little utility, there are no settings that will
perform “an exhaustive test” for driver security. In fact, there probably
isn’t any such thing. It’s just too big a space to cover.
You can run a good quick set of tests on your driver using DC’s HCT mode:
DC2 /hct /dr your-driver-name-here
This will send “many thousands” of random ioctls to your driver. You can
also specify:
DC2 /hct /fl lowF /fu highF /dl lowD /du highD /dr your-driver-name-here
where:
lowF is the LOWEST IOCTL function code to send
highF is the HIGHEST IOCTL function code to send
lowD is the lowest device type to send
highD is the highest device type to send
Ensure that your device type is between lowD and highD, and that the
functions your device supports is between lowF and highF (NOTE: MOST drivers
that we non-MS types write will support function codes of 1024 and above…
so, be sure to try those).
Lastly, the /pr switch can be pretty amusing. It randomly and continuously
changes the protection on the user data buffers sent to your driver.
Most of the “non-standard” tests in DC2, including /pr, can be revealing but
can also give you all sorts of false positives. It’s cool as a development
support utility, but it can be hard to sort out precisely what failing a few
of several hundred thousand IOCTLs sent to your driver, due to the buffer
being set to read-only, really MEANS.
Hope that’s at least a little helpful.
Peter
OSR
—
You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%
I have another question. When running some of the DC2 options it creates
some extra log files CRASHN.LOG and DIAGS.LOG.
I don’t see the exact definition of what these files are for in the
documentation or -? help output.
During some of my tests DC2 prints:
DC2 has stopped making progress… Attempting to resume
DC2 has successfully resumed testing
I don’t see any clearly marked errors in these files, so I am unsure how to
interpret these messages.
Does anyone have any information on if the messages are a concern or what
these log files are for?
Thanks
Allan
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Viscarola
Sent: June 18, 2002 6:52 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Automated testing of my driver for Driver security
exploits?
“Allan Smith” wrote in message news:xxxxx@ntdev…
>
> I was wondering if DC2.EXE or a similar utility exists that could do an
> exhaustive test for device driver security issues on a given driver.
>
In a word, no.
While DC2 is a very helpful little utility, there are no settings that will
perform “an exhaustive test” for driver security. In fact, there probably
isn’t any such thing. It’s just too big a space to cover.
You can run a good quick set of tests on your driver using DC’s HCT mode:
DC2 /hct /dr your-driver-name-here
This will send “many thousands” of random ioctls to your driver. You can
also specify:
DC2 /hct /fl lowF /fu highF /dl lowD /du highD /dr your-driver-name-here
where:
lowF is the LOWEST IOCTL function code to send
highF is the HIGHEST IOCTL function code to send
lowD is the lowest device type to send
highD is the highest device type to send
Ensure that your device type is between lowD and highD, and that the
functions your device supports is between lowF and highF (NOTE: MOST drivers
that we non-MS types write will support function codes of 1024 and above…
so, be sure to try those).
Lastly, the /pr switch can be pretty amusing. It randomly and continuously
changes the protection on the user data buffers sent to your driver.
Most of the “non-standard” tests in DC2, including /pr, can be revealing but
can also give you all sorts of false positives. It’s cool as a development
support utility, but it can be hard to sort out precisely what failing a few
of several hundred thousand IOCTLs sent to your driver, due to the buffer
being set to read-only, really MEANS.
Hope that’s at least a little helpful.
Peter
OSR
—
You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%
“Allan Smith” wrote in message news:xxxxx@ntdev…
>
> I have another question. When running some of the DC2 options it creates
> some extra log files CRASHN.LOG and DIAGS.LOG.
>
CRASHN.LOG is the restart log, and is used by DC2 to restart processing
after a crash.
DIAGS.LOG is the diagnostics log, that has additional information about each
DC2 operation. For example, if you do NOT specify /HCT, logging in
DIAGS.LOG defaults of /LDI (“logging, diagnostic, INFORMATION level”) which
logs every single request sent to your driver. This log can get, ah,
“rather long” and logging at this level can take “a while”.
> During some of my tests DC2 prints:
>
> DC2 has stopped making progress… Attempting to resume
> DC2 has successfully resumed testing
>
This isn’t usually an error. Rather, it signals that DC2 is waiting for
some previously issued I/O requests to complete. For example, some of the
IOCTLs DC2 issues might be interpreted by the driver under test as being
synchronous. DC2 tries to wake itself and continue running, and will
eventually issue a cancel for this pending requests. Assuming the cancel is
successful (as it should be) then there’s no error. You can disable
synchronous operations by specifying /-k.
HTH,
Peter
OSR