Hello
I have a generic function driver for PCI Device (KMDF) that its external interface is some IOCTL and Write/Read.
When I run WHCK all of the fuzzing tests (e.g. DF - Fuzz random IOCTL test (Certification) ) are passing, when I look at the logs I see the following text: ?WDTF_FUZZTEST: Cannot open any attack surface on device?
What does it mean? Can it be that the WHCK testing cannot do IOCTL fuzzing on my driver?
Thanks in advance.
xxxxx@gmail.com wrote:
I have a generic function driver for PCI Device (KMDF) that its external interface is some IOCTL and Write/Read.
When I run WHCK all of the fuzzing tests (e.g. DF - Fuzz random IOCTL test (Certification) ) are passing, when I look at the logs I see the following text: ?WDTF_FUZZTEST: Cannot open any attack surface on device?
What does it mean? Can it be that the WHCK testing cannot do IOCTL fuzzing on my driver?
Right. For example, if your device is declared as “exclusive open”, and
some app already has a handle, then WHCK can’t get in to do its
hacking. This a Good Thing – that message means the test will pass.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
My Driver is not exclusive open…
how can I debug it? I don’t see any useful in the logs…
in which logs should I dag in?
xxxxx@gmail.com wrote:
My Driver is not exclusive open…
how can I debug it? I don’t see any useful in the logs…
in which logs should I dag in?
There’s nothing to debug. The “fuzz” test sends random ioctls to a
device IF it can open a handle to it. If it can’t open a handle, then
the device is safe because there’s no way to inject bad ioctls. It’s
not a failure.
Is there some reason why a plain open would fail? Do you require a
special file name or special permissions? Have you set a breakpoint on
the file open path to see what it’s doing?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Suppose I write a driver that is a trapdoor. Then my app, perhaps
something in JavaScript, opens the one-and-only handle, and sends the
secret IOCTL code down, and all security falls to pieces. So how is
having exclusive open a guarantee of safety?
joe
xxxxx@gmail.com wrote:
> My Driver is not exclusive open…
> how can I debug it? I don’t see any useful in the logs…
> in which logs should I dag in?There’s nothing to debug. The “fuzz” test sends random ioctls to a
device IF it can open a handle to it. If it can’t open a handle, then
the device is safe because there’s no way to inject bad ioctls. It’s
not a failure.Is there some reason why a plain open would fail? Do you require a
special file name or special permissions? Have you set a breakpoint on
the file open path to see what it’s doing?–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@flounder.com wrote:
Suppose I write a driver that is a trapdoor. Then my app, perhaps
something in JavaScript, opens the one-and-only handle, and sends the
secret IOCTL code down, and all security falls to pieces. So how is
having exclusive open a guarantee of safety?
Honestly, Joe, you need to adjust your medication. This thread is not
about security or safety. This thread is about dealing with what
appeared to be an error from the WHCK tests.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> xxxxx@gmail.com wrote:
> My Driver is not exclusive open…
> how can I debug it? I don’t see any useful in the logs…
> in which logs should I dag in?There’s nothing to debug. The “fuzz” test sends random ioctls to a
device IF it can open a handle to it. If it can’t open a handle, then
the device is safe because there’s no way to inject bad ioctls. It’s
not a failure.
“Inject bad IOCTLs”? And this ISN’T about security? What is a “bad”
IOCTL? I can certainly appreciate that sending an illegal IOCTL should
trigger an error (the number of drivers I saw that returned without
completing the IRP with an error code is frighteningly high). But
detecting an illegal IOCTL has nothing to do with having multiple handles
open, and if a device CAN have multiple handles open, then presumably it
is capable of handling multiple handles; therefore, if there is a problem
with two handles sending IOCTLs, it has nothing to do with “bad” IOCTLs;
an erroneous driver wouldn’t handle multiple “good” IOCTLs. So the only
explanation of what is a “bad” IOCTL is one that can be used to compromise
security…but then, maybe that’s because I think of security as an
important issue. And words like “safe” typically mean “will not
compromise the integrity of the operating system”. So it obviously must
deal with the issues of robustness, reliability, and security. Or perhaps
this is a meaning of the word “safe” of which I have been previously
unaware.
My meds were recently adjusted; I now take 7.5mg of Coumadin on Wednesday
and Friday evening. I used to take 7.5 only on Wednesdays.
How, exactly, this affects my ability to comment on what seemed to be the
obvious problem under consideration, is something I do wonder about.
joe
Is there some reason why a plain open would fail? Do you require a
special file name or special permissions? Have you set a breakpoint on
the file open path to see what it’s doing?–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer