56

I'm currently using a USB flash drive with a live distribution. At times I would plug it into terminals I cannot trust.

My threat model here is solely the risk of unauthorized modifications to the live distribution image on the flash drive. Unfortunately, a live CD is not convenient enough (the file system has to allow writes when used on a secure terminal and constant remastering is too cumbersome).

I'm considering now if a physical write protect (read only) switch on the flash drive is reliable enough to be trusted. I mean such as can be seen on older flash drives (e.g. PQI U339H).

From what I've found so far, the write protection is said to be done completely on hardware level, but I couldn't verify if there's indeed no way to circumvent it. For sure with SD cards there is (as it's basically software level information that doesn't have to be respected by rogue systems).

For instance the SD Simplified Specification describes it as:

4.3.6 Write Protect Management

Three write protect methods are supported in the SD Memory Card as follows:

  • Mechanical write protect switch (Host responsibility only)
  • Card internal write protect (Card's responsibility)
  • Password protection card lock operation.

Mechanical Write Protect Switch

A mechanical sliding tablet on the side of the card (refer to the Part 1 Mechanical Addenda) will be used by the user to indicate that a given card is write protected or not. [...]

A proper, matched, switch on the socket side will indicate to the host that the card is write-protected or not. It is the responsibility of the host to protect the card. The position of the write protect switch is unknown to the internal circuitry of the card.

[...]

Do you know of some similar technical explanation of how this kind of write protection works on USB flash drives and would relying on it for security be wise?

AviD
  • 72,708
  • 22
  • 137
  • 218
Karol J. Piczak
  • 1,155
  • 2
  • 9
  • 15
  • 4
    Writing to a Flash drive requires a high voltage (15 Volt or so) which is not needed in read-only mode. A sane choice would be to disable the charge pump which generates the necessary 15 Volt. But while sane, this has one disadvantage: a failing block with recoverable errors can no longer be saved by copying it. – MSalters Dec 30 '13 at 22:15
  • 1
    @MSalters: I've never seen any recent flash chips which required an externally-provided high voltage supply for normal write operations. Incorporating charge pumps on the chip makes it possible for a manufacturer to use whatever precise voltages would work best for various operations. Further, unless a board has a reason to keep a high-voltage supply active all the time, the energy required to charge up an external HV supply may vastly exceed the amount of energy required to perform a few flash writes. – supercat Jul 18 '15 at 18:27

8 Answers8

18

Physical write protect on a USB drive should work in all cases. The write controller is in the drive itself. Thus, excepting a wholly insane implementation, the physical write protect switch is secure.

Physical write protect is always kind of a semi-soft thing, but it's usually at the drive internals. With a floppy drive where the controller is external to the device, one could craft a drive that ignored the write-protect slider. I think SD cards are the same as floppy drives in that regard, though I won't make a bet on it because I know those include some circuitry for things like wear-leveling.

Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172
  • 1
    That's in fact my assumption I'm trying to confirm. As to SD cards, I've added an excerpt from SD specifications showing that mechanical switches are explicitly host based. Only internal card protection would work, but it's not that common (optional to the standard). But I suppose it's this kind of internal solution that is used on flash drives, however I couldn't find anything precise about it. – Karol J. Piczak Jun 02 '11 at 15:46
  • 1
    You don't find it because the Mass Storage specification is a subset of USB, and it isn't explicit in regards to the write switch because the specification allows any medium to be represented using that specification. The host machine doesn't have to know whether it's an SD card with a USB front-end or a hard drive. It IS possible for somebody to design a drive that tell the OS it is read-only but will respond to write commands. It would be stupid to do so. Because each implementation is different, this can happen. That said, the medium interface in the USB has full control over how it acts. – Jeff Ferland Jun 02 '11 at 17:05
  • How can this be explained, then? https://kanguru.zendesk.com/entries/24752223-SS3-physical-write-protect-switch-not-working – user1284631 Jul 11 '15 at 11:35
  • 1
    @axeoth: See my answer. – supercat Jul 18 '15 at 18:55
  • I've used the PNY item referenced in the question and found it reliable, however it's rather undersized by today's standards. Never had the switch fail to protect me, including using it in infected systems (I used that flashdrive to hold anti-malware programs.. Unless the vendor is an idiot, or the switch is 'just for show" a write protect switch should be reliable. The challenge is finding a flashdrive that has one, they are uncommon. – Chuck van der Linden May 10 '20 at 01:33
8

First of all here is a link to a page with a list of usb sticks with such write protection switches: http://www.fencepost.net/2010/03/usb-flash-drives-with-hardware-write-protection/ There is some info there, and they too imply that it's a hardware protection.

Now, if you are really serious about it, you can consider usb write blockers, commonly used for forensic purposes but can be used like this too. Here is one example: http://www.salvationdata.com/data-recovery-equipment/source-data-safe-guard.htm

john
  • 10,998
  • 1
  • 36
  • 43
  • 6
    As the creator of that first page with the list of drives, I have absolutely no firsthand knowledge of the actual implementations being used. I could see it being either a flag to the on-drive controller that writes should not be allowed or a physical interruption in circuit traces, but I think the first is far more likely for cost & reliability reasons. It still comes down to trusting the controller implementation. For the truly wary, I suspect Kanguru will be your best bet both for drives and for getting detailed technical responses. – fencepost Aug 07 '11 at 23:14
4

Although many low-level flash chips do provide a hardware "write-protect" pin, operation is completely unspecified if the state of that pin changes in the middle of a write operation; while changing the pin around the time an operation is started might always have the effect of either preventing the operation altogether (if done soon enough), allowing one last write operation to complete (if done just after the chip recognized the command), or perhaps creating bits with weird intermediate logic levels, some data sheets expressly refuse to specify that consequences are limited to those.

The purpose of the write-protect pins is not to allow end-user control via an external switch, but more typically to allow the manufacturer of the product to either ensure that the contents of a pre-programmed chip won't be changed once it's soldered into the final application circuit, or allow the manufacturer to ensure that it can only be changed via special factory-programming cable.

If the firmware in a flash controller is designed properly, having a firmware-readable "write-protect" switch should be essentially as good as a hardware-interlocked one. An alternative which would be even better would be to have the switch connected to a latching circuit such that the write protect pin could only change to allowing writes when the switch was enabled to do so, but once the processor had taken action that required the ability to write, it could ensure that it kept that ability even if the switch changed in the interim. Such an implementation might require extra hardware, however.

With regard to the observation by axeoth that some drives may only check the switch when a drive is mounted, I would suggest that such behavior (which would not be incompatible with a latching design as I described above) might be motivated by a deficiency in the USB Mass Storage Device specification--most notably the lack of a means by which a device can say to the operating system "I would like to remove myself from the system; please ensure that any pending data gets written to me, and either let me know when that's done, or let me and any human nearby know if there's a problem". If such a behavior were supported, flipping the switch from write-enable to write-protect mode could prompt the device to request a clean unmount and then remount itself as a read-only device. Without such an ability, however, a device would have to either perform a "rude" unmount, delay acknowledgment of the switch, or have write operations report "unexpected" failures. While a rude unmount would perhaps be the best behavior, some users may be annoyed if flipping the switch after they think data is written results in data loss.

supercat
  • 2,049
  • 11
  • 10
  • 1
    This assumes that "the firmware in a flash controller is designed properly", however, vulnerabilities (and factory backdoors) in USB drive firmware can allow a malicious computer to overwrite the firmware. This would not be detectable to the USB stick owner in any way. The new firmware can do many interesting things, among others, ignore the write protection switch. As there have been published attacks on USB stick firmware, you should assume that a compromised computer can permanently compromise any connected USB flash drives anyway. – Peteris Jan 09 '17 at 17:14
3

I wanted to post this as a comment to @Jeff Ferland's answer, but it was a bit too long.

Jeff, it seems your explanation is the best I can get. Every implementation is vendor specific, but every sane implementation should provide hardware level write protection.

I would have to verify my actual flash drive, but looking instead at an example of flash drive internals, the write protect feature is stated explicitly in the datasheet for the embedded Hynix NAND Flash:

A Write Protect pin is available to give a hardware protection against program and erase operations.

[...]

When the Write Protect signal is Low the device will not accept program or erase operations and so the contents of the memory array cannot be altered. The Write Protect signal is not latched by Write Enable to ensure protection even during power-up.

I think I can safely assume it's the same for all major manufacturers. So unless I'm very unlucky with some faulty implementation, I should be safe relying on physical write protection switches.

Karol J. Piczak
  • 1,155
  • 2
  • 9
  • 15
  • 2
    This seems sensible, for the most part. But... I guess the paranoid in me has lingering doubts. After all, for all I know, perhaps there are lots of insane implementations out there. If that sounds implausible, perhaps it is worthwhile to look at the history of how vendors who implemented hardware-encrypted disks and USB drives have fared; a surprising number of them have had devastating and elementary security flaws (like, not "encrypting" using XOR; or, not actually encrypting, but just storing the "key" on flash and checking it in software before allowing access). – D.W. Jun 04 '11 at 05:28
1

The question is old but the concern remains in situations where you might not be able to 'trust' a system that you need to connect to a USB storage device. Furthermore it is very difficult to locate a flashdrive with a write protect switch (only a few exist last I looked) Hence the following answer for 2020 and beyond:

What you may want to consider is a cheap "USB Write Blocker" this is a device (most often used to safely make a forensic image of a disk) that allows reads, but blocks all write operations. Prices range from $50 on up.. some of the pricier ones have special features that are mostly of interest to folks that do digital forensics. Get one of these and you can put it between any USB device that looks like a drive, and the system and you will be able to read from but not write to the device.

DO NOT confuse this with a cheapy 'data blocker' that you'd use to charge a phone or tablet from an untrusted source. That prevents all flow of data. If you are seeing sub $20 prices it's almost a sure bet that's what you are looking at, and not a true write blocker.

With the ability to instantly make any USB storage device 'read-only' by running it though a write blocker, you'll no doubt find other uses for one, such as malware analysis, or recovering infected systems. It's a handy thing for any security pro to have on hand.

Chuck van der Linden
  • 111
  • 2
  • It just isn't true that these can provide universal protection. The communication is still bidirectional and a determined designer can take advantage of that. In fact, it doesn't even have to be a malicious design -- one can easily image a USB mass storage-class device intended for development and verification testing that maintains a log of all incoming commands. Using one of these write-blockers is akin to blocking HTTP(s) POST requests in order to prevent data exfiltration, and then being surprised that some web forms use HTTP(s) GET. – Ben Voigt Oct 18 '22 at 20:26
1

Have you considered hashing your image and checking the hash after boot and/or before shut down? An attack that would replace your boot image seems a very low probability but the hash could give you peace of mind. A live image boot expects to be from read-only media so all changes are made in local memory (to be lost with power off) and not to the image thus that is not an attack vector. To attack your boot image the attacker would need to know you were not booting from a CD and know where you image was, what release, etc.

zedman9991
  • 3,377
  • 15
  • 22
  • Yes, in general this would help. But to be honest, when I look at the question now, I think my attack vector as described in its current state is purely theoretical and too specific. I also doubt any kind of attack would be that targeted. I should have described it as pertaining to the avoidance of unwanted data corruption. – Karol J. Piczak Jun 02 '11 at 16:03
  • So, a bit less specific version - would a read-only switch work as a reliable fail-safe mechanism when a write was not intended? Be it from malicious tampering with the live image or more probably just due to accidental erasing/overwriting when left mounted on another system. – Karol J. Piczak Jun 02 '11 at 16:04
  • The example device appears to need a special driver. So if properly configured with said driver and residing in the expected OS the answer appears to be yes. I personally dislike specialty devices with proprietary drivers like U3 as they take some control and decisions away from the user and replace it with unexpected behaviors and features. – zedman9991 Jun 02 '11 at 18:32
  • But wow would you check the hash? Where are ya gonna get the hashing software? If the USB drive is compromised, then it could be modified to have malicious hashing software. Asking untrusted software to validate itself is pointless. It's like asking aviation passengers "are you a terrorist?"; any self-respecting terrorist is gonna lie, in that situation. Thus, @zedman9991's answer does not seem useful. – D.W. Jun 03 '11 at 01:15
  • 1
    The live boot OS has hashing routines like MD5 so a one line script would address that. I take your point but in my mind you would have to be a very personally targeted individual as you are running from a read-only image that you controlled until boot time. The attack against the hash would have to find the personally created hash, the checking script, and modify all against that read-only image. This question was slightly modified from the original so please correct me as appropriate as I may be missing important points. – zedman9991 Jun 03 '11 at 12:46
  • Argh. @zedman9991, you completely missed the point. Having the live boot OS hash itself is *POINTLESS*. If the live boot OS is compromised, then the hashing routines might also be compromised to make it look like everything is OK. If the live boot OS is not compromised, then there is no need for it to hash itself. Did you even read my explanation? (I have no idea what you mean by "a very personally targeted individual"; the attack is totally trivial. Perhaps if the adversary is a cat, or a five-year-old, or someone who does not know how to write a shell script, you might be OK.) – D.W. Jun 04 '11 at 05:31
  • So how does the boot image get compromised if it boots read only? How does the hash value that is found elsewhere on the thumb drive get discovered and changed? – zedman9991 Jun 06 '11 at 12:52
1

If you don't have a hardware switch or don't trust the physical switch itself there is a hardware solution that will work, but requires copying data.

Burn your OS image to a dvd or hard drive and verify it with a hash. This is your back up. Now copy it to a few usb 3 drives, since they are cheap these days. Each time you boot with one, it will be considered dirty. After using it copy from the backup image to create a new usuable clean one.

If you need to use Apple or Windows, you can use solid state internal drives instead of usb drives and boot clean and virus free each time for the Internet. If you have to 'call home' for an app in which you use to create sensitive data with this solution will allow you to sign in with that app with a pristine OS copy, then unplug the Internet when that's loaded, then plug in your sensitive data for work.

Scripter Inc
  • 51
  • 2
0

The USB manufacturer Kanguru states:

Overall, a USB based write protection switch is extremely reliable as long as it is fully hardware based or utilizes a combination of hardware and software like found in our drives. The write protection within our drives is contained in two locations. The first is within the operating system where the device registers as a read only device. The second method is provided directly by the controller on the device itself. The reasoning for the second method is so in case the registry is corrupted in any away, the controller would be able to still enforce the write protection property.

As for how this assists with using bootable media, we would recommend using the Live CD version of whichever OS you are planning on using. This recommendation is due to a number of write protocols that may be requested for other version of the OS. If the device is in write-protection mode then these protocols may not occur resulting in a failed boot. Please note that the only drive Kanguru offers that supports using as a bootable device is the Kanguru Mobile WorkSpace (located at https://www.kanguru.com/virtualization/windows-to-go-kanguru-mobile-workspace.shtml) and this does not offer any write-protection.

Community
  • 1
zylstra
  • 103
  • 3