Texas Instruments flicks Armis’ Bluetooth chip vuln off its shoulder

Texas Instruments has rather feebly slapped down infosec researchers’ findings on a so-called Bleedingbit Bluetooth Low Energy vulnerability after a more detailed explanation of the chipset’s weakness emerged.

At Black Hat London last week, Ben Seri and Dor Zusman from research house Armis went into full detail about their November discovery of how to pwn TI-made Bluetooth Low Energy (BLE) chips.

The two affected chips – CC2640 and CC2650 – are used in several models of Cisco and Aruba wireless APs. What gave Armis a way in was the method of updating the chip’s firmware, which consisted of uploading firmware over an unencrypted connection, though the upload was authenticated.

Seri and Zusman went into precise detail during their Black Hat presentation on how they triggered the memory corruption problem which they said allowed them to pwn the chip, and thus the router it is built into.

The pair said that when a BLE chip broadcasts advertising packets (for other devices to know it is there and connect to it), those packets’ headers contain a field marked “length”. This field is “supposed to be 6 bits” long according to the deprecated Bluetooth 4.2 spec. Bluetooth 5.0, introduced two years ago, extended that to 8 bits.

TI’s affected chips, said Seri, happily handle both Bluetooth 4.2 and 5.0 advertising PDUs – and will execute 4.2 spec messages by checking incoming packets for length and ignoring the “missing” final 2 bits in the length field. Those two were reserved for future use (RFU’d) in the 4.2 spec, later being incorporated as a full part of the length field in Bluetooth 5.0. Having reverse-engineered the chip’s firmware, Armis figured out how to bypass that length authentication and fool the chip into executing over-length 4.2 spec messages, reading and executing the RFU-reserved bits.

Once they had done that, they said they turned on each of the “extra” bits in the length field until they found a combination that crashed the chip.

After finding their way past a secondary code validation method that halted their initial attempts to trigger a buffer overflow (with Zusman admitting that their final “form of exploitation [has a] 50 per cent success rate”), Armis’ researchers figured out that the chip “has no address space layout randomisation” and so “sprayed packets [at it] that hold [our] desired ICall_ values,” triggering a memory overflow. From there they were able to customise their payload until the chip’s memory was running in a loop that they controlled.

Zusman told the Black Hat audience:

“First we set up some shell code environment, then we stop the GAP task; we install our backdoor; then we link the data entry that has triggered the vuln to itself, making sure we [wouldn’t] crash in the next trigger, then we restore 2 variables, then we unhook ourselves from the Cisco gateway because we don’t want to run again. And that’s it basically: we have exploited the AP with only 32 bytes.”

Full technical details are available on Armis’ website, with its Black Hat presentation available on the BH site.

We patched, we warned – TI

Texas Instruments was not particularly happy about Armis’ published findings when El Reg asked the company to comment, stating, among other things, that “the potential security vulnerability that [Armis] are exploiting was addressed with previous software updates”.

TI added: “Additionally, the over-the-air firmware download (OAD) Profile feature mentioned in Armis’ report is not intended or marketed to be a comprehensive security solution, as noted on TI.com [it pointed to the relevant URL here]. We encourage our customers to use security-enabled features when designing security-related systems.”

Cisco told us in a statement:

“Cisco is aware of the third-party software vulnerability in the Bluetooth Low Energy (BLE) Stack on select chips that affects multiple vendors. Cisco PSIRT issued a security advisory to provide relevant detail about the issue, noting which Cisco products may be affected and subsequently may require customer attention. Fixed software is available for all affected Cisco products.”

Firmware updates for all three of the TI chips are available from its website, though one should first look for updates from the vendor of any affected device.

For the CC2640 (non-R2), BLE-STACK version 2.2.2 is on TI’s website.

Folk wanting to “update to SimpleLink CC2640R2F SDK version 1.30.00.25 (BLE-STACK 3.0.1) or later” should go here.

And finally, for the CC1350, you can find Simplelink CC13x0 SDK version 2.30.00.20 (BLE-STACK 2.3.4), or later, here. ®

Updated to add on 13 December

Armis sent us this statement after the article was published: “Coordinated vulnerability disclosures of this complexity require careful orchestration. Once we identified the issues, we reached out to TI and connected with their appropriate security contacts. We clearly communicated in our public report that TI had already identified the BLE-STACK issue and provided a fix. But as TI itself states, they identified it as a stability issue – not a security issue.”

READ MORE HERE