Billions of devices imperiled by new clickless Bluetooth attack (ars technica) [LWN.net]

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 12, 2017 22:05 UTC (Tue) by karkhaz (subscriber, #99844) [Link] (9 responses)

...so cellphone manufacturers removing the 3.5 mm audio plug and forcing people to have Bluetooth turned on all the time _wasn't_ a fantastic idea, you say?!

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 12, 2017 22:42 UTC (Tue) by intgr (subscriber, #39733) [Link] (5 responses)

> cellphone manufacturers

Implying there's more than one?

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 0:03 UTC (Wed) by karkhaz (subscriber, #99844) [Link] (1 responses)

Lenovo/Motorola: https://www.motorola.com/us/products/moto-z

HTC: https://www.htc.com/uk/smartphones/htc-u11/

(search both those pages for "adapter").

Point taken from the commenter below mentioning that iOS 10 isn't vulnerable, but I wouldn't have been so worried about Apple products even if it was---I believe they do get timely updates. Devices running android, like the above two, are a different story.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 18:22 UTC (Wed) by markhb (guest, #1003) [Link]

The U11 supports audio via the USB-C port; it doesn't require Bluetooth for that use case. (For private listening while charging, perhaps :)

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 17:38 UTC (Wed) by rfunk (subscriber, #4054) [Link] (2 responses)

Almost every new or upcoming flagship phone lacks the headphone jack. Including Google's Pixel 2. It seems that new phones with a headphone jack are the exception, rather than the rule like a year ago.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 21:13 UTC (Wed) by jengelh (subscriber, #33263) [Link] (1 responses)

>It seems that new phones with a headphone jack are the exception, rather than the rule like a year ago.

I think we are still good for now. List from Techradar Top 10 2017-07-28, specs from GSM Arena:
10. LG G6 - jack, 9. Pixel - jack, 8. HTC U11 - fail, 7. Xperia XZ premium - jack, 6. Motorola Moto Z - fail, 5. Galaxy S8+ - jack, 4. iphone 7 - fail, 3. OnePlus 5 - jack, 2. iphone 7+ - fail, 1. Galaxy S8 - jack.

A 40% failure rate is surely not reassuring, but I think I am not a target for Apple anyway, and Motorola I can mentally mask out.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 21:47 UTC (Wed) by rfunk (subscriber, #4054) [Link]

The Pixel is due to be replaced next month, and all the leaks say that the Pixel 2 won't have a headphone jack. Now we're down to 50%, and trending the wrong direction. (Though at least LG's more recent V30 still has a headphone jack.)

Personally I won't consider Apple or Samsung right off the bat, and in general I can't be confident that a OnePlus or a Sony will work on my carrier (Sprint, FWIW). There are only so many brands that make phones that work everywhere.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 12, 2017 23:37 UTC (Tue) by ssmith32 (subscriber, #72404) [Link] (1 responses)

I don't follow apple too closely, but by the time they removed the jack (and they're the only ones I know of that did), they were on ios10, which is not vulnerable (buried in the article is the fact that ios is also vulnerable pre-ios10.. to be fair, though I don't think ios9 is terribly widespread now...)

Not sure about cars. Probably rife with other vulns, if not this one...

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 5:49 UTC (Wed) by marcH (subscriber, #57642) [Link]

> though I don't think ios9 is terribly widespread now...)

It all depends for how long people keep their iPhone and/or iPad: http://iossupportmatrix.com/
Not every Apple customer is a tech fashion addict. I know people whose device is too old to be supported by iOS 10.
While generally better than Android, iOS devices don't get infinite support either.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 1:44 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

Just add it back on:

https://strangeparts.com/bringing-back-the-iphone-headpho...

:D

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 8:20 UTC (Wed) by danpb (subscriber, #4831) [Link] (7 responses)

The impact of the flaw is bad, but isn't quite as severe as the article makes out. For any kernel that is built with CONFIG_CC_STACKPROTECTOR=y, the remote code execution capability is believed to be downgraded to "merely" a remote crash aka denial of service. Still bad, but at least it won't turn your system into part of a botnet

https://access.redhat.com/blogs/product-security/posts/bl...

Most major Linux distros should have this kernel config option enabled (article says Fedora >= 5, RHEL >= 6). So the worst impact is probably for embedded systems which have bluetooth hardware (eg Cars with bluetooth audio integration), but whose vendors didn't enable the stack protector kernel option.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 10:40 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (1 responses)

Stack canaries are a statistical mitigation. How big is the canary? If we crash whenever the attacker guesses wrong a 32-bit canary is enough to feel statistically protected, but if we were to instead catch this and carry on (or if we're a device with a hardware watchdog which will merely reset when crashed) then guessing the canary in reasonable time becomes merely unlikely - not so astonishing as to be negligible. Particularly in the "catch and carry on" case we might imagine an attacker can try many thousands of times per hour, quickly eroding our mitigation.

its a buffer overflow

Posted Sep 13, 2017 12:20 UTC (Wed) by johnjones (guest, #5462) [Link]

so yes its basically like wifi,

there is a buffer overflow in some versions of windows/linux/iOS

this has been patched in all the OS's
its not a replicating worm per se unless you count all the people who have downloaded an "app" to check if they are vulnerable...

the videos and documentation on their website give absolutely no details and completely pointless, this is what happens when you let a media company deal with a buffer overflow

Actual information :

Background Information
The Logical Link Control and Adaptation Layer Protocol (L2CAP) works at the data link layer in the Bluetooth stack. It provides services such as connection multiplexing, segmentation and reassembly of packets for upper layer protocols such as Bluetooth. It facilitates higher level protocols to transmit and receive L2CAP data packets to and from clients.

A stack buffer overflow issue was found in various systems Bluetooth subsystem processing the pending configuration packets received from a client. As a result, a client could send arbitrary L2CAP configuration parameters which were stored in a stack buffer object. These parameters could exceed the buffer length, overwriting the adjacent kernel stack contents. This exchange occurs, prior to any authentication, when establishing a Bluetooth connection. An unauthenticated user, who is able to connect to a system via Bluetooth, could use this flaw to crash the system or potentially execute arbitrary code on the system if not secured correctly. if the Linux kernel stack protection feature (CONFIG_CC_STACKPROTECTOR=y) is on then your not going to be vulnerable.

Not impressed with the press release at all I'm afraid

It does show which vendors of equipment pay attention, develop patches and deserve respect

Regards

John Jones

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 1:45 UTC (Thu) by thestinger (guest, #91827) [Link] (3 responses)

> the remote code execution capability is believed to be downgraded to "merely" a remote crash aka denial of service

Stack canaries can be leaked via a memory disclosure vulnerability and then it can be bypassed. The same canary value is in every stack frame on the thread's stack. Their proof of concept was demonstrated against a Google Pixel which has -fstack-protector-strong for the kernel. Stack canaries aren't a deterministic mitigation, they rely on the low probability of guessing the secret value, but that secret value can be leaked. It's copied all over the stack, not just in TLS or a global.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 4:01 UTC (Thu) by eru (subscriber, #2753) [Link] (2 responses)

> The same canary value is in every stack frame on the thread's stack.

There are stack canary implementations where this is not the case. The original StackGuard already supported randomizing: https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/full_papers/cowan/cowan_html/node6.html. Of course, having to pick a different value in each function makes it a bit slower.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 4:21 UTC (Thu) by thestinger (guest, #91827) [Link] (1 responses)

CONFIG_CC_STACKPROTECTOR / CONFIG_CC_STACKPROTECTOR_STRONG are the only form of stack canaries supported by the mainline Linux kernel, i.e. the SSP implementation in GCC and Clang. It has per-thread random values for some environments, but most non-x86 environments are stuck with a global random value.

There are better implementations of canaries and other more modern mitigations but they aren't what was being discussion. I wasn't responding to a comment about SafeStack, CFI, XOR canaries, finer-grained canaries or other mitigations. It was claimed that CONFIG_CC_STACKPROTECTOR (SSP) makes this unrealistic to exploit, which I think is far from true, and the proof of concept was done against a system with a kernel compiled with -fstack-protector-strong.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 4:25 UTC (Thu) by thestinger (guest, #91827) [Link]

s/being discussion/being discussed/

If and when they release their PoC exploit(s), we'll see how they bypassed stack canaries. Claiming that it makes it infeasible to exploit is a claim that they're lying about having working exploits for those systems... and I think that's unfair at this point. There's no reason to think that they couldn't find an information leak either letting them read the value from the global (would work fine with a finer-grained implementation too) or from the stack.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 6:18 UTC (Thu) by mjthayer (guest, #39183) [Link]

I seem to recall hearing a couple of years ago that bluetooth in cars tended to be home-brew proprietary stacks. Does anyone know more about that?

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 8:30 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]

While the paper focuses on host side implementations in the major OSs i'm more worried by the various embedded devices and modules.

Peripheral devices like health monitors and some USB bluetooth dongles merge the host and controller parts of the bluetooth stack in the device and include a full BT / BTLE stack inside, right up to the GATT layer.

They either expose an internal API with a manufacturer defined application linked with the stack and flashed to the device or provide a proprietary host interface to the top of the stack (like AT commands or the bluegiga "BGAPI") over a serial link.

Unlike the major host OS implementations these are quite unlikely to be updated once shipped...

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 13, 2017 10:39 UTC (Wed) by eru (subscriber, #2753) [Link] (1 responses)

Article: The researchers consider three of the flaws to be critical. The researchers reported them to Google, Microsoft, and Apple in April and to Linux Maintainers in August.

I wonder why Linux maintainers were notified so much later?

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 7:39 UTC (Thu) by jsegitz (subscriber, #102650) [Link]

probably because they don't offer long embargoes

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 12:45 UTC (Thu) by janc (guest, #95095) [Link] (2 responses)

Most devices are not discoverable all the time and attacker need to know BT address. This means that "developing a self-replicating worm that would spread from a single device to other nearby devices that had Bluetooth turned on, and from there those devices would infect other nearby devices in a chain reaction" is a bit exaggerated.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 17:32 UTC (Thu) by alonz (subscriber, #815) [Link]

The researchers do mention this in their whitepaper; they also point out that if the device has any active Bluetooth-classic connections, the packet headers leak 24 bits of the BDADDR.
The researchers also point out that WiFi scans can leak the full BDADDR, which is true for many devices — the WiFi MAC and Bluetooth BDADDR are often closely related. WiFi MAC randomization somewhat helps here, but it's far from a panacea.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 15, 2017 18:17 UTC (Fri) by Wol (subscriber, #4433) [Link]

I *think* my phone actually disables bluetooth - it times out - so I have to switch it on every time I want to use it. Not bad - decent energy savings :-)

Cheers,
Wol

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 19:30 UTC (Thu) by ssmith32 (subscriber, #72404) [Link] (5 responses)

Just a note - it looks like Armis has provided an app to check if your particular phone is vulnerable - since the article was notably vague on what update would fix this. And the updates you do get, on Android, have always been a bit vague...

(The bluetooth process they exploited is launched by zygote - but I'm not sure if that's updated as part of a normal update, or an OTA firmware update??).

I'm running a self-purchased, unlocked Nexus 5X on T-Mobile, (pretty sure that means I get my updates from Google) and it hasn't been updated yet..

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 19:41 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]

Ahaha! After some digging around, I found a note at the bottom of this:

https://source.android.com/security/bulletin/2017-09-01

That the Sept security updates would be shipped as part of the upgrade to Oreo.

Note that the reading is a little depressing. There are a number of "remote code execution in a privileged process" vulns. This particular one is not even considered "remote". It is listed as "proximate".

I guess the other ones didn't get flashy press releases? I dunno....

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 14, 2017 20:35 UTC (Thu) by excors (subscriber, #95769) [Link] (3 responses)

Zygote isn't particularly relevant - it's just the process that launches all Java-based apps and services, including system ones and user ones. (It initialises the VM and a bunch of standard classes and other widely-used resources, then every new app is launched by forking Zygote and running the app code in the new child process. That reduces app startup time, and reduces memory usage since read-only data (like the standard classes) is shared by all apps.)

Apparently the vulnerability is in native code that I expect gets compiled into somewhere like /system/lib/hw/bluetooth.default.so (if I'm reading the build scripts correctly), and gets loaded by the Java-based Bluetooth service (via JNI and some more interface layers) which is probably /system/app/Bluetooth.apk. Everything in /system is part of the firmware, and might be arbitrarily customised by the vendor (so even if Google could push security updates through the Play Store, they don't actually have the source code for those libraries (except on Nexus/Pixel devices)), so it can only be fixed in an OTA update.

If your phone is no longer getting OTA updates, throw it away and buy a new one.

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 15, 2017 2:18 UTC (Fri) by ssmith32 (subscriber, #72404) [Link] (2 responses)

Thanks for the explanation!

My phone is getting OTA updates, I just meant that it hasn't got the update for this vuln.

I have a vanilla Nexus 5X, looks like the last updates for those were on Aug 5th, 2017.
At least on T-Mobile...

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 15, 2017 20:59 UTC (Fri) by ssmith32 (subscriber, #72404) [Link]

So I signed up for the Android developer preview / beta program, and grabbed the OTA for Oreo - Armis app still reports that I'm vulnerable.

So prolly just have to wait for the official build that bundles all the new fixes in...

Billions of devices imperiled by new clickless Bluetooth attack (ars technica)

Posted Sep 15, 2017 22:37 UTC (Fri) by bronson (subscriber, #4806) [Link]

Be very careful to back up your 5X... Last week mine bootlooped without warning. It's a known deficiency in a few LG phones: one day it just won't finish booting.

Luckily I only lost a neat video of my kid from the day before.