35C3: Finding Bugs In Bluetooth

[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.

In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.

As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the address handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.

All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.

Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.

You might know [Jiska] from her previous FitBit hack. If not, be sure to check it out.

24 thoughts on “35C3: Finding Bugs In Bluetooth

  1. Huh. Is this why they want you to turn on Bluetooth when you’re waiting in airport security?

    There have been signs up asking people to turn on Bluetooth at the security line at Halifax international airport for at least a year now, probably two. I always thought that was strange.

    I’m sure this zero day has been in the hands of government for much longer.

    1. Probably more likely they’re measuring foot traffic. 5hey can use your Bluetooth hardware address to anonymously see where you go, how long you stay and generally how busy an area is.

  2. Does anyone else besides me not see this as a problem with ‘buggy Bluetooth code’ but a problem with the corporate culture of let’s lay off all the costly grey-beards and hire bulk replacement green contractors for pennies on the dollar? Yeah! Saved the company -30% in labor costs that goes direct to the bottom line.. Executive Bonus Material Time!

    I do acknowledge the possibility I am biased since my beard is grey. But I’ve never been laid-off.

    1. I’ve seen grey beard people as bad as the younger ones. Look, do you see a lot of grey beards in the picture for this article ? Age is not the point here.

      However, greed and, yes, lack of skills is a problem (whatever the age is).
      So are career-minded people. I’ve met a few in my work life, they favor shipping a buggy/unsafe product on time, instead of delaying it and getting the problems fixed. When the problems finally surface, they are long gone, and the skilled people who were against the release (and who are now labelled as witches) have to deal with them.

      I think it killed my company and I expect to be layed off (with everyone else) in a few weeks/months.
      Management listened to a stupid egocentric careerist maniac for a few years because he sure looked good in his speeches, discarding the opinion of the rest of the team. When they realized the problem, a lot of damage has been done. This was 3 years ago and we’ve been sinking since then, and I don’t see a way out. Sad.

    2. Could be one reason. More likely is the problem of limited resources… with a given timeline and budget it is very hard if not impossible to be 100% bug free. So for example you find 99.9% of your bugs this still we result in a few bugs still in your code. A hacker just needs one bug to exploit your system…

    3. Grey beards have caused this problem … the majority believe is that buffer overflows are something other people code. They’ve been doing embedded coding for 30 years and can do it flawless, it’s everyone else’s fault. Also if you really want to you can just use these tools which increase your development time by 100x to write safe C, so you see we’ve never needed an alternative and we never will.

      Grey beards were hackers. Maybe the newer generation are poorer hackers, but the industry should have moved to being engineers … and the grey beards have been obstructing that even more than the framework du jour javascript programmer, but with a false mantle of respectability.

  3. Oy vey..

    This is, indeed, a recurring theme. Vendor releases cheap chipset but with lots of “secret sauce” locked up tight.
    Security researchers pierce the veil of security through obscurity.
    Vendor drags its feet releasing a patch, fails to release it for older devices, or declares entire chipsets no longer supported… often patching only those explicitly found bugs, and not addressing design/design pattern flaws.
    Chip vendor may release patch, but then device vendor may no longer exist and/or care about the device, so even fixed flaws remain unpatched.
    Large number of devices, otherwise fully functional, are orphaned – forcing upgrades…

    Particularly as devices are miniaturised and integrated (think SoCs etc.) so that the previously clear lines between components are blurred…

    … and what’s with the shit protocol development? I mean, how did WPS come a thing with separate checking of MSB and LSB on PINs?

  4. I think the most valuable sliver of information that people missed was that the dev kit had a firmware binary that hadn’t been stripped of the symbols. This alone could save you months of labor in reverse engineering a single firmware image.

  5. “Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure.”

    Makes a strong argument for open-source hardware and software, and less for NDAs and other means of obscurity.

    1. I mean, that’s hardly news to anybody. It’s not like people aren’t *aware* that this model sucks, but there are only a few companies making chips like this and they steadfastly refuse to be more open. They are aggressively secretive and have very little competition (or at least, no viable open competitor), so there’s no motivation for them to change.

      The problem’s not lack of awareness, it’s lack of incentive to do better.

  6. Looks like i was correct in keeping Bluetooth off all these years. Android needs silent running to be the default setting, at the very least an option.

    Is Paranoid Android distro still a thing?

  7. „And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time.“ Sounds like a general problem, not only bt related.

  8. I have a friend that has dealt with Broadcom chips for years. Since cable modem chips came out. The last few years he has been writing embedded code controlling (among other things) Broadcom bluetooth chips. Long story short, he thinks Broadcom is a pack of fuckwits (my translation). :)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.