I just bought an L14 with coreboot+SeaBIOS firmware (i.e. without a Librem Key). I did so on purpose because I generally do not like the idea of needing an additional thing to be able to use a laptop. Neither do I like the added complexity, or having one less usable USB slot.
Still, I would like to be able to be certain that the firmware has not been tampered with.
Is there a way to check that, other than Librem Key?
Can I just somehow read the firmware from the OS so that I could calc its hash and compare it with the hashes from Purism?
a) you don’t need the Librem Key to boot i.e. you can choose to go ahead and boot without it (and without that integrity verification), and
b) you only need the Librem Key at boot time so you aren’t really losing a USB slot.
I suspect that any mechanism to verify integrity without a Librem Key will bring you “added complexity”,
Some of the complexity is that boot files will legitimately change from time to time, and there may be no easy way round that no matter how you do it.
The integrity verification is covering the boot partition (and, optionally, selected files from the root partition).
I don’t think there’s any way to verify from the operating system because if your computer has been compromised then it is already too late - and compromised software can report the uncompromised contents (theoretically speaking).
I am talking about verifying the firmware only, i.e. piece of software flashed somewhere in the motherboard. Isn’t that accessible from the OS (vs from Librem Key)?
Not worried about tampering with files on the disk because of full disk encryption (including the boot files).
I suspect that any mechanism to verify integrity without a Librem Key will bring you “added complexity”
It will, but I will only need to use it occasionally (vs every boot) just to checksum the firmware.
Have you confirmed that? My understanding is that the boot partition is unencrypted while the root partition is encrypted.
(Just because something is encrypted doesn’t mean that it can’t be subject to modification and hence doesn’t mean that it is not worthwhile to verify integrity. However some disk encryption choices give you integrity built-in. And some don’t.)
$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 238.5G 0 disk
└─sda1 8:1 0 238.5G 0 part
└─luks-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 253:0 0 238.5G 0 crypt /
Just because something is encrypted doesn’t mean that it can’t be subject to modification
Sure — it can be modified while the LUKS is open/mounted. But all parts of the OS are susceptible to such modifications, not just the boot stuff, so I don’t see much value in verifying the latter only.
Would such an attack be practical? Maybe. Maybe not. The important point is that confidentiality is not integrity.
If you want integrity with LUKS itself (which then covers all content on the disk) then you need to use the experimental--integrity option or verify only the important files from outside of the file system (which is the approach taken using Pureboot with the Librem Key).
I can’t think of any scenario where it would be practical. What is the attacker going to do, just write some random bytes somewhere on the disk? The most they would achieve is mutilated/unreadable filesystem.
If you want integrity with LUKS itself
I want integrity just with the firmware for now.
Besides, integrity with the filesystem under LUKS is easily achievable with BTRFS. If a file is mutilated you’ll get I/O error trying to read it. Also, the integrity of the whole FS can always be checked with btrfs scrub.
Hi Greendrake,
Maybe you could think about this problem of firmware integrity validation in a different way.
I will explain: you would like to validate the integrity of your firmware, but at a higher and also later stage of execution (OS) that is also less privileged than what was just executed before actually launching the OS. You would then compare some hashes provided by Purism with your own computation for your firmware that just ran. But how can you prove that the entire platform is not already compromised, manipulating your calculation and feeding you a fake result that will satisfy what Purism tells you the hash should be?
This tells us of the complexity to provide a valid attestation of the firmware state after that firmware has already run in the boot chain. How can you trust any code already executed via a post-execution validation process?
Pureboot along with the LK has exactly been designed to solve this problem. It can attest that not a single bit was changed in all the code that the firmware ran upstream in the boot chain, and that all configs and variables used in this process were exactly the same as that previous “Known Good State” that was frozen at some point when the shared secret between the TPM and the LK was last established.
To me, Pureboot + LK is the best security currently available that can prove firmware integrity and statelessness.
Though theoretically it is possible for malicious firmware to manipulate the OS in order to make it report good firmware test results, I tend to be satisfied that it is not practicable with full disk encryption including boot.
For such an OS to be attacked, the firmware needs to continue to run when control has already been passed to GRUB for unlocking the LUKS device. Is that possible? Correct me if I’m wrong, but AFAIK once control has been passed to GRUB, the firmware is no longer running (IME aside, which should be disabled on all Purism laptops). That means when the disk is unlocked, there is nothing running anymore that could manipulate its contents (apart from the OS). The GRUB bootloader itself could in theory be compromised by the firmware and do the OS manipulation, but I don’t think there is enough space in it to embed malicious code capable of modifying the OS to the extent that it would report false firmware test results.
Even assuming that the firmware, while it is running, has access to the OS, what could it possibly do, hack the hashing tool so that it reports good hashes when a certain bad one is to be returned? Heck, the firmware dump could be hashed by many different tools, copied to another machine and hashed there etc.
So far the only possibly feasible attack I think is this:
— [OS to the firmware chip]: Okay, give me your full dump.
— [Firmware chip]: Sure, here you go. [passes good dump instead of the malicious crap factually residing in the chip]
But I don’t know, is that even possible? Doesn’t the OS just read the chip contents like a passive memory card — as opposed to like requesting an active API?
It a nut shell, whereas testing a firmware from a full-disk-encrypted OS booted by that firmware is still arguably less secure than Pureboot, it can probably give me just enough peace of mind. So, I am looking for tools to dump the firmware / check its hash from the OS, and also for the original hashes to compare the results with .
OK, we are getting into obscurity, some would say paranoia, but sure … the firmware sets up a Virtual Machine and the software is actually running inside a VM even though the software may not be able to determine that fact. Then, whenever the OS tries to read firmware, the firmware contents can be falsified. Otherwise everything else runs normally, including of course GRUB, LUKS, …
(and once LUKS is used to open the encrypted partition/disk, the encryption master key can be stolen and thereafter the whole encrypted partition/disk can be read or written without limitation, even if you have a file system that supports integrity).
That is my recollection but then I thought maybe that it’s not implemented yet.
Sorry, in my latest reply, I hadn’t realized that you wanted to stick with an encrypted /boot.
Pureboot in this case would not be a candidate: it needs an unencrypted /boot partition for its validation (or rather attestation) process before launching the target OS.
But then again the fact that it’s left unencrypted is nothing to worry about since that partition not yet mounted on the target rootfs is considered R/O and its unmodified state validated by the Secure Boot-style check of every single file in it.
It is also needed for the anti-rollback feature using the TPM monotonic counter.
Another great advantage is transitioning from the payload to the target Linux OS directly, by using kexec to launch the initrd without having to use any bootloader. Gone with bootkits, vulnerable bootloaders or meddling with commandline parameters. This alone greatly decreases the attack surface - one less step an attacker could eventually target.
I think nothing lives after all the boot chain has been executed and the target OS is launched, except for the stuff in Ring -2 SMRAM and SMIHandlers that was setup during Coreboot run. So what could possibly be further compromised if an attacker had already gained a foothold at this stage?
I really don’t know. But something I am sure of, is that if one can set foot and compromise any level, he owns it and also owns any less privileged level above it.
That certainly makes sense when the compromised, more privileged level lives alongside the less privileged one.
But, as you noted, it doesn’t live after the boot chain has been executed; and when it does live, it doesn’t have access to the less privileged one because it is not unlocked yet: it can surely mutilate the OS but it can’t sensibly patch it.
I would like to explain what owning a lower level (in this case Ring -2 SMM) really means and can compromise your running OS,
I already mentionned that Coreboot will setup system management mode, SMRam and SMIHandlers. We hope that this was carefully done (SMM, also sometimes called “God Mode”!), that everything was properly configured and that the SMRam is protected and D-Locked. SMRAM is some range in the DRAM space that cannot be accessed nor written to, except when the processor is in system management mode due to some SMI interrupt calling for immediate action.
The attack was named Attacking SMM Memory via Intel® CPU Cache Poisoning, described by Rafal Wojtczuk and Joanna Rutkowska at ITL.
Its goal is to force execution of unauthorized code crafted by the attacker, while in highly privileged-mode smm - but we normally cannot read or write to SMRam, right?
It so happens that they found a design flaw in some chipset in use at that time and could manipulate a register called MTRR (Memory Type Range Register) and change the SMRAM range - which is obviously normally uncacheable - to cacheable Write-Back. Then they attempt to write their own code from somewhere in DRAM to the write-protected SMRam, resulting in nothing being written there, BUT the malicious code is now cached - the cache has been poisoned - and next time an SMI is issued, the SMIHandler that will be executed is the malicious code now fetched from the cache instead of from the physical DRAM location. Neat trick. You can imagine the consequences!
I could for example have malicious code execute in your running OS, triggered by you typing some keystroke causing the EC to trigger an SMI, the SMIHandler executing in smm now being my malicious shellcode. Or it could be a thermal sensor reaching a threshold causing an SMI. Or any other event causing to enter management mode.
I hope this was not too technical a description of the mechanism. The chipset flaw was corrected in later chipset architecture. This was just an exemple of what can be done in order to compromise a running OS from lower rings.
Right, so, in a nut shell, the modus operandi would be to wake up the malicious firmware while the OS is running (and the firmware is supposed to be completely off).
Well, that’s exactly why I would like to verify the firmware, preferably from the OS or by way of booting from some Heads/LK-like USB flash — even though I am conscious that such a verification itself can in theory be thwarted/fooled by super-smart-ass hackers’ tricks. As you noted, installing full-blown Pureboot requires relinquishing encrypted /boot which I am not comfortable with.
Is you concern the confidentiality of information in /boot ?
Because Pureboot will ensure the integrity of information in /boot.
Seeing as this topic is still going …
Sure. Writing some random (uncontrollable) bytes to a known place on the disk could be extremely helpful e.g. to “comment out” one or more lines of a shell script. It would be difficult to write a shell script that runs as root and works securely when one or more lines are randomly removed. Of course there are still significant challenges with implementing this attack that are somewhat outside the scope of this topic but I wouldn’t rule it out.
No, it’s just the exposure of it. Anyone having physical access to the laptop in my absence can modify the boot partition however they like. Of course Pureboot will detect it, but now I would have to use Pureboot — which I most likely would not have to if I keep /boot encrypted.
I don’t think there can be a “a known place” on an encrypted disk. If the attacker wished to damage/disable a particular shell script, they would have no reliable information as to where exactly the encrypted bytes of that script reside on the disk — it would depend on the OS, filesystem, how much data has been written to it etc. No sane hacker would ever try to guess where exactly this needle is in the haystack.
I think for a fresh install or recent install that’s not true. Over time any given file will move around if it gets updated. I would guess that there are some important shell scripts that would infrequently or never get updated. Of course any such assertion depends on the particular file system in use i.e. one where a file is located by knowing what logical block address it is stored at (starts at) and that LBA doesn’t gratuitously change.
While this topic started out talking about the Librem 14, if you look at the way you flash the Librem 5 (when using the LUKS variant) and even if you re-encrypt with a new LUKS master key, every file should be in an exactly known place at the time of flashing.
To give an illustration of how this attack might be practical, imagine the fairly common shell script architecture where a master script runs all the scripts that are in some directory (e.g. xyz.d/). If one of those scripts does something important then it should be reliable to “delete” the script by overwriting its #!/bin/sh (with uncontrollable bytes) and it then becomes a question of how the master script handles that error.
Having said all that, I think there may be far more shell scripts of interest in the root file system, as compared with the boot file system.
Just asking another question … what happens if someone replaces your encrypted /boot with an unencrypted /boot ?
The encrypted /boot is just a directory on the single encrypted partition, not a separate encrypted one. You can’t “replace” it. Pretty much like with the shell script example, one can only guess where the boot files are on the block device (and if they overwrite those, they’ll become completely nonsensical sequence of bytes upon unlocking the LUKS device).
.