Implement read-only mass storage mode

[robertfisk]

Various use-cases (forensics, enhanced paranoia) have a need for a read-only mass storage mode. This could be either a compile-time option, or dynamically set on bootup based on an input pin controlled by the user.

Both Upstream and Downstream would need to be put into read-only mode to ensure robustness in the face of USB exploits coming from either direction.

[teeks99]

I think this is an awesome idea, this device seems like it would be perfect to implement it. I frequently need to use drives like the Kanguru with a write-protect switch when transferring data onto a system that stores high-value data. This is done with the hope that if malware were to infect this high-value data system, it wouldn't have any way to ex-filtrate the data. However, ever since the revelation of BadUSB, I've been very worried about a virus being able to just overwrite the firmware to disable the input from this write-protect switch. Even though it is a physical switch, I'm sure that switch doesn't directly control the hardware that charges the write capacitors on the media, or anything like that. I'd bet my bottom dollar that physical switch just gives an input to the firmware...which could be hacked by BadUSB or the like.

However, I'm not sure there would be a benefit in putting downstream (device side) into read-only mode. Does that mean that data couldn't be passed from the mass-storage device to the pc? If so, I believe it would effectively prevent usage of the device completely...don't you need to read data to the file system before you preform writes to the device? I guess you could maybe use that mode to format devices, but even then you'd want some status back.

With the separation of the upstream and downstream sides here, it seems like there would be a place where we could read a switch telling the USG to go to read-only mode for the media, and could then filter any commands coming from the PC sending file data to the media. However, this would need to be in a section of firmware that is protected from manipulation by either end of the connection. From reading the documentation I'm unsure if such a place exists on the device. It seems like this is only upstream and downstream firmware, ideally this firewall would be in neither of those as it would be possible for there to be malicious code on both ends at the same time. Hope that doesn't grow the scope of the problem too much :-)

[robertfisk]

I'll take that as a +1 !

I agree that the write protection on common devices is a flag to the firmware, which could be overridden. You can also get forensic 'write blockers'. I have not looked inside one of these, but unless they are built to the same spec as the USG with independent processors, they will also be vulnerable to compromise.

Regarding putting Upstream and Downstream into read-only mode, this would allow reads from the PC through to the device. I agree doing it any other way won't make sense.

Having both Upstream and Downstream agree to disable writes is important in a variety of scenarios:

1. Malware on PC wants to exfiltrate data. Writes are blocked by Upstream.
2. USG-aware malware on PC wants to exfiltrate data. Malware compromises Upstream, but writes are blocked by Downstream.
3. USG-aware BadUSB device wants to disable write protection. BadUSB device compromises Downstream, but writes are blocked by Upstream.

However there is a fourth scenario where things get ugly: USG-aware malware on PC wants to exfiltrate data to USG-aware BadUSB device. In this case both Upstream and Downstream are compromised and we no longer have control. You could have a third 'referee' microcontroller monitoring the SPI bus and blowing the whistle when it sees write commands. But the attacker can easily avoid this by coding a sequence of 'read' commands that actually transmit data to write. In this case we are owned.

So the takeaway is to make sure that the attacker who controls your PC is not cooperating with the attacker who controls your USB storage. Second-sourcing is important!

[robertfisk]

This feature is now implemented as a compile-time option! Writes can be disabled by commenting out this line...

#define CONFIG_MASS_STORAGE_WRITES_PERMITTED

in the files:

Upstream/Inc/build_config.h
Downstream/Inc/build_config.h

(be sure to make the same change to both files, for maximum malware resistance)

Support for mass storage, keyboards, and mice can be selectively disabled by commenting out other defines in the files above.