Bluetooth driver stack implementations

Just for the record: Broadcom WIDCOMM Bluetooth stack ships in two versions

  • one is Bluetooth
    bus driver based and another is root-enumerated.

Thanks,
Ilya Faenson

-----Original Message-----
Subject: RE: Bluetooth driver stack implementations
From: “Shahar Talmi”
Date: Wed, 17 Nov 2004 18:56:27 +0200
X-Message-Number: 10

Yes, I’m aware of the WIDCOMM design. I already did a little research on it.

Thanks for the warning.

I’ll take you note about the undocumented IOCTL in consideration, but its
very hard for me to believe that filtering the HCI layer will be effective
for my purposes.
Should I take it that there are no other important implementations?

Thanks,
Shahar.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, November 17, 2004 6:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations

WIDCOMM uses disjoint stacks, they don’t use a bus driver design. Each
protocol is it’s own root enumerated device and opens the radio on the side.
Be warned, there were WIDCOMM releases where if the radio devnode failed to
start, one of the auxiliary protocols would bugcheck the
machine.

Filtering above the controller at the IOCTL level is not such a great idea.
Each stack has its own set of undocumented IOCTLs and behaviors that you
would have to inspect and deconstruct w/out docs. This is why I asked about
filtering on a known protocol, the HCI layer in the stack.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Wednesday, November 17, 2004 3:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations

I am probably going to filter above the host controller, maybe even use a
bus filter driver (I would like to implement the driver in a way that will
allow me to know as little as possible about the actual Bluetooth protocol
stack).
One of the many potential purposes is to deny connections, but this is not
where it stops.
Do you think that filtering the WIDCOMM and Microsoft implementations will
cover almost all users ?

Shahar

If the machine is properly secured, that’s correct to a degree. Don’t
forget, though, that someone in physical possession of the machine can
always hack things with the recovery console, disk editing tools,
jumping out to the “Last Known Good Configuration”, etc. There are also
a number of known privilege elevation hacks for Windows…

It’s really unrestricted physical access to the machine that rules out
any kind of effective protection against this sort of thing.

Maxim S. Shatskih wrote:

You cannot protect the computer from administrators and limit their
actions. Period.

Non-administrators, in turn, cannot disable the filter drivers.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com mailto:xxxxx
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: Calvin Guan mailto:xxxxx
> To: Windows System Software Devs Interest List
> mailto:xxxxx
> Sent: Wednesday, November 17, 2004 10:49 PM
> Subject: RE: [ntdev] Bluetooth driver stack implementations
>
> Filter for this purpose is probably not solid.
>
> It’s not difficult for average users to remove a filter driver if
> (s)he really wants to use his Bluetooth or other stuff.
>
> -
> Calvin Guan Software Engineer
> ATI Technologies Inc. www.ati.com http:
>
> -----Original Message-----
> From: Shahar Talmi [mailto:xxxxx@safend.com]
> Sent: November 17, 2004 6:02 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Bluetooth driver stack implementations
>
> I am probably going to filter above the host controller, maybe even
> use a
> bus filter driver (I would like to implement the driver in a way
> that will
> allow me to know as little as possible about the actual Bluetooth
> protocol
> stack).
> One of the many potential purposes is to deny connections, but this
> is not
> where it stops.
> Do you think that filtering the WIDCOMM and Microsoft
> implementations will
> cover almost all users ?
>
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, November 16, 2004 10:13 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Bluetooth driver stack implementations
>
> If you filter below the host controller, the USB HCI is completely
> standardized and you can write a filter that covers all USB devices.
> Serial is a different story, although H5 should cover it for the
> most part.
>
>
> What is the purpose of the filter? To deny connections?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Tuesday, November 16, 2004 11:44 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Bluetooth driver stack implementations
>
> I plan to write a filter driver for a Bluetooth driver stack
> (probably for
> the Bluetooth Host Controller, or atleast I think this is the right
> term).
> Since I want my filter to work on as many computers as possible and
> since
> there are more then one implementations, it seems I would have to
> implement
> a different filter for each implementation.
> Therefore, I must know what implementations exist, and I’m hoping that
> WIDCOMM and Microsoft are covering enough users for me to be
> satisfied with
> only being able to filter those implementations.
>
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, November 16, 2004 9:15 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Bluetooth driver stack implementations
>
> OK, I’ll bite. Why is this important? What are you trying to do?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Tuesday, November 16, 2004 11:08 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Bluetooth driver stack implementations
>
> So, is it safe to assume WIDCOMM and Microsoft’s implementations are
> used by
> almost all Windows users that require Bluetooth support?
> Isn’t there any other implementation which is even close to be
> widely used?
>
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, November 16, 2004 7:41 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Bluetooth driver stack implementations
>
> 3com’s stack is dead and has been for a long time.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Programmers
> Society
> Prokash Sinha
> Sent: Tuesday, November 16, 2004 9:26 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Bluetooth driver stack implementations
>
> 3Com had a stack long back (2001 time fram) and it was essentially ESI
> (extended system’s joint work with 3Com) stack …
>
> -pro
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ati.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com


