From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jan 31 18:22:37 2006 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1512316A422 for ; Tue, 31 Jan 2006 18:22:37 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C58343D60 for ; Tue, 31 Jan 2006 18:22:35 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id k0VIM8M15210; Tue, 31 Jan 2006 13:22:08 -0500 Message-ID: <43DFAACD.5040802@savvis.net> Date: Tue, 31 Jan 2006 10:22:05 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iain Hibbert References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org> In-Reply-To: <1138708994.303189.24314.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth security X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 18:22:37 -0000 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) { ... } From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jan 31 19:09:25 2006 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3A4616A420 for ; Tue, 31 Jan 2006 19:09:25 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 0F65443D48 for ; Tue, 31 Jan 2006 19:09:24 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: (qmail 57560 messnum 11065182 invoked from network[83.70.176.191/unknown]); 31 Jan 2006 19:09:22 -0000 Received: from unknown (HELO rya-online.net) (83.70.176.191) by mail11.svc.cra.dublin.eircom.net (qp 57560) with SMTP; 31 Jan 2006 19:09:22 -0000 Received: (nullmailer pid 14754 invoked by uid 1000); Tue, 31 Jan 2006 19:09:21 -0000 Date: Tue, 31 Jan 2006 19:09:21 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: <43DFAACD.5040802@savvis.net> References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org> <43DFAACD.5040802@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1138734561.599404.4457.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth security X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 19:09:25 -0000 On Tue, 31 Jan 2006, Maksim Yevmenkin wrote: > > 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. One of the first issues that I found was that when you wrote the include files, you used NG_ and ng_ prefixes on all the HCI and L2CAP definitions and structures. This seemed unnecessary since HCI and L2CAP defs are not really NetGraph related - I have used your include files hci.h and l2cap.h more or less directly apart from this. The biggest choice I made that intentionaly breaks compatibility is that I chose to have bluetooth address family socket address consistent through the family (ie a single struct sockaddr_bt for all AF_BLUETOOTH sockets) - this means so far that HCI sockets use the bdaddr instead of device name and that L2CAP sockets must set the PSM via setsockopt() but I have to say, that converting the FreeBSD userland libs & utilities was pretty much a noop even after those differences. I haven't especially looked at anything more, am starting work on a RFCOMM layer soon. > > 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 That may be where I got the idea from, it just seemed logical to have the functionality in a single security guard at the gate (who are you? ok - have you a pass? no! whats the code? ok in you come..) how many people use bluetooth for incoming connections and do not enable the hcsecd daemon? regards, iain From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jan 31 19:50:48 2006 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8948816A420 for ; Tue, 31 Jan 2006 19:50:48 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7030643D62 for ; Tue, 31 Jan 2006 19:50:40 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id k0VJoaM17551; Tue, 31 Jan 2006 14:50:36 -0500 Message-ID: <43DFBF8A.7040606@savvis.net> Date: Tue, 31 Jan 2006 11:50:34 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iain Hibbert References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org> <43DFAACD.5040802@savvis.net> <1138734561.599404.4457.nullmailer@galant.ukfsn.org> In-Reply-To: <1138734561.599404.4457.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth security X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 19:50:48 -0000 Iain, >>>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. > > One of the first issues that I found was that when you wrote the include > files, you used NG_ and ng_ prefixes on all the HCI and L2CAP definitions > and structures. This seemed unnecessary since HCI and L2CAP defs are not > really NetGraph related - I have used your include files hci.h and l2cap.h > more or less directly apart from this. yes, i was thinking about moving most of the includes into include/bluetooth or something like that. the naming convention is an artifact of very early stage of development (when the code was developed outside of the freebsd source tree) > The biggest choice I made that intentionaly breaks compatibility is that I > chose to have bluetooth address family socket address consistent through > the family (ie a single struct sockaddr_bt for all AF_BLUETOOTH sockets) - > this means so far that HCI sockets use the bdaddr instead of device name > and that L2CAP sockets must set the PSM via setsockopt() may i ask why did you make this decision? > but I have to say, that converting the FreeBSD userland libs & utilities > was pretty much a noop even after those differences. I haven't especially > looked at anything more, am starting work on a RFCOMM layer soon. ok >>>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 > > That may be where I got the idea from, it just seemed logical to have the > functionality in a single security guard at the gate (who are you? ok - > have you a pass? no! whats the code? ok in you come..) > > how many people use bluetooth for incoming connections and do not enable > the hcsecd daemon? i *always* recommend to run hcsecd(8) if bluetooth is used. changes are that hcsecd(8) will be required. even though authentication is off by default in freebsd, it still may be required. _either_ device may request authentication. even if accepting device has authentication off, but remote device has authentication on the authentication sequence will be performed anyway. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jan 31 22:33:20 2006 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6F3716A422 for ; Tue, 31 Jan 2006 22:33:20 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by mx1.FreeBSD.org (Postfix) with SMTP id EC70C43D6B for ; Tue, 31 Jan 2006 22:33:16 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: (qmail 52925 messnum 4214467 invoked from network[83.70.176.191/unknown]); 31 Jan 2006 22:33:15 -0000 Received: from unknown (HELO rya-online.net) (83.70.176.191) by mail13.svc.cra.dublin.eircom.net (qp 52925) with SMTP; 31 Jan 2006 22:33:15 -0000 Received: (nullmailer pid 15027 invoked by uid 1000); Tue, 31 Jan 2006 22:33:15 -0000 Date: Tue, 31 Jan 2006 22:33:15 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: <43DFBF8A.7040606@savvis.net> References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org> <43DFAACD.5040802@savvis.net> <1138734561.599404.4457.nullmailer@galant.ukfsn.org> <43DFBF8A.7040606@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1138746795.375218.15473.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth compatibility X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 22:33:21 -0000 On Tue, 31 Jan 2006, Maksim Yevmenkin wrote: > yes, i was thinking about moving most of the includes into include/bluetooth > or something like that. the naming convention is an artifact of very early > stage of development (when the code was developed outside of the freebsd > source tree) in a way its not that important - the values are the same and basic HCI definitions can be represented in a compatibility file (I think you have one such for BlueZ?) Well I have include files in netbt/ which makes sense for NetBSD (also OpenBSD) not sure though that FreeBSD (and DragonFly BSD?) have the same directory structure any more? In fact I noticed that you include all the other files from within anyway which I may end up doing - that way user programs only need to include the one file and less changes need to be made when porting software. > > The biggest choice I made that intentionaly breaks compatibility is that I > > chose to have bluetooth address family socket address consistent through > > the family (ie a single struct sockaddr_bt for all AF_BLUETOOTH sockets) - > > this means so far that HCI sockets use the bdaddr instead of device name > > and that L2CAP sockets must set the PSM via setsockopt() > > may i ask why did you make this decision? Well I considered that the socket address is identified by the family, therefore it should have the same type of address throughout at least. You can look at the sa_family type and know how to interpret it. Also, addresses can be passed up and down the stack layers without problems (dont know how useful that will be) regarding the PSM, when I got to it I thought that possibly it could be in the sockaddr_bt (and just be ignored for HCI) as you may need to set an PSM for protocols other than L2CAP that you might access through another socket type. Actually this is something that is simple to change in the future so I just left it for now regards, iain