L15 (and all existing Librem laptops?) doesn’t respect the write lock switch on the SD card jacket. This isn’t a trivial issue. It means that:
-
You can never actually authenticate that an SD card hasn’t been written to, because by the time you compare everything, it might have been written to by some other (not necessarily rogue) process. This isn’t theoretical. Various Linux flavors like to update file access timestamps, for example. Which is probably why you get this bizarre notification saying “Don’t remove media, still writing” after you copy some files from external storage and request ejection.
-
There is no easy way to authenticate that an ISO wasn’t corrupted. Let’s say your OS gets trashed. You have an SD card on the shelf with an installer. You install the OS and boot up to the desktop. Then you read back the SD card and compare the hash to whatever is published online for the ISO (assuming there’s no MiTM between you and the published hash, like DNS poisoning, so take rigorous mitigations). But the hash often doesn’t match because some OS flavors will update a few bytes of the ISO in order to prevent random number collisions across installs. That makes some sense, but it makes it a lot harder to detect corruption. (Evil maid attacks can still occur because someone could walk into your house and write to the SD card anytime, then restore the switch to the locked position. For that matter, the more competent such attacks would also compromise the OS so as not to perceive the modification of the installation media, so verify on an unrelated machine. You might have to first overwrite the random number reseeding bytes, normally located in the first KB of the ISO. After comparing, and with your newly installed OS already booted, insert the SD card back into your own laptop. Destroy the first (partition index) block of the SD (not your harddrive!) and then properly eject it, so it can’t become a virus vector.)
My assumption is that this was simply a design oversight with previous laptops. I’m suggesting that this be added to the hardware QA checklist for L16 and other future laptops.
2 Likes
Not answering your question but … you can turn that off - and an ISO sitting on an SD card might be a case where you would want to do that (since recording the read-access is not usually useful in this scenario).
The access recording only affects the file system though, not the file itself. So the SD card as a whole might fail an integrity check but the file won’t.
The mere act of mounting the file system may alter the file system, thus causing the same issue.
Does any of this change if you do a read-only mount?
What about a flash drive with a write-lock switch? (I don’t own one but I believe they do exist.)
Doesn’t this more or less always apply? A competent hacker could make it so that when you boot from the ISO it presents one set of content (modified by hacker) but when you verify a hash it presents different content (unmodified).
Some protection against evil maid can be achieved by putting an encrypted (or preferably encrypted and authenticated) partition on the external drive. However that probably doesn’t work if your computer has died and you are attempting to use the portable media for recovery.
2 Likes
Thanks @irvinewade . I never use mount because my Linux distro does all that automatically upon insertion, so I need to find a flag somewhere in order always mount SDs as readonly. Good to know it’s possible, though.
Of course, that doesn’t address the problem of the OS installer deciding to update its own random seed, which happens at some point during its boot process. For that, I would need to use a USB with a writelock switch as you suggested. But to actually prevent an evil maid attack, I’d need to carry it around with me 24/7, which is impractical (because I don’t know when I’ll need it). At least an SD card can fit in a wallet or a cell phone case that literally does follow most of us 24/7.
“A competent hacker could make it so that” Correct. Perhaps you didn’t notice that in my post. Anyways it’s not an issue because the SD can always be verified in an unrelated machine which would not likely suffer the same attack. (It’s just that you need to assume that the SD has a virus the moment you remove it from that other machine.) But then problem is that, due to the lack of SD write lock enforcement on Librem, you can’t actually do that compare without opening a hex editor and patching the random seed back to a bunch of zeroes. Then you need to install a trustworthy editor on that other machine, and the trust problem just snowballs from there. All of this would be solved by hardware which respects SD write lock.
Unfortunately encryption doesn’t solve evil maid, although it does solve some subset of cases (as you said, “some protection”). The partition block (zero) is always unencrypted. It’s not code but it contains pointers to the partitions on the media, so I could change them in order load one which contains my attack kit, then branch to your encrypted one with my hypervisor already pwning the machine. It wouldn’t look any different to the user. Only an SD comparison on an uncompromised machine would reveal my attack.
1 Like
Don’t know about that but if it’s a specific SD card that you regularly mount then you can force it to mount read-only always by including it in /etc/fstab
man mount also points at man 8 blockdev and from there specifically --setro but I admit that I have never played with that.
Automatic mounting is in general troublesome when you need greater control over mounting but it is not a specific volume hence that can be included in /etc/fstab but you should be able to disable automatic mount with dconf-editor or gsettings (org.gnome.desktop.media-handling), again not something that I have tested.
… unless the disk device firmware is itself modified.
3 Likes
But then write-lock surely doesn’t solve evil maid since, as you set out initially, the evil maid can flip the switch to unlock, write whatever she wants, and then flip the switch back to lock.
In practice, the best defence is possession, which for an SD card is relatively practical.
If you are actually booting from the SD card then options for security are limited because then whatever firmware code executes before booting from the disk must be capable of supporting the needed security measures.
If you have a spare SD card that you don’t mind trashing, you could see whether it supports the actual SD card authenticated write security feature (RPMB), which would remove the need to bother to write-protect the disk with a switch … but then for actually booting from it the boot firmware would need to support RPMB.
1 Like
PS I managed to lay my hands on an SD card with a write-protect switch and …
I don’t think this is a Purism / PureOS / Librem 15 problem.
Testing on completely different hardware, not using PureOS, syslog shows
Write Protect is off
regardless of the actual state of the switch, and the file system is mounted read-write. So something else is going wrong here.
Ignoring the physical switch for a moment, using blockdev did work i.e. set the device read-only and then an explicit mount command but using default mount options did correctly give
mount: /home/irvine/mnt: WARNING: source write-protected, mounted read-only.
and mount -l | grep whatever did confirm that it was mounted read-only.
The only observation that I would make is that I am testing through a USB dongle card reader. It is possible that a native card reader (SD interface to host) would behave differently. What’s the device name in /dev that you see?
Of course from the perspective of the original question … you need to ask a pre-question: Will the Librem 16 even have a card reader?
3 Likes
Ooh, and one more thing: SD card - Wikipedia
Write-protect isn’t really a thing as far as security is concerned.
That doesn’t make it a bad thing to have but it protects against accidents caused by the owner, not against malicious acts by a third party who has access to the card and not against malicious acts by a third party who has access to the host - and, because it’s an optional feature, it may not even be there to protect against accidents.
The above link does also suggest other avenues of investigation if you really want to protect an SD card.
Also, I have never seen write-protect on an SD card that is not full-size i.e. not on mini-SD and not on µSD. So there is a risk that if more recent host devices only support µSD (not full size SD) then there’s no write-protect switch anyway. So you are left with seeing which, if any, of the various card firmware features for security might actually be supported by the controller, driver and software.
So there’s also the post-pre-question: If it has a card reader, will it be full-size SD or µSD only?
3 Likes
Thanks! Never knew about the fstab and setro approaches. Of course they still don’t solve the self-modifying installer problem, but at least they allow straightforward verification of the written ISO (or any other data) under the assumption that the OS isn’t compromised.
Deep thinking here. This would be a highly improbable attack vector because any firmware upgrading transaction would surely involve manufacturer signature checks on the device side. But, Pascal’s wager: it would be devastating and maybe hard to detect, and it would apply to any storage system, in principle.
That’s the most practical solution to evil maid. It just doesn’t solve the ISO corruption problem.
Very interesting! Sounds like you can permanently write-protect an SD card this way. As you said, you’d need to trash it if the ISO got stale, but at least then you probably don’t need to carry it with you 24/7.
A native SD card reader should behave differently. The reason you’re not getting write lock respect is likely that your USB dongle doesn’t respect it, and everything else inherits that.
OMG it’s internally on USB! Probably same crappy firmware as on your side, just a different OEM. No wonder it fails.
/dev/sda
Alcor Micro Corp. Multi Flash Reader
No clue. Hopefully it will have a full size SD reader which respects write lock (because as you said, no smaller version has one to begin with). But I get it: it’s going the way of the dinosaurs. The bottom line is that it just saves a lot of unproductive work when dealing with ISOs and other situations where you want nonpermanent readonly behavior.
In any event, I find your contributions outstanding, as usual, whether I like the implications or not.
1 Like
Yes, that is one option within the functionality of an SD card - and for the cost of an SD card if holding an ISO, that might be perfectly feasible.
However RPMB is different. RPMB means that you can forever alter the contents provided that you possess the secret key (presumed to be strongly randomly generated and actually kept, you know, secret). It is a relatively small area (e.g. 4MB). It could form part of a secure boot solution e.g. hold a hash of the contents of the boot area, providing that the firmware knows to read the hash from the RPMB and then calculate the hash of the boot area and compare the two hashes before transferring control to the boot area.
This is not uncommon. For example, it’s the same on the Librem 5.
I’m not totally convinced that this is a USB problem, given that the write protect switch is an optional feature of the SD spec. Note that the card itself does not implement or respect the write protect switch. It simply advertises it as a statement of intention to the host and it is up to the host to respect the switch by not allowing or generating any writes.
I’m just wondering whether I have any computers with a native card reader for full size SD cards …
2 Likes
Are you too young to remember the string in the doorjam technique? When I was younger there was a lot of paranoia about people sneaking in and sifting papers and so on, now the government has zero respect for the amendments, search and seizure, nothing. When you talked to the old Vietnam era guys they would tell you about the stuff they had been shown in training like leaving strings or paper in a doorjam, if it was on the ground when you came back someone had been in your room.
1 Like
For what it’s worth, I tested the same SD card on a computer that has a full size SD card reader and with the card reader seemingly native, not through some internal USB connection … and it worked properly.
Inserting the card with the switch in the LOCK position … /dev/mmcblk0 appeared, and syslog showed it recognised as “ro”, and blockdev --getro /dev/mmcbkl0 said “1” and a default mount did mount the file system read-only and attempts to write to the file system gave the expected error.
Likewise, inserting the card with the switch in the normal position, everything worked oppositely and correctly and as expected.
However some online discussion of this problem spurred me to go and find a much older USB card reader dongle that I have and it all worked properly. So USB is not in and of itself a problem, and current kernel software is not in and of itself a problem.
Maybe that is a workaround for you but it would have its limitations e.g. a much older dongle may not support SDXC and e.g. may be much slower (USB 2.0 only).
My guess is that all the chips in the world that do SD-to-USB are generic and come out of the same factory in China 
and these days someone designed said chip to ignore the LOCK switch - since that switch is security theatre anyway.
2 Likes
Cool! 4MB is more than enough to at least store the hash. Granted you would need some special way to read the storage area, as presumably it’s not part of the normal storage. Probably I can find some tool to do this. (Then I have to authenticate the tool against supply chain attacks. Infinite rabbit hole but at least this is an improvement!)
I have an old laptop with an actual SD reader not on USB and it does respect writelock. This is in hardware. It was based on the same feature of floppy disks in ancient times.
1 Like
Yeah this would seem to be the bottom line. But it’s not security theater because it guarantees against corruption after verification. It just don’t solve evil maid. Anyway it sounds from your research like this won’t be fixed in L16 because they’ll just order the same unit from the same factory. To be fair, they might not even be able to find an alternative at this point.
1 Like
No, it doesn’t. The LOCK switch is purely advisory. There is no connection between the firmware or circuitry on the card and the state of the LOCK switch. So if a host computer even notices that the LOCK switch is on, the host computer can still issue “writes” if it is reckless, compromised, broken, malicious - and those “writes” will be executed regardless by the card.
So you probably want a storage device where the LOCK switch is implemented by the storage device itself but advised to the host. If the host ignores the advisory then the write will fail on the storage device.
Or you want something cryptographically strong, which solves both the write protect problem and the evil maid problem.
The online discussion that I found implied that this is a “recent” change (last 10 years, not sure). That’s why I went looking for an older dongle.
So if the Librem 16 has a card reader at all and if it has a full-size SD card reader then it may be unlikely that it will use an older chip. For an all new design, it’s likely to use current chips, and older chips may not even be available any more.
So for your actual original question, I would be pessimistic.
But you at least have alternatives to explore.
1 Like