…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.</http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Sad, but true. This is an unfortunate blindness on how components within Windows use the OS provided security mechanisms - because it would be nice to delegate just certain privileges/operations to a restricted account, rather than concentrating all authority in one account (or one group) as seems to have become the default. Note that this is NOT a restriction on how the Security Reference Monitor works, but rather the na?ve insistence in other OS components that all power should be concentrated into a specially nominated group.

For example, you might want to create an account that has the ability to install new devices without the numerous other rights that are inherent in the rights assigned to the Admin Group (for example, Admin Group can override security checks using restore privilege). The current implementation of the Service Control Manager REQUIRES that the request come from the Admin Group - no choice. So you could modify the registry and force a reboot (which is likely to be required for a filter anyway) but you cannot do this in dynamic fashion.

In general, good security policy is to divide up tasks and compartmentalize the security rights to provide only those rights that are required. This has become my current hot-button because I recently spent time trying to figure out how to configure an account that was NOT a member of Admin Group that could install a service and found the SCM restriction. Then I went to figure out how to create a unique service account for interacting with a kernel driver as a counter-point to the hideous “let’s look at the undocumented image name in the EPROCESS” hack and found that I can’t use IoCreateDeviceSecure to create such an SD (with a non-well-known account) and the APIs necessary to do this correctly are not exposed. So, I’m restricted to using an account that is an Admin Group member which means that if I screwed up anything in my service, instead of merely compromising the control over my device, I have compromised the entire box.

The concentration of privileges and propensity for giving people unlimited control over the box to compensate has led to the current situation in which 90% of the computers are used by people with “Admin” privileges that then makes it far easier for attacks against those boxes to gain complete control once they are so compromised.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April 4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, November 17, 2004 6:52 PM
To: ntdev redirect
Subject: RE: [ntdev] Bluetooth driver stack implementations

If they are not an admin, they cannot touch the filters on a device nor enable/disable a service


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 3:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations

In very rare case, user logs in with account other than root, well in Windows.

Calvin Guan??? Software Engineer??
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: November 17, 2004 4:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
As said many times, if someone is an admin on the box (which is required to muck around w/drivers), you have no security b/c they can disable anything on the machine.
d


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 11:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
Filter for this purpose is probably not solid.
It’s not difficult for average users to remove a filter driver if (s)he really wants to use his Bluetooth or other stuff.

Calvin Guan??? Software Engineer??
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: November 17, 2004 6:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I am probably going to filter above the host controller, maybe even use a
bus filter driver (I would like to implement the driver in a way that will
allow me to know as little as possible about the actual Bluetooth protocol
stack).
One of the many potential purposes is to deny connections, but this is not
where it stops.
Do you think that filtering the WIDCOMM and Microsoft implementations will
cover almost all users ?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 10:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
If you filter below the host controller, the USB HCI is completely
standardized and you can write a filter that covers all USB devices.
Serial is a different story, although H5 should cover it for the most part.
What is the purpose of the filter?? To deny connections?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I plan to write a filter driver for a Bluetooth driver stack (probably for
the Bluetooth Host Controller, or atleast I think this is the right term).
Since I want my filter to work on as many computers as possible and since
there are more then one implementations, it seems I would have to implement
a different filter for each implementation.
Therefore, I must know what implementations exist, and I’m hoping that
WIDCOMM and Microsoft are covering enough users for me to be satisfied with
only being able to filter those implementations.
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 9:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
OK, I’ll bite.? Why is this important?? What are you trying to do?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
So, is it safe to assume WIDCOMM and Microsoft’s implementations are used by
almost all Windows users that require Bluetooth support?
Isn’t there any other implementation which is even close to be widely used?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 7:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
3com’s stack is dead and has been for a long time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Programmers Society
Prokash Sinha
Sent: Tuesday, November 16, 2004 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bluetooth driver stack implementations
3Com had a stack long back (2001 time fram) and it was essentially ESI
(extended system’s joint work with 3Com) stack …
-pro

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

