Critical Bluetooth vulnerability in Android

watches the plan fail yet again

This is like saying "we dont need regulations in meat packing, every individual can become educated in butchery cleanliness and track the supply chains for the products they buy and everything will be better!"

Also FWIW, the problem has zilch to do with "Android" per se - pre-Android mobile Linux was even worse. It's embedded platforms in general.

Having a "standard" OS interface for the phone, where there is just one OS image for a given OS version, and that image could be installed on any phone - now that would be the true alternative, which I would be delighted to vote for with my wallet.

That means there is no Android or Apple device on the market today that accomplishes what you say.

The only phones that are out there that can do that are the Pinephone and Librem 5. I have beta devices of both, and while I am extremely excited to see them mature and turn into daily drivers, the fact is neither can actually be a daily driver today.

Can you name one smartphone device with open internals? I'd love to buy one, but I don't think they exist. From Replicant's recommendations [1]:

If compromising on privacy/security is not an option, or anything serious is at stake (e.g. political activism or journalism in a sensitive area), it is advised to avoid using a telephony-enabled device at all.

My impression from the smartphone market is that phone platforms have become less open, not more, over the last ten years. The PinePhone isn't generally available yet, and the Librem 5 current iterations don't have working audio calls.

[1] https://www.replicant.us/freedom-privacy-security-issues.php...

* The barrier of entry is very high: You need a top-tier manufacturing system and supply chain. An operating system. An entire suite and market of applications. All of the apps users expect and rely on (mail, navigation, Facebook, chat, Instagram, etc.) must be supported. The hardware is only profitable if you manufacture at very high scale.

* Information asymmetry is very high. Users have almost no insight into how secure one platform is versus another. In fact, they have access to paradoxical information. The most secure platforms are the ones with the most transparent security flaw handling, but those are also the ones that appear the least secure because the vulnerabilities are more widely reported.

* Products are nowhere near commoditized. A phone is a very large constellation of hardware, operating system, and software features. There is no apples to apples comparison between phones. Maybe you like the camera on one but not the screen on the other. One has better apps but the other a more stable OS.

This is not a market where consumer choice will effectively drive solutions to diffuse problems.

"Voting with your wallet" only leads to good outcomes if the incentives are right. I mean it's money, the VAST majority of it is spent not for the greater good but for small, inefficient egotistical purposes.

While scanning for devices, a phone reveals the Mac address. There are other ways to know the Mac address too.

Still the biggest problem. For my PC I can install updates on a daily basis. For my smartphone, I can be happy if there are any updates at all.

When you can make a ridiculous profit on a flagship phone and sell it for $500-700 (say, a OnePlus, for a good example), but they sell it for $800-1400 (Samsung, Apple, et al), then what am I paying for? It's supposed to be for better support and a smoother experience when things go wrong.

You know who has historically stabbed me in the back the least? OnePlus. I'm not going to say it has been perfect, but for a phone I spent $550 on, they've screwed me far less times than other alternatives would have.

So, we are paying for the patches to be delivered on a meaningful schedule for more than 3 years. I seem to be getting it what I paid for, and you don't.

There is something massively wrong with this picture.

I remember the times of endless tweaking and patching after some Google Play services update a few years ago.

It's unreliable by definition. You're better off keeping a device around with the stock OS on it, that you only use for SafetyNet-required stuff.

Recently the wire of my regular ear buds gave up (as they do) and, since I had gotten some BT ones, I decided to use them. They're Jabra Elite Sport, which got good reviews from what I can recall.

They're dropping out like crazy. It's seldom to get an entire minute of music without a small dropout. The area around the bus stop at work is particularly bad, with sound drops every few seconds until I get away from that area.

I upgraded the firmware and it got a bit better, but still pretty poor. If I hold the phone in my hands and keep still it's usually ok, but as soon as it goes into my pocket, all bets are off.

I don't miss the cable tangle, but I miss being able to enjoy music.

Playing the movie is going to use enough battery that I'd like to be plugged in. The dongles are easy to lose. I don't have a set of bluetooth headphones that I use regularly, so I got a pair at the airport, but i need to remember to charge them, and they also don't last for the whole movie. Also, everybody using bluetooth probably contributes to the janky streaming in flight.

Characteristic impedance alone is all over the map, Apple apparently couldn't align its 3.5mm jack pinout with the rest of de facto industry, and form factor is just one of many inherent market differentiators.

This part looks very different if the attack is a worm.

How many phones are not in reach of another vulnerable phones at least once a workday?

Learning Rust and with its concepts improved my C code. Even if Rust would vanish over night I wouldn't regret learning it.

I guess you are talking about the first commit I linked. The problem here seems to be that some events of the kind HCI_READ_RMT_EXT_FEATURES_COMP_EVT can be shorter than the assumed 13 bytes. The code contains no check for that and if the events are shorter, it would read data from after the allocation. It would use that data to index inside arrays, etc.

Now, if you just allocate a buffer of 256 entries but don't do anything else, it wouldn't read data from outside the allocation, yes, but it would still read uninitialized data, as nothing would be written after the end of the valid data. That uninitialized data could e.g. come from previous freed allocations. This would hardly be an improvement. You'd have to allocate and zero-initialize it, and then you'd still have the problem whether zero is invalid data or part of the allocation... Even if code would figure that out, it would be extremely smelly code and I'd never merge it in any projects I maintain.

The approach done by the patch to just check the length is much much better. The length is sent as part of the event.

> Keeping code simple and without unnecessary abstraction is a far more valuable skill than $safe-language-trend-of-the-day.

This code almost directly maps to the bluetooth host controller interface which is part of the published Bluetooth standard. So you can't change the core concepts of it. There are a few abstraction layers which copy the data for some reason from a new/delete managed hidl_vec to a malloc/free managed array (check hciEventReceived function in hci/src/hci_layer_android.cc). Yes, I'd say that some of those layers are indeed unnecessary. But those abstraction layers are not where the vulnerability occurs. It occurs in the code that parses the message, and the bug is that the code does not check the length of the input data. This is a classic bug that can occur in C/C++ codebases.

Safe Rust prevents OOB writes/reads by performing bounds checks when you index into a slice.

The issue with languages like C is that verifying that code is safe is extremely hard, even harder than writing it in the first place. This codebase seems to have not been written by Google but by Broadcom, so Google would have to verify whether what Broadcom wrote is actually safe. With Rust, such verification is easy. If your code makes little use of unsafe, and most code doesn't actually have to, it's easy to verify its safety (at least for the classes of bugs that Rust eliminates). Due to the strong typing, other types of bugs are made harder to write as well.

That said, regarding:

> safe-language-trend-of-the-day.

I agree that rust advocacy can sometimes be a bit misguided and over-enthusiastic - however how often is an out of bounds write not a bug (or a too clever by far hack)?

We've had pretty efficient ways to deal with this in c like languages for a long time (eg Pascal, Ada).

(c-like in the sense of being relatively low-overhead, close to the hardware wrt memory layout etc).

This will take a couple of decades, but it's a worthwhile effort.

But I think this vulnerability serves as an important lesson about which language to choose for new projects in the embedded area. Thus I'm very glad that Google uses Rust for its new OpenSK security key firmware. I hope that future versions of Android will adopt Rust, at least in newly written components. Some Google developed Android related projects are already using Rust, like Cuttlefish which uses crosvm.

We've spent decades pushing the limits of security improvements we can get through asking people to please try harder and do better with C, but we still see a high rate of high-impact errors like this.

Rust's safety model isn't the only valuable thing about Rust. Another big valuable part of Rust is that instead of giving the programmer a box of unsafe tools and a post-it reminding them to be careful, Rust provides sane, safe default tools that have been built based on what we've learned from the past several decades.

The argument isn't "Only Rust can save you", but that Rust is a good choice that both meets the same performance requirements, and avoids these problems by default.

If you've got a better solution to persuade C and C++ developers to consistently and reliably always wrap their use of pointers from other APIs into (ptr,len) buffer types, I'd love to hear it!

With comments like this, I sometimes feel like many developers are much more interested in smugly dismissing a group that's made significant real-world progress in making it easy to do the right thing than they are in actually helping real developers to reliably make safer software today.