I have read a good bit on here about filtering USB devices, but want to clarify some of my understandings so I don’t go down a bad path.
-
If I want to, from the kernel, filter ALL USB devices, that is have my filter installed on every single USB device that gets plugged in, there is essentially no documented way to do this? Only hope is an undocumented bus filter driver as mentioned by Mark Roddy et. al. in previous posts?
-
WPD devices were never meant to be filtered from the kernel? Is there no way to filter URBs for these devices from the kernel in a standard/recommended fashion?
-
Who/what creates the \Driver\SoftwareDevice driver? Looking in WinDbg it appears that all of the DeviceObjects in this driver’s device list are PDOs. That doesn’t follow the normal PnP bus setup as I understand it. In other words I would expect to find at least one FDO that attached to some other PDO’s stack, but I don’t. Is this driver a special case?
Thanks for any help/info!
-Fred
What bigger problem are you trying to solve ? bus filtering all usb device is usually not the right answer. \Driver\SoftwareDevice is a “built in” driver in the kernel (just like the root bus). As a special driver, it has specifical kernel APIS that route IO to it, not an FDO. This driver is responsible for creating swdevices, see SwDeviceCreate, https://msdn.microsoft.com/en-us/library/windows/hardware/dn315038(v=vs.85).aspx
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, June 8, 2017 9:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Filtering USB devices
I have read a good bit on here about filtering USB devices, but want to clarify some of my understandings so I don’t go down a bad path.
1) If I want to, from the kernel, filter ALL USB devices, that is have my filter installed on every single USB device that gets plugged in, there is essentially no documented way to do this? Only hope is an undocumented bus filter driver as mentioned by Mark Roddy et. al. in previous posts?
2) WPD devices were never meant to be filtered from the kernel? Is there no way to filter URBs for these devices from the kernel in a standard/recommended fashion?
3) Who/what creates the \Driver\SoftwareDevice driver? Looking in WinDbg it appears that all of the DeviceObjects in this driver’s device list are PDOs. That doesn’t follow the normal PnP bus setup as I understand it. In other words I would expect to find at least one FDO that attached to some other PDO’s stack, but I don’t. Is this driver a special case?
Thanks for any help/info!
-Fred
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
Well, without going into to much detail, suffice it to say this is a security product, and kernel only filtering is a requirement. Being able to control (i.e. prevent start, filter traffic, etc.) all USB devices from the kernel is a must.
Doran,
Also, thanks for the explanation on \Driver\SoftwareDevice, I thought that was the case (root driver).
xxxxx@gmail.com wrote:
Well, without going into to much detail, suffice it to say this is a security product, and kernel only filtering is a requirement. Being able to control (i.e. prevent start, filter traffic, etc.) all USB devices from the kernel is a must.
At the risk of starting another flame war, this is a ridiculous design
goal. There are a nearly infinite number of USB devices, each with
their own protocols, each with their own traffic patterns. You cannot
possible hope to understand all of the device types well enough to do
any kind of reasonable filtering. What happens if you interfere with
the traffic of the USB device controlling grandma’s respirator?
If you want to control access to USB storage devices or USB camera
devices, there are group policy options to do that. Beyond that, the
most effective way to control access to USB ports is to inject silicone
sealant into the ports. Anything else is doomed to failure.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Well, one man’s ridiculous is another man’s absolute requirement. Try to back up a second and think about everywhere Windows is used. Perhaps there are some Windows machines that are so sensitive that extreme measures are absolutely necessary. Let’s just pretend that this case involves that sort of situation and go back to the problem shall we?
Group policy is not sufficient for reasons I will not go into here, but I understand the problem landscape and why you suggest it. The suggestion is good, just not sufficient in all use cases.
USB device absolutely must be used. But, their use needs to be heavily (as heavy as possible) controlled (no solution is perfect and this won’t be either, but raising the bar as high as possible is the goal).
Your goals are basically impossible. While you can prevent devices from
showing up with a bus filter, you can never filter the traffic because each
USB device is different. This would be like saying you are going to
interpret every packet over Ethernet, you might see the raw packet but you
cannot do intelligent control.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, June 08, 2017 1:05 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Filtering USB devices
Well, without going into to much detail, suffice it to say this is a
security product, and kernel only filtering is a requirement. Being able to
control (i.e. prevent start, filter traffic, etc.) all USB devices from the
kernel is a must.
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>
Don,
I respectfully disagree. Keep in mind I am not stuck with a single driver for this, I can utilize several kernel and even user-mode agents to solve what needs to be solved. BUT, being able to absolutely ensure that no USB device is plugged in without a filter attached in the kernel is a must. That is definitely doable, just curious if there is a sanctioned/better way to do it than what I am imagining at the moment? I’ve seen far worse attempted and carried off with success.
I really don’t want to get into a debate about design. I know folks won’t like what I am doing, but there are times you just have to do things that aren’t pleasant. There just is no way around it.
Doing things in the least unpleasant way is my goal here.
-Fred
A bus filter driver can do this. But you know that already. It is not
impossible. It is just unusual and for usb difficult because of the usb
architecture. Implemented correctly you would be actively filtering at the
usb hub pdo level, and as such would have access to all usb connected
devices.
Mark Roddy
On Thu, Jun 8, 2017 at 1:37 PM, wrote:
> Don,
>
> I respectfully disagree. Keep in mind I am not stuck with a single driver
> for this, I can utilize several kernel and even user-mode agents to solve
> what needs to be solved. BUT, being able to absolutely ensure that no USB
> device is plugged in without a filter attached in the kernel is a must.
> That is definitely doable, just curious if there is a sanctioned/better way
> to do it than what I am imagining at the moment? I’ve seen far worse
> attempted and carried off with success.
>
> I really don’t want to get into a debate about design. I know folks won’t
> like what I am doing, but there are times you just have to do things that
> aren’t pleasant. There just is no way around it.
> Doing things in the least unpleasant way is my goal here.
>
> -Fred
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
You can see all devices with a bus filter, they are undocumented but can be
figured out (there are a few notes in the Walter Oney book “Programming the
Windows Drivers Model”.
On your claim you can do this, you are talking an essentially infinite
number of different devices, so you are faced with potentially having an
essentially infinite number filters. Theoretically anything is possible, in
actuality either there are constraints you have not revealed, or you have a
task that will never be completed.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, June 08, 2017 1:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Filtering USB devices
Don,
I respectfully disagree. Keep in mind I am not stuck with a single driver
for this, I can utilize several kernel and even user-mode agents to solve
what needs to be solved. BUT, being able to absolutely ensure that no USB
device is plugged in without a filter attached in the kernel is a must.
That is definitely doable, just curious if there is a sanctioned/better way
to do it than what I am imagining at the moment? I’ve seen far worse
attempted and carried off with success.
I really don’t want to get into a debate about design. I know folks won’t
like what I am doing, but there are times you just have to do things that
aren’t pleasant. There just is no way around it.
Doing things in the least unpleasant way is my goal here.
-Fred
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>
Don,
Thanks, bus filter is what I was hoping to avoid, but alas, seems the only alternative.
Agreed on the scope. Fortunately, I do have the luxury of deny everything until it is proven necessary, so we can piece meal the solutions. Never completed, ha, you may indeed be correct!
If anyone has a better solution for the basic filtering, I am all ears. Thanks all for the comments!
-Fred
Global USB filtering is definitely doable. I did this for both Windows and Mac OS X. Yes, this might involve a technique that gives someone in this list a heart attack.
Thank you Mark as well, your past posts on bus filters have been extremely helpful and looks like will be again!
Doran,
Real quick, is there any way to do #2?:
- WPD devices were never meant to be filtered from the kernel? Is there no way
to filter URBs for these devices from the kernel in a standard/recommended
fashion?
>2) WPD devices were never meant to be filtered from the kernel?
Are you sure ? I know about an antivirus that does this along with many other device classes.
HKLM, System\CurrentControlSet\Control\Class{EEC5AD98-8080-425F-922A-DABF3DE3F69A}, UpperFilters, 0x00010008, %ServiceName% ; WPD
N.D.,
You are correct, I should be more succinct. You can definitely filter those devices, but you can’t, to my knowledge, deal with USB URBs from an upper class filter to the WPD class of devices {EEC5AD98-8080-425F-922A-DABF3DE3F69A}.
So, I am curious if there is a way to filter the URB traffic for these devices in the kernel in some standard fashion?
-Fred
As long as you are below the FDO (wudfrd in this case), as you would be as a bus filter, you should be able to filter WPD. If the fdo has a bug in it where it sends IO directly to the PDO, your filter is out of luck.
If these machines are so secure/sensitive and you can’t seal off the USB ports, why are you letting random drivers load? Don’t let new drivers come from WU and have a limited set of drivers in the image.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, June 8, 2017 11:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Filtering USB devices
N.D.,
You are correct, I should be more succinct. You can definitely filter those devices, but you can’t, to my knowledge, deal with USB URBs from an upper class filter to the WPD class of devices {EEC5AD98-8080-425F-922A-DABF3DE3F69A}.
So, I am curious if there is a way to filter the URB traffic for these devices in the kernel in some standard fashion?
-Fred
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
Well, THAT is completely different issue. I don’t control the IT department. This isn’t a new setup either, so, what is done is done, changes are difficult/slow. If you ever work with bureaucracies beyond your wildest imagination, you will start to understand. I can’t fix the setup, but I can try to make it more secure. Unfortunately, it’s still important as well.
By the way, one more quick one, hopefully, on WPD. So, I plug in an iPhone and I have a minifilter that selectively loads on USB devices. How in the world do I tell that a WPD storage device is actually USB connected?
I tried IOCTL_STORAGE_QUERY_PROPERTY and the bus comes back BusTypeSata. I tried IoGetDeviceProperty for DevicePropertyBusTypeGuid and that apparently isn’t supported (returns 0xC0000034). I tried again with DevicePropertyEnumeratorName and that comes back “SCSI”. Is there an easy/straight forward way to determine that this storage device is ultimately USB connected?
By the way, this is going into multiple environments. One in which iPhones and the like are likely, another in which those types of devices would never appear. Just to clarify my previous important/sensitive comments.
Doran,
Also, it isn’t driver loading I am worried about. It is USB devices and their traffic. Drivers are controlled, I skimmed your post, and was thinking devices being controlled. Drivers are not a concern. But, USB devices can do incredibly dangerous things with in box drivers.
-Fred