36C3: All Wireless Stacks Are Broken

Your cellphone is the least secure computer that you own, and worse than that, it’s got a radio. [Jiska Classen] and her lab have been hacking on cellphones’ wireless systems for a while now, and in this talk gives an overview of the wireless vulnerabilities and attack surfaces that they bring along. While the talk provides some basic background on wireless (in)security, it also presents two new areas of research that she and her colleagues have been working on the last year.

One of the new hacks is based on the fact that a phone that wants to support both Bluetooth and WiFi needs to figure out a way to share the radio, because both protocols use the same 2.4 GHz band. And so it turns out that the Bluetooth hardware has to talk to the WiFi hardware, and it wouldn’t entirely surprise you that when [Jiska] gets into the Bluetooth stack, she’s able to DOS the WiFi. What this does to the operating system depends on the phone, but many of them just fall over and reboot.

Lately [Jiska] has been doing a lot of fuzzing on the cell phone stack enabled by some work by one of her students [Jan Ruge] work on emulation, codenamed “Frankenstein”. The coolest thing here is that the emulation runs in real time, and can be threaded into the operating system, enabling full-stack fuzzing. More complexity means more bugs, so we expect to see a lot more coming out of this line of research in the next year.

[Jiska] gives the presentation in a tinfoil hat, but that’s just a metaphor. In the end, when asked about how to properly secure your phone, she gives out the best advice ever: toss it in the blender.

29 thoughts on “36C3: All Wireless Stacks Are Broken

  1. “In the end, when asked about how to properly secure your phone, she gives out the best advice ever: toss it in the blender.”

    Well, I would advise to remove the lithium polymer battery first. Then you would be safe and secure.

    1. Concerning that quote, I was never a fan of people preferring to give technically correct but flippant replies that don’t actually answer the question when asked a valid one. I appreciate she might not have any usable answers, but then just say so – what I definitely do not appreciate is someone more interested in being a smart alec then giving an actual reply.

      1. It’s a joke meant to drive home how incredibly difficult it is to secure such devices. If that didnt get through, it’s on you, because I think most people understood, and didn’t take it literally.

    2. Not unless you also plan to put google’s servers in the blender, and also the servers at your phone company with your call history. You should probably put the cell phone towers in the blender because they keep logs too. And then you will have to pulverize every computer you ever surfed to. By. the time you are done you will need a really big blender for all those computers.

      1. FYI cell site antennas don’t collect “logs” , they collect simple flag counters and are aggregated for debugging and erased every 15 minutes. Up to 10-15 antennas per cell site, 2 petabytes of “logs” every day in the US, you can’t store all the details.

    3. Was always wondering about the same thing, but everything looks fine in the “iPhone 8 vs. Samsung Galaxy S8—will it blend?” video ;)

      Also, I only proposed that solution because recent operating systems don’t disable Bluetooth properly. I would like to see more practical solutions.

    1. If you watch the video, you will learn that her research group looks at various wireless protocols but her field of research is Bluetooth. The stuff about BT/Wifi coexistence might be in someone else’s paper or thesis or it might still be unpublished.

  2. Before a medical problem caused a project failure I was involved with a project to have an user respecting phone project with GNU-Linux OS. One major feature was a both physical and hardware power switch for the modem module as well as a hacker connection inside which was to interface to user made modules and hopefully a future available POCSAG pager module which would allow a user to optionally be 100% radio silent with a powered off modem yet receive and call back in nearly real-time(as long as it takes to boot modem and connect to cellular network) the number calling the pager/phone number.
    I even had a tepid conditional endorsement from the famously phone-phobic RMS though he demanded among other things to somehow permanently disable firmware updates to the modem module.

    1. You might be interested in the pinephone from PINE64 and the librem 5 from Purism.
      Both have hardware kill switchs for radios, and both run mainline linux kernels, and no android !
      And they are both approching a state where they will be daily driver ready o/

  3. Phones are designed with the premise that someone else isn’t going to open it. If you take away that premise, sure, they are insecure, but so is almost everything. The Bluetooth stack is probably not even the easiest attack vector, in that case. You might as well go after the “secure element” itself.

      1. It’s my issue, of course — I don’t like watching video presentations/lectures. I wish that written reports would be shared in addition-to (or instead-of) all the links to video lectures, but so often they don’t exist. As for Bluetooth, anyone who cares about security has it off (very few people really care about security or privacy). On the other hand, the issue of Bluetooth is compounded by wireless headphones, but hopefully Apple will soon shift to UWB for this use-case.

  4. A good presentation.
    I like the idea we had of physical switches for wifibt and cellular; she mentions/likes this too. Hard(power) and soft switching with OS support for power cycling of the radios is great for when you have to enter a insecure area like foreign embassy, airport, border crossing, or defcon; we need to bring back pagers so we can be radio silent and unavailable to hacking when we choose.
    What a mess we have to fix bluez on linux and we also need to get beyond the droid/appl duoopoly and get some real FOSS phones with better wireless firmware.

    1. My guess, crappy proprietary stacks. With open an source stack it could potentially thrive and evolve. But these blobs tend to be fire and forget. Especially if its a blob masked in ROM. Not that eeprom helps that often, as they hardly ever get upgraded.

      In WiFi land we have 1 open firmware blob, ath9k. Sadly it is an outdated chipset and the vendor lost interest after Qualcomm bought the, but even so, while extremely slow, is still evolving.

      1. Proprietary stacks the fact that the various profiles (36 at last count) were designed by committees, often with members trying to gain some advantage in the market. That’s why there’s multiple file transfer, overlapping audio and video profiles, and useless profiles that never got any use, like FAX.

Leave a Reply

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