udev rule vulnerability to badUSB

[leni536]

There is a HN discussion about Circlean. Some questions came up about badUSB vulnerability, and it turned out that Circlean has a mitigation at circlean_fs/root_partition/etc/udev/rules.d/50-blockhid.rules.

However a potential attack came up. A badUSB device could imitate an USB hub with an attached keyboard, and it wouldn't be blocked (relevant comment). I suggest some whitelist based udev rule instead that only allows USB MSC devices, something along the lines of this and this methods.

An other badUSB attack came up too: because according to the instructions the USB devices are plugged in before boot, a badUSB device can potentially enter the BIOS, make itself the boot device then boot into a virus. This could be mitigated by fixing the method and the instructions to only plug in the device after boot.

[Rafiot]

I see some usability issues:

• there is no graphical UI, the user has no way to know when it would be safe to plug the key
• the script needs to know which key is which and right now, /dev/src and /dev/dst are mapped at boot time.

And if the attacker has a vulnerability able to compromise the bios of the Raspberry pi, they have lots of resources (money, time) and it is probably easier to just exploit a parser and write a malicious file on the destination key.

[leni536]

there is no graphical UI

The device already has a UI implemented as a blinking LED and sound. Now it only indicates two states: copying (blinking and music), and ready (silence). Indicating a third state could complicate instructions, but wouldn't be impossible.

Alternatively there could be separate/alternative instructions for the overly paranoids, like setting up a BIOS password and disable booting from USB.

As for the udev rule, I think it's still vulnerable. As I see the udev rule is there to block badUSB like attacks already, and now it fails at that. I see no reason to not fix that.

[Rafiot]

Silence means "not started" or "done". I can think about implementing a loop to wait until two keys are connected, but if the attacker can compromise the bios when booting, does it makes any difference to have the system booted? De you have some white paper about that? Based on the spreadsheets I found, the rpi can only boot from the SD card and there is no way to mess with the bios without compromising he SD card first.

The udev rule aims to avoid having keyboards and this one could in fact be improved (PR welcome). In practice there is no usable user in image so the attack vector is limited.

[dputtick]

A note on the question of a BadUSB making the RPi boot from itself - RPis cannot be booted from USB without setting a special bit in the SoC, and this can only be done while booted from a SD card. So, that attack doesn't seem like something we should be particularly worried about.

More details here: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md