Date: Tue, 31 Jan 2006 10:22:05 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth security Message-ID: <43DFAACD.5040802@savvis.net> In-Reply-To: <1138708994.303189.24314.nullmailer@galant.ukfsn.org> References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain,
> 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
thanks.
> 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
> searches)
correct
> 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 ...
[.skipped.]
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).
*/
int
ng_l2cap_lp_con_ind(ng_l2cap_p l2cap, struct ng_mesg *msg)
{
...
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43DFAACD.5040802>