netdev - Re: Bluetooth fixes for 2.6.27

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Sep 2008 04:04:02 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: Bluetooth fixes for 2.6.27

Hi Dave,

>> The second patch fixes the authentication requirements. We do have to
>> separate between service discovery and actual profile channels.  
>> This is
>> a clear requirement of the Bluetooth Security Mode 4 introduced  
>> with the
>> addition of the Simple Pairing support. Not fixing this will result  
>> in
>> broken behavior when doing service discovery with Simple Pairing  
>> enabled
>> devices.
>
> What regression reported by a user is fixed by this?
>
> This does not look like it is appropriate outside of the merge window.

the regression is that with Bluetooth 2.0 and before we always were  
allowing service discovery (SDP) connection without any bonding  
requirement. This is still true, but with Bluetooth 2.1 enabled  
devices it can now happen that we have to do a full pairing procedure.  
For SDP it should be at least using pairing with a just-works model  
with the no bonding requirement, while the other PSM channels (RFCOMM,  
BNEP etc.) should use generic bonding. We would now always use generic  
bonding (even for SDP).

The number of users are still limited to a few people actually testing  
with 2.1 hardware. These are mainly people working on 2.1 enabled  
products. However with the new MacBooks and the EeePC 901 we do have  
devices with Bluetooth 2.1 chips available for everybody.

This is clearly an oversight on my hand when developing the initial  
Simple Pairing patches that I submitted for 2.6.27-rc1 and I only  
found it when we tested against the official Bluetooth 2.1 test system.

This patch also fixes the issue when we for example wanna connect a  
BNEP connection with a 2.1 device. The requirement is that this has to  
be secure. However without this patch it pairs it during ACL  
connection setup and then again to ensure the man-in-the-middle  
protection. This decreases the connection setup time since the 2.1 key  
generation procedure takes 3-5 seconds and doing this twice is an  
significant penalty compared to 2.0 and before devices.

I think it is appropriate outside the merge window, but if you don't  
think so, I gonna pull that patch and only submit the other two.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html