If you can search the ntdev, Long time ago ( sometime this year ) the topic was visited and one of the Conjecture I had is “Trusting Admin is like trusting monkey being our root …” it is not to insult any security model(s), those are well studio by pioneers and was implemented as was necessary at that time, but fortunately things change, and wide use of network makes things worse …

I would much rather prefer compartmentalzation, well for me it is easy to demand or request since I would not have to go thru the trouble of hardwork, but in the future something like that would greatly enhance base level security/privacy etc to ordinary users. And I’m sure oneway or the other future would take that shape ( may be in the form of virtual machine )…

By the way I still hold my conjecture unless proven otherwise :-).

-pro

Well, ok, but if you can install a driver, you can effectively do any of
those other things that the Admin group can do anyway, so isn’t this a
difference that makes no difference?

It seems to me that allowing the “install drivers” privilege outside of
the Admin group would just give you a false sense of security.

Tony Mason wrote:

Sad, but true. This is an unfortunate blindness on how components within Windows use the OS provided security mechanisms - because it would be nice to delegate just certain privileges/operations to a restricted account, rather than concentrating all authority in one account (or one group) as seems to have become the default. Note that this is NOT a restriction on how the Security Reference Monitor works, but rather the naïve insistence in other OS components that all power should be concentrated into a specially nominated group.

For example, you might want to create an account that has the ability to install new devices without the numerous other rights that are inherent in the rights assigned to the Admin Group (for example, Admin Group can override security checks using restore privilege). The current implementation of the Service Control Manager REQUIRES that the request come from the Admin Group - no choice. So you could modify the registry and force a reboot (which is likely to be required for a filter anyway) but you cannot do this in dynamic fashion.

In general, good security policy is to divide up tasks and compartmentalize the security rights to provide only those rights that are required. This has become my current hot-button because I recently spent time trying to figure out how to configure an account that was NOT a member of Admin Group that could install a service and found the SCM restriction. Then I went to figure out how to create a unique service account for interacting with a kernel driver as a counter-point to the hideous “let’s look at the undocumented image name in the EPROCESS” hack and found that I can’t use IoCreateDeviceSecure to create such an SD (with a non-well-known account) and the APIs necessary to do this correctly are not exposed. So, I’m restricted to using an account that is an Admin Group member which means that if I screwed up anything in my service, instead of merely compromising the control over my device, I have compromised the entire box.

The concentration of privileges and propensity for giving people unlimited control over the box to compensate has led to the current situation in which 90% of the computers are used by people with “Admin” privileges that then makes it far easier for attacks against those boxes to gain complete control once they are so compromised.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April 4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, November 17, 2004 6:52 PM
To: ntdev redirect
Subject: RE: [ntdev] Bluetooth driver stack implementations

If they are not an admin, they cannot touch the filters on a device nor enable/disable a service


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 3:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations

In very rare case, user logs in with account other than root, well in Windows.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: November 17, 2004 4:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
As said many times, if someone is an admin on the box (which is required to muck around w/drivers), you have no security b/c they can disable anything on the machine.
d


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 11:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
Filter for this purpose is probably not solid.
It’s not difficult for average users to remove a filter driver if (s)he really wants to use his Bluetooth or other stuff.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: November 17, 2004 6:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I am probably going to filter above the host controller, maybe even use a
bus filter driver (I would like to implement the driver in a way that will
allow me to know as little as possible about the actual Bluetooth protocol
stack).
One of the many potential purposes is to deny connections, but this is not
where it stops.
Do you think that filtering the WIDCOMM and Microsoft implementations will
cover almost all users ?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 10:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
If you filter below the host controller, the USB HCI is completely
standardized and you can write a filter that covers all USB devices.
Serial is a different story, although H5 should cover it for the most part.
What is the purpose of the filter? To deny connections?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I plan to write a filter driver for a Bluetooth driver stack (probably for
the Bluetooth Host Controller, or atleast I think this is the right term).
Since I want my filter to work on as many computers as possible and since
there are more then one implementations, it seems I would have to implement
a different filter for each implementation.
Therefore, I must know what implementations exist, and I’m hoping that
WIDCOMM and Microsoft are covering enough users for me to be satisfied with
only being able to filter those implementations.
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 9:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
OK, I’ll bite. Why is this important? What are you trying to do?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
So, is it safe to assume WIDCOMM and Microsoft’s implementations are used by
almost all Windows users that require Bluetooth support?
Isn’t there any other implementation which is even close to be widely used?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 7:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
3com’s stack is dead and has been for a long time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Programmers Society
Prokash Sinha
Sent: Tuesday, November 16, 2004 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bluetooth driver stack implementations
3Com had a stack long back (2001 time fram) and it was essentially ESI
(extended system’s joint work with 3Com) stack …
-pro

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

But your analysis is flawed then, since we can delegate the ability to start a driver (SeLoadDriverPrivilege) to an arbitrary group or user. Provided I have access to the registry (controlled by the ACL on the Services key), I can create the service key and manually start the driver (ZwLoadDriver). I just cannot do it via the Service Control Manager because it applies a FIXED ACL to its own control object. Of course, I can create the service key and then reboot the system and then the SCM will pick up that registry key anyway.

There are many aspects of security we don’t discuss here, but certainly one principle to keep in mind is that we often try to make things more difficult to achieve just to “raise the bar”. For example, it is impossible to eliminate covert channels from within a system, but we can mitigate their bandwidth. Similarly, we can make it more difficult for an arbitrary attack to beat away at the box. Think of it as similar to the reason we put locks on our windows - the windows CAN be broken, so the locks aren’t really useful and yet it makes it less convenient to break in.

The harsh truth is that most systems are compromised via the users; partial authority to do something often makes it much easier to gain full control. Given that reality, it requires that we add other security features (audits and alarms) to track how the system was compromised.

Within the Windows security model, there is no special (distinguished) magic user. UNIX has the “root” account but while Windows HAS distinguished accounts, you can actually gut those accounts and restrict their privileges (well, perhaps SYSTEM is an exception here, since it represents the local running system itself, but it is not a user level account).

Indeed, your point that once a driver is loaded it can do anything is a valid one and I suspect you’ll see steps in future versions of Windows that try to mitigate against this. For example, perhaps more people will start to use alternate system processes (Services for UNIX does this, for example). Nothing would prevent such alternate processes from having a different set of credentials…

My point however remains: concentrating all security within a single well-known group would seem to be a weakness, not a strength. In many ways this is comparable to mastered key systems on buildings - they seem like a good idea but in fact make the overall system FAR less secure. By concentrating all power in a single group and user account, we simplify the jobs of hackers because they can focus their attention on that one weak spot.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Friday, November 19, 2004 2:22 PM
To: ntdev redirect
Subject: Re:[ntdev] Bluetooth driver stack implementations

Well, ok, but if you can install a driver, you can effectively do any of
those other things that the Admin group can do anyway, so isn’t this a
difference that makes no difference?

It seems to me that allowing the “install drivers” privilege outside of
the Admin group would just give you a false sense of security.

Tony Mason wrote:

Sad, but true. This is an unfortunate blindness on how components within Windows use the OS provided security mechanisms - because it would be nice to delegate just certain privileges/operations to a restricted account, rather than concentrating all authority in one account (or one group) as seems to have become the default. Note that this is NOT a restriction on how the Security Reference Monitor works, but rather the na?ve insistence in other OS components that all power should be concentrated into a specially nominated group.

For example, you might want to create an account that has the ability to install new devices without the numerous other rights that are inherent in the rights assigned to the Admin Group (for example, Admin Group can override security checks using restore privilege). The current implementation of the Service Control Manager REQUIRES that the request come from the Admin Group - no choice. So you could modify the registry and force a reboot (which is likely to be required for a filter anyway) but you cannot do this in dynamic fashion.

In general, good security policy is to divide up tasks and compartmentalize the security rights to provide only those rights that are required. This has become my current hot-button because I recently spent time trying to figure out how to configure an account that was NOT a member of Admin Group that could install a service and found the SCM restriction. Then I went to figure out how to create a unique service account for interacting with a kernel driver as a counter-point to the hideous “let’s look at the undocumented image name in the EPROCESS” hack and found that I can’t use IoCreateDeviceSecure to create such an SD (with a non-well-known account) and the APIs necessary to do this correctly are not exposed. So, I’m restricted to using an account that is an Admin Group member which means that if I screwed up anything in my service, instead of merely compromising the control over my device, I have compromised the entire box.

The concentration of privileges and propensity for giving people unlimited control over the box to compensate has led to the current situation in which 90% of the computers are used by people with “Admin” privileges that then makes it far easier for attacks against those boxes to gain complete control once they are so compromised.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April 4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, November 17, 2004 6:52 PM
To: ntdev redirect
Subject: RE: [ntdev] Bluetooth driver stack implementations

If they are not an admin, they cannot touch the filters on a device nor enable/disable a service


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 3:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations

In very rare case, user logs in with account other than root, well in Windows.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: November 17, 2004 4:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
As said many times, if someone is an admin on the box (which is required to muck around w/drivers), you have no security b/c they can disable anything on the machine.
d


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 11:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
Filter for this purpose is probably not solid.
It’s not difficult for average users to remove a filter driver if (s)he really wants to use his Bluetooth or other stuff.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: November 17, 2004 6:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I am probably going to filter above the host controller, maybe even use a
bus filter driver (I would like to implement the driver in a way that will
allow me to know as little as possible about the actual Bluetooth protocol
stack).
One of the many potential purposes is to deny connections, but this is not
where it stops.
Do you think that filtering the WIDCOMM and Microsoft implementations will
cover almost all users ?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 10:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
If you filter below the host controller, the USB HCI is completely
standardized and you can write a filter that covers all USB devices.
Serial is a different story, although H5 should cover it for the most part.
What is the purpose of the filter? To deny connections?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I plan to write a filter driver for a Bluetooth driver stack (probably for
the Bluetooth Host Controller, or atleast I think this is the right term).
Since I want my filter to work on as many computers as possible and since
there are more then one implementations, it seems I would have to implement
a different filter for each implementation.
Therefore, I must know what implementations exist, and I’m hoping that
WIDCOMM and Microsoft are covering enough users for me to be satisfied with
only being able to filter those implementations.
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 9:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
OK, I’ll bite. Why is this important? What are you trying to do?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
So, is it safe to assume WIDCOMM and Microsoft’s implementations are used by
almost all Windows users that require Bluetooth support?
Isn’t there any other implementation which is even close to be widely used?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 7:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
3com’s stack is dead and has been for a long time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Programmers Society
Prokash Sinha
Sent: Tuesday, November 16, 2004 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bluetooth driver stack implementations
3Com had a stack long back (2001 time fram) and it was essentially ESI
(extended system’s joint work with 3Com) stack …
-pro

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I googled some more and found three more Bluetooth implementations:

  1. XTNDConnect Blue Manager
    (http://resolution.extendedsystems.com/NR/rdonlyres/ely73feuhvv4ksnyteez3sk2
    mxttbwhwxxr3jli7i5fy6tblipyqdqprbtjb5kvsakstodcs7dcgiepsmuyjsgj44oc/XCBlueMa
    nager0403.pdf)
  2. IVT BlueSoleil
    (http://www.ivtcorporation.com/products/bluesuit/index.php)
  3. Toshiba Bluetooth stack for Windows

Can someone tell me how commonly used these implementations are ?

Thanks,
Shahar.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 9:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations

So, is it safe to assume WIDCOMM and Microsoft’s implementations are used by
almost all Windows users that require Bluetooth support?
Isn’t there any other implementation which is even close to be widely used?

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 7:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations

3com’s stack is dead and has been for a long time.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Programmers Society
Prokash Sinha
Sent: Tuesday, November 16, 2004 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bluetooth driver stack implementations

3Com had a stack long back (2001 time fram) and it was essentially ESI
(extended system’s joint work with 3Com) stack …

-pro


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@safend.com To unsubscribe
send a blank email to xxxxx@lists.osr.com