Assuming a predetermined set of desired drivers in a driver stack, is there a programatic way to determine what drivers are in the stack and then authenticate/verify the identity of each driver? To take it one step further, is there a way to know when the system attempts to insert a driver (such as an intermediate driver) into a stack and prevent its insertion if unable to verify its identity?
Thanks
No. No such mechanism exists. Even if it did, any driver could circumvent it because it runs at the same level of trust.
d
sent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@unisys.com
Sent: June 03, 2010 8:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Verification of drivers in a stack
Assuming a predetermined set of desired drivers in a driver stack, is there a programatic way to determine what drivers are in the stack and then authenticate/verify the identity of each driver? To take it one step further, is there a way to know when the system attempts to insert a driver (such as an intermediate driver) into a stack and prevent its insertion if unable to verify its identity?
Thanks
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
First drivers are not inserted into the stack they are added to the top
of the stack.
You can see drivers being loaded but you will not know what stacks they
are attaching to until they are present in the stack. You can use
IoGetAttachedDeviceReference to get the device object for the top of the
stack to test if what you think is the top of the stack is the top of
the stack.
Finally there is no way to block an attach to a stack of a loading of a
driver by another driver in the kernel.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@unisys.com [mailto:xxxxx@unisys.com]
Posted At: Thursday, June 03, 2010 11:59 AM
Posted To: ntdev
Conversation: Verification of drivers in a stack
Subject: Verification of drivers in a stackAssuming a predetermined set of desired drivers in a driver stack, is
there a
programatic way to determine what drivers are in the stack and then
authenticate/verify the identity of each driver? To take it one step
further,
is there a way to know when the system attempts to insert a driver
(such as an
intermediate driver) into a stack and prevent its insertion if unable
to
verify its identity?Thanks
__________ Information from ESET Smart Security, version of virus
signature
database 5169 (20100603) __________The message was checked by ESET Smart Security.
intermediate driver ? did you mean in NDIS ? I think NDIS maintain the
relationships between the miniport/protocol/intermediate drivers , maybe not
the device stack model WDM take . In a device stack your question is how to
hook function call like IoAttachDeviceToDeviceStack , I think it’s a
difficult thing
2010/6/3
> Assuming a predetermined set of desired drivers in a driver stack, is there
> a programatic way to determine what drivers are in the stack and then
> authenticate/verify the identity of each driver? To take it one step
> further, is there a way to know when the system attempts to insert a driver
> (such as an intermediate driver) into a stack and prevent its insertion if
> unable to verify its identity?
>
> Thanks
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
The case that I am looking at is indeed an NDIS 6.x stack containing a miniport and intermediate driver under Windows TCP/IP. It is my understanding that additional IM drivers could be added to the stack at just about any time by anyone with administrative authority. This presents a potential security risk w.r.t. software integrity and packet interception. Hence ny questions about verification and detection.
The security risk in this scenario would be that users who are not trusted are being granted administrative access.
The OS security model is such that admin == full control of the system. Trying to enforce a policy contrary to this will not be a successful endeavor.
-----Original Message-----
From: xxxxx@unisys.com
Sent: Thursday, June 03, 2010 9:50
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verification of drivers in a stack
The case that I am looking at is indeed an NDIS 6.x stack containing a miniport and intermediate driver under Windows TCP/IP. It is my understanding that additional IM drivers could be added to the stack at just about any time by anyone with administrative authority. This presents a potential security risk w.r.t. software integrity and packet interception. Hence ny questions about verification and detection.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>driver under Windows TCP/IP. It is my understanding that additional IM drivers could be added to the
stack at just about any time by anyone with administrative authority.
Yes.
This presents a potential security risk w.r.t. software integrity and packet interception.
No security risks, just do not give the administrative authority to everybody.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
On 6/3/2010 9:50 AM, xxxxx@unisys.com wrote:
The case that I am looking at is indeed an NDIS 6.x stack containing a miniport and intermediate driver under Windows TCP/IP. It is my understanding that additional IM drivers could be added to the stack at just about any time by anyone with administrative authority. This presents a potential security risk w.r.t. software integrity and packet interception. Hence ny questions about verification and detection.
What you're really said here is "someone could break security if they've already completely broken
security".
Ray