Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bluetooth security


          I have a concern about FreeBSD bluetooth security that I can't
really evaluate (since I'm not running FreeBSD) but I thought I'd let you


know. I have been writing a bluetooth protocol code for NetBSD and I have
looked at your code for reference though the NetGraph entanglement makes
it unuseable for me. I am using most of your userland code with few

yes, i've been following (not very closely) your work. since netgraph did not make it to other bsd's (for various reasons), i've been considering to un-netgraph freebsd stack for quite some time. unfortunately, i do not have any time to do this :(

changes though which is saving me lots of work (thanks :)

sure. common bluetooth api for all bsd's would be ideal. i'm willing to work in this area. if you have any suggestions to that would make it easier to share the code please let me know.

This is my reasoning:

Incoming connections are approved automatically at the HCI level, so if
bluetooth is enabled then connections are opened automatically.

yes, if you are talking about acl and sco (and i assume by "approved" you mean accepted).

Yes, pscan can be turned off and an attacker needs to know your bdaddr if
you do not have iscan enabled (though, there are tools to do brute force


Once an ACL connection is up, then I dont think its possible to filter
L2CAP connections based on bdaddr? This means that the L2CAP engine is
available to all intruders.

you are correct, l2cap does not deal with this scenario. however, it not that bad. there are two options here:

1) use "write_authentication_enable" hci command. this command can be used to turn authentication globally on device. what it means is that device will try to request authentication at the time of baseband (acl) connection establishment. "authentication" means that devices must have common link key (or pin code). if, for whatever reason, link key or pin code does not match the baseband connection will not be established. that is what hcsecd(8) is for. it listens for "link_key_request" or "pin_code_request" hci events and consults its local database to give out the answers.

2) at _any_ moment device can issue "authentication_requested" command on already established baseband (acl) link. this will trigger the same link key/pin code exchange sequence. after the sequence is complete the "authentication_complete" hci event is sent, and, depending on result (success or failure) the baseband connection may be terminated.

note: (2) is not implemented in the freebsd stack.

At this point, the configuration starts and I noticed that ...


could you please send me another (private) email with more details regarding this? if possible could you provide some examples?

I was working on this late last year and have only just got back to it, so
sorry if I can really do any more than wave a vague impression at you.
Frankly this would be a very obscure attack method, but still, I thought
I'd let you know that I thought of it and I'm no cracker. It might be
worth looking at one day when your child is asleep..

thanks for letting me know. i will look into this. again it would be helpful if you could give me more details (in private email).

Partly for this reason, I have chosen to have ACL connections for NetBSD
accepted via the hcsecd userland daemon as while it does not currently
have the capability, some kind of hosts allow/deny capability can be added
and thus anybody concerned about security could lock out unknown devices.

well, you could do that, but, frankly, i do not think this is required. i was thinking about the same too. that is why i put the following comment in the ng_l2cap_llpi.c

* Process LP_ConnectInd event from the lower layer protocol. This is a good * place to put some extra check on remote unit address and/or class. We could
 * even forward this information to control hook (or check against internal
* black list) and thus implement some kind of firewall. But for now be simple
 * and create new connection descriptor, start timer and send LP_ConnectRsp
 * event (i.e. accept connection).

ng_l2cap_lp_con_ind(ng_l2cap_p l2cap, struct ng_mesg *msg)