“Curiouser and curiouser,” said Alice. “I wonder what all these security bulletins are for?”
That was how I felt this morning, seeing that a sea of Apple security announcements had dropped into my inbox overnight.
But a quick visit to
Software Update on my iPhone took just a couple of seconds to confirm:
Your software is up to date.
I had a similar outcome on my Mac when I went
About This Mac →
On reaching my desk at Sophos HQ, the mystery deepened when I was asked to comment on the newly-published Carnegie Mellon’s CERT Vulnerability Note VU#304725, detailing a security hole dubbed CVE-2018-5383.
The CVE-2018-5383 bug has the full and imposing title:
Bluetooth implementations may not sufficiently validate elliptic curve parameters during Diffie-Hellman key exchange.
Simply put, a crook who is in the right place at the right time might be able to figure out the encryption key that one of your Bluetooth devices is using to talk to your laptop, or your bicycle computer, or your phone, or whatever it’s paired with.
This sounds serious – presumably, this sort of bug could allow crooks to listen to, or even to interfere with, data coming out of your Bluetooth devices, from heart rate monitors and bicycle power meters all the way to mice and keyboards.
Sniffed-out keyboard data could be used to get hold of passwords you just typed in; modified keyboard transmissions could be used to alter data you’d just entered, leaving you with wrongly-edited documents or taking you to websites you never intended to visit.
Diffie-Hellman is more correctly called Diffie-Hellman-Merkle (DHM) after its three co-inventors. Martin Hellman himself has urged that Ralph Merkle’s name ought to be included, and we agree, so DHM is how we shall refer to it here.
Sharing secret keys securely
Diffie-Hellman-Merkle was a breakthrough when it was published in the 1970s, because it was the first public and practical algorithm for sharing secret encryption keys without needing a pre-existing secure channel.
Imagine where internet commerce would be without a system like DHM – every time you wanted to do business with someone online, you’d have to visit their offices first with a USB drive so you could securely collect the encryption keys to use when you got back home.
In theory, even if crooks can intercept all the network data that’s exchanged at the start of a network session by a correctly implemented DHM algorithm , they won’t learn enough to be able to figure out the encryption key agreed upon for that session.
In other words, the crooks won’t subsequently be able to eavesdrop on or to tamper with the traffic that’s exchanged, even if they were there and listening in right from the start.
But CVE-2018-5383 is an implementation flaw discovered by Israeli cryptographers Lior Neumann and Eli Biham – some Bluetooth firmware has bugs that get in the way of the anti-snooping/anti-tampering properties of DHM.
A crook within Bluetooth range might be able to interfere with the device connection process – what’s called a Man-in-the-Middle, or MiTM, attack – in such a way as to extract the secret encryption key that each end of the Bluetooth session just agreed on.
What to do?
According to Carnegie Mellon’s vulnerability notice, Apple, amongst others, only published an update for this bug on 2018-07-23 – the date that the vulnerability was publicised, and the date of Apple’s latest wave of security bulletin emails.
Yet Apple’s own products will report that “your software is up to date” if you try to get this apparently important fix.
That’s because Apple’s latest security bulletin isn’t announcing that a fix is available, merely that this issue was already fixed – in the update before last, in fact, namely when iOS 11.4 and macOS 10.13.5 came out. (Current Apple version numbers are iOS 11.4.1 and macOS 10.13.6.)
So, it looks as though 2018-07-23 was merely the pre-arranged date for talking publicly about CVE-2018-5383, rather than the date at which vendors started fixing it.
Are you safe?
According to Cargnegie Mellon’s chart, Bluetooth code from Android, Microsoft and Apple is either already updated or was never affected…
…but you will need to check with your phone vendor or mobile carrier to make sure that the patches added to the Android Open Source Project have made their way to your handset.
In the meantime:
- To exploit this vulnerability, crooks need to be in range when you first connect to a Bluetooth device. As far as we can see, they can’t start snooping on a device that’s already connected, which limits the extent of any attacks.
- If you’re not using Bluetooth, turn if off. You’ll save battery and avoid any sort of unwanted pairings or connections, as well as neutralising any cryptographic attacks that might exist. You’ll also avoid inadvertently broadcasting your Bluetooth hardware address, a detail that makes you easier to track.
5 comments on “The Bluetooth “device snooping bug” – what you need to know”
But what about those products that are not ‘smart phones’ but still use Bluetooth connections? Millions of laptops and tablets use Bluetooth and few run Apple’s iOS. Many run Windows ranging from W7 through W8.1 to W10. Others use various flavours of Android, some bespoke and some going back as far as v4 and cannot be updated to newer versions.
The Duck’s article reports mainly on hpw Apple products might be affected but such users are actually a small minority, but they have the same right to be safe and secure.
I did mention both Android and Windows in the article, along with Apple, as well as presenting the chart that Carnegie Mellon published in its vulnerability note. My mention of Apple at the start of the article was merely by way of revealing how confusing this issue has turned out to be.
Apple – apparently fixed since start of June but only announced as fixed yesterday. Android – patched in AOSP (the open source tree) but consult your vendor/carrier for specifics on your device. Microsoft – apparently not affected in the first place.
Bluetooth. the way in, or is it?
Are you protected if one device in the pair has a vulnerable implementation but the other is patched/invulnerable? This would really be a nightmare if we need to figure out how to patch every Bluetooth peripheral that exists!
TBH, I am not sure – I couldn’t find more detail that Carnegie Mellon had given out. I had somehow formed the opinion that you needed to patch the end that periperhals would pair with and then connect *to*, e.g. your laptop, mobile phone, tablet. But now I am not sure what made me think that. For all I know it might be that *both* ends need to be vulnerable for the hack to work and therefore patching either end might be enough…