Hacker News new | comments | ask | show | jobs | submit login
BleedingBit: The hidden attack surface within BLE chips [pdf] (armis.com)
70 points by keyme 72 days ago | hide | past | web | favorite | 14 comments

Crap... CTRL+F Nordic .... Whew! Seems like this is mainly in relation to the Ti CC26xx series. I'm using the Nordic right now and the only time it's mentioned here is the Over The Air update service.

For that that might not know, Ti the approach that some others (not Nordic) does where they give you an ARM Cortex M4 to put your code on and have another Cortex M0 that runs the ROM based BLE Stack. This drove me away from many of the Ti offerings because while you can't mess them up, the BLE Stack is typically not upgradable. With the launch of BLE 5 and it's mainly software upgrades it was important to us to have that ability. So here is an issue with the shared que between the two chips - I'm not sure if this will be patch-able all applications.

The hack to get console on the Aruba device is pretty cool.

It's patchable, but requires each implementor to recompile the FW with an up to date stack. The patched stack is available on TI's site for months now.

Do you really think there is no such things (unpublished) in the Nordic BLE stack?

There are definitely (unpublished, and possibly unfound) vulnerabilities in the Nordic stack. The point (IIUC) is that the Nordic stack can be fixed once those vulnerabilities are known. The TI stack, on the other hand, is in ROM; if^Wwhen it's broken, it's broken forever. (And that appears to have happened just now.)

I can't speak to the CC26xx series specifically, but normally deeply embedded cores running a ROM stack like that have some additional SRAM which can be loaded at boot for firmware patches.

Nordic <3

They are doing great stuff

I'm interested in building a security-sensitive project with Nordic's stack, are there no ways to isolate their "softdevice" from the rest of the code running on the SoC?

The softdevice binary runs in supervisor mode and typically does all its work in one of two interupt contexts.

So... it gets its own ram, rom, and you can’t (not supposed to anyhow) access it. So... no, to answer your question, but depends on what you are trying to prevent I guess.

You don’t need to run the softdevice at all, can shut off it down temporarily like while doing some crypto work, but if there was an exploit it seems like it could be bad because the SD seems like it can probably do anything your code could plus some. Additionally with the ‘software interrupt’ peripheral it seems it has a built-in way to branch to any arbitrary code location.

However... there is a gambling application that uses one and the code has been through a couple audits as I was told.

This is also yet another reason as to why ditching the headphone jack on phones is so brain-dead.

Bluetooth seems to be quite hard to secure (or am I mistaken?), is there any decent (simpler) alternative available or on the horizon that could become ubiquitius?

Phones without headphone jacks have digital wired interfaces to which headphones can also be connected.

Sure, but that's not a worthy solution to a portable device.

Why do bugs nowadays have to have a name and a website?

Are they security researchers or posers?

Security researcher A opens a bug report on a tracker and writes a technical description and it sits there for five years and it gets zero replies and nobody cares.

Security researcher B hires a designer, makes a logo, catchy name and a website and it gets upvotes on HN and Reddit and media picks it up and the whole world gets a day-worth of drama from it, emergency meetings are held and things get fixed.

Can anyone offer a TLDR summary? Any good open-source atacks out there?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact