ROM USB Flash Drive as solution to storage firmware exploits

[WhonixQubes]

If one does not want to be vulnerable to storage firmware exploits as
recently attributed to the Equation Group...

Then wouldn't USB flash drives with ROM read only firmware -- used with
Qubes PVUSB usbvm isolation -- be a solid solution for trustable
non-exploitable storage?


It seems most all USB flash drives do *NOT* come with non-programmable
read only firmware, since this would up the cost of production for
updating/fixing firmware in such mass produced cheap devices, and most
vendors are not security focused anyway.


Does anyone know of some USB flash drives with non-programmable read
only firmware?

Would this be a viable way to get non-exploitable storage with Qubes OS?


Thanks!

WhonixQubes

[Alex]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/24/15 09:14, WhonixQubes wrote:
> If one does not want to be vulnerable to storage firmware exploits
> as recently attributed to the Equation Group...
>
> Then wouldn't USB flash drives with ROM read only firmware -- used
> with Qubes PVUSB usbvm isolation -- be a solid solution for

> trustable non-exploitable storage? [...]
There is also the chance that the controller has a write-enable
hardware pin, that can be wired to be set in read-only mode. Such a
thing may exist for hard drive controllers too; I'll check the
datasheets for the ones in my hard drives, if available.. They are
often hard to find in non-chinese language, and I can't really say I
understand more than one or two ideograms ;)

- --
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU7DcWAAoJENNOJZnNP8uDxTEQAJ4A8aT6BxFvFe36FXyeXAu2
MgVRNbuEkM3RXxf9z+XAHVIj/bY3oRTAhW/k1WwxB3C069wMpZgil3an+0J7dQ77
1J7t+ZLWCnBfVRyZkPdIwjKUzhbxxWFtisLyRMB5Tn6tOuVHfPjQ9FDWS+f1BaA6
A+IrJBRTIbWyNqkstBTnPO5J4OOIRGRL50r4eH7wewGGIxslCMGRCZ6a1ic0z3P+
DD9YguOSQzJZ0ZBB1npRvOGAbju1Pw3cLCzMOYqWule8LVWpp5UKCn+RLX2KFzGB
ZZ0+2BOCOZ02+IU/BnqWW0KtoAaIGK8SZKuNCJRoMBBqwV+/0w6iXX/1Fo20U479
DUSwIYA2tmDEAw7nWM46PUVtkguqVGuh8ccod2f/CmQ8Q4vuqMedx65pf/nG+X3E
CJiinhDugGxKpFHmFpkC4yizmKt7V112LH4fyjpt5I0xYhn1FOKPgccatZ4gblbO
7tOu2pyEg/8UdvmFZgG56RuXxrqDOmPVFqk89419ibb2qzXa59EjLwEZpMzlxbz/
xi/80+GGIwJHzMNj6gbjvd7Cc4dufzRDkuLLoJHTPBfmlR1H3Izkv6PwxEyjzon4
Qg+Zw2ABrxnFl4yjj4I2ePWXv2WfRO1XifNYOdjuff96tV7wp/eyNjP+iDoI56Gp
qRJux3SWD0kCfKvV5VHU
=PX37
-----END PGP SIGNATURE-----

[7v5w7go9ub0o]

Here are a couple of USB products that sign their firmware, and validate
it before updating. I don't know if bad firmware could be updated after
disassembling the drives(s) and using a dedicated device.... presently a
dis-countable concern for me.

<http://store.kanguru.com/blogs/news/15106765-kanguru-releases-kanguru-flashtrust-the-world-s-first-unencrypted-usb-3-0-flash-drive-with-secure-firmware>

<http://www.ironkey.com/en-US/solutions/protect-against-badusb.html>

So the question becomes, have they hidden something within their signed
code? (or does NSA have a key?)

The Kanguru products additionally have a hardware switch that activates
a read-only mode - which allows me to share files with my Windows
friends without fearing corruption of either the firmware or of the
files/storage area.

Can't help but wonder who has cryptographically-signed firmware on their
SSDs - IIUC that is a requirement for NIST-certified servers.

[Alexis Wattel]

The USB Armory is a crowd-funded hardware project led by a company
called Inverse Path [1].
After having watched a presentation they made at 31c3 [2], I sense that
it is very promising device. It is essentially a full-flavored computer
the size of an USB key, with allegedly a "Trusted Boot" feature. Some
characteristics :

- Freescale i.MX53 ARM Cortex-A8 with ARM Trust Zone for security
enforcement.
- Runs Linux kernel.
- MicroSD slot for storage.
- Emulation of USB devices (Storage, Network Controller, ...)

The device is programmable, and allows code to be signed with user's own
keys, although the presentation was not very technical on this subject.

Example use cases are encrypted storage and Key Management for anything,
passwords or Bitcoin wallet with keys not leaking to host.

So to sum up, it would offer a wide range of secure computing
applications that will rely a lot on the security scheme offered by ARM
Trust Zone. The code integrity mechanism is assured by 4 secure
registers that can hold the user's keys to sign to code.

Hopefully, it is an open-source and "open-hardware" initiative [3], so
it will be open for reviews and developers' ideas. The presenter assured
that ARM's technology was not encumbered too much with NDAs.

Anyway the interesting feature is that it is a whole Linux computer that
implements a mass storage device for example. So in a way, you control
the (virtual) firmware and can force a screening procedure of every file
before it reaches storage.

Although it does nothing to the actual storage firmware, that is the
MicroSD firmware. This is still wide open to attacks. But this device
offer a chance to, e.g., monitor its behavior, and I/O transfers.

[1] http://inversepath.com
[2]
https://media.ccc.de/browse/congress/2014/31c3_-_6541_-_en_-_saal_2_-_201412281730_-_forging_the_usb_armory_-_andrea_barisani.html#video
[3] https://github.com/inversepath/usbarmory

[WhonixQubes]

Thanks for the replies! :)


Overall, I generally see the device firmware exploit threat like this...

1. Unsigned Reprogrammable Firmware
- Vulnerable to General Unprivileged Exploitation (common)
- Vulnerable to Malicious Manufacturer Original Firmware (maybe)
- Vulnerable to Malicious Manufacturer Updated Firmware (maybe)
- Vulnerable to Post-Manufacturer Physical Interdiction (rare)

2. Signed Reprogrammable Firmware
- Vulnerable to Key Theft or Key Compulsion (common)
- Vulnerable to Malicious Manufacturer Original Firmware (maybe)
- Vulnerable to Malicious Manufacturer Updated Firmware (maybe)
- Vulnerable to Post-Manufacturer Physical Interdiction (rare)

3. Non-Reprogrammable Firmware
- Vulnerable to Malicious Manufacturer Original Firmware (maybe)
- Vulnerable to Post-Manufacturer Physical Interdiction (rare)



This is an interesting article that says the opposite about USB flash
drives, that they typically do not have updatable firmware...

https://www.yubico.com/2014/08/yubikey-badusb

"Many low-end USB devices do not support DFU (Device Firmware Upgrade),
either because the firmware is factory-programmed in a non-alterable
mask ROM, one-time-programmable ROM or simply because there is no DFU
mechanism implemented. Supporting DFU adds cost and complexity and
therefore makes little sense for low-cost mass-market devices, such as
thumb drives, card readers, keyboards and mice."

Yet, I've seen many other BadUSB articles (although less technical)
claiming that most USB devices do indeed have updatable firmware.



As referred to, we've found some USB storage devices that have signed
reprogrammable firmware.

However, it would be nice to remove the attack vectors of reprogrammable
firmware altogether with a simple dumb storage device that has ROM (Read
Only Memory) or non-DFU (Device Firmware Upgrade) based firmware.



Would need to be able to use as primary Qubes data disk to read/write
files to.

Would preferably be a simple dumb storage device and not have advanced
computing capabilities like USB Armory that could be hacked and abused
beneath Qubes's control.


Still looking for these elusive non-reprogrammable firmware USB storage
sticks!


WhonixQubes

[cprise]

On 02/24/15 03:14, WhonixQubes wrote:

These new exploit reports do not appear to mention if the malware is
effective against password-protected drives. I think its possible that
either the Opal 2.0 or FIPS 140-2 security standards may at least
implicitly require the refusal of firmware updates under certain conditions.

''FIPS 140-2 Level 3 adds requirements for... identity-based
authentication, and for a physical or logical separation between the
interfaces by which "critical security parameters" enter and leave the
module, and its other interfaces.''
https://en.wikipedia.org/wiki/FIPS_140

However, that appears to refer only to the crypto module.


And from the TCG / Opal 2:

''5.1
Interface Control Template
5.1.1
Overview
The Interface Control template enables TPer control over selected
interface commands. The benefit is the
reduction of undesired side effects. These commands MAY change the
runtime or permanent configuration of
the Storage Device as a whole. As such, it is in the spirit of being a
trusted peripheral that the use of such
commands be restricted.
Some examples of interface command operations that MAY be restricted
are:

Downloading new firmware
Changing the maximum LBA accessible
Enabling or disabling Storage Device features
Forcing read errors
Changing power-on default settings
Changing Storage Device timing parameters
Reading and writing raw data
Formatting the Storage Device

This template provides facilities to restrict unauthorized use of
certain commands via the host interface.
''
http://www.trustedcomputinggroup.org/files/resource_files/B15F1F8F-1A4B-B294-D03F09D5122B21F6/Opal_SSC_2%2000_rev1%2000_final.pdf


That sounds more like it. Well, a person can hope......

[Robert Fisk]

I am currently working on a solution to the problem of untrusted USB
devices. From an earlier post to qubes-devel:

> On the topic of taming BadUSB, I can envision a hardware widget that
> contains two microcontrollers. One talks to the PC and emulates a USB
> device, such as a flash drive (mass storage class). The other
> microcontroller is a USB host talking to the actual untrusted flash
> drive. The two microcontrollers pass data through a simple protocol over
> a local bus such as SPI at ~10MHz.

Like most, my available time for this project is limited. But I
absolutely aim to have something ready for release this year. Initial
devices will support USB1 speeds only. If it proves useful to a
significant number of people a USB2 version will be developed in due
course :)

Regards,
Robert

[WhonixQubes]

Robert,

I would certainly be interested in what you produce here!

Looking forward to seeing more this year. :)

WhonixQubes

[Robert Fisk]

>
> On Thu, Feb 26, 2015 at 12:53 AM, Robert Fisk <rober...@fastmail.fm
> <mailto:rober...@fastmail.fm>> wrote:
>
>
>
> I am currently working on a solution to the problem of untrusted USB
> devices. From an earlier post to qubes-devel:
>
> > On the topic of taming BadUSB, I can envision a hardware widget that
> > contains two microcontrollers. One talks to the PC and emulates a USB
> > device, such as a flash drive (mass storage class). The other
> > microcontroller is a USB host talking to the actual untrusted flash
> > drive. The two microcontrollers pass data through a simple
> protocol over
> > a local bus such as SPI at ~10MHz.
>
> Like most, my available time for this project is limited. But I
> absolutely aim to have something ready for release this year. Initial
> devices will support USB1 speeds only. If it proves useful to a
> significant number of people a USB2 version will be developed in due
> course :)
>
> Regards,
> Robert
>

> --
>On 01/03/15 06:17, Attila Horvath wrote:> Robert
>
> I'm sure your effort will be welcome.
>
> When you say you will have something ready this year - do you mean a
> custom/prototype? If so, we can assume it'll be proprietary w/ patent -
> correct?. Will you be releasing any specs for user community evaluation?
> Will your solution/product be verifiable by end user?
>
> Thx
>
> Attila



Hi Attila and all,

Initially the 'product' will be source code and instructions for people
to build their own device. I will probably arrange a supply of
pre-assembled hardware once functionality is confirmed.

My firmware source and hardware design files will be released under an
open-source license. As you point out, this project would have little
value if its functionality could not be independently verified.

The template code from ST is not strictly open-source: hardware driver
libraries and headers are freely redistributable on an as-is basis,
while the USB middleware stack is licensed on the condition that it is
only used in ST hardware products :)

Robert