Snippet 21: Blueborne Attack Linux Kernel RCE

BlueBorne turned carefully crafted Bluetooth packets into full remote code execution across Linux, Android, Windows, and Apple stacks. On Linux the exploited code runs in kernel space, handing the attacker complete control of the device.

Key Takeaways

• BlueBorne achieved real remote code execution across Linux, Android, Windows, and Apple Bluetooth stacks
• The Bluetooth specification’s size and complexity, 2,800 pages versus Wi-Fi’s 450, invites implementation mistakes
• An L2CAP buffer overflow let attackers load their code with a carefully sequenced set of packets
• On Linux the Bluetooth stack lives in the kernel, so the exploit runs as a kernel thread with no additional escalation needed

Video Transcript

OK, let's talk BlueBorne. It's similar to [? Swain ?] Tooth in that the attacker is injecting carefully constructed packets. But they took it considerably further, the BlueBorne researchers did. They were able to show remote code execution by digging through the code and the Bluetooth stack to actually get real code execution. The attack applies to the Bluetooth stack in the Linux kernel, Android, and they have demonstrations for Windows and Apple. You can check out their website for all the details.

Their white paper is definitely worth a read. It's well written and informative. So they note that the Bluetooth spec is 2,800 pages, Wi-Fi is only 450 pages, and it's hopelessly bloated. They note also that the whole Osi stack is re-implemented in Bluetooth, whereas Wi-Fi leverages TCP/IP, and other standards. They don't try to do it all themselves. So all this complexity and packet/stack fragmentation makes it hard for vendors to properly implement the Bluetooth stack, just like we saw with [? Swain ?] tooth.

So the plot on the right shows a plot from the Bluetooth spec. And you can see each time you get a new layer or a new fragmentation here there's C code that somebody's got to write to handle these fragmentations and all the options basically. So it's easy to miss corner cases. So what they did is you've got the Bluez code and the kernel code is all available open source.

And for the Linux vulnerability, at least, they were able to just figure out where buffer overflows were possible and then carefully craft a sequence of packets that would load up the buffer in such a way that they could get remote code execution. Specifically, they found an L2 cap problem where the buffer was allowed to be arbitrary length, even though the protocol was only using a certain number of bytes so they could do an overflow and get their code onto the target device.

Here's a quote from the paper that highlights something that's maybe even more interesting is that, for the Linux kernel, this Bluetooth stack is actually in the kernel code. So that means that once you get this exploit, you're running code in kernel space in the context of a kernel thread. So the last sentence here, this provides an attacker with a full and reliable kernel level exploit of Bluetooth enabled devices running Linux, requiring no additional steps. So that's impressive and super scary.