Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SeaBIOS as heads payload? #718

Closed
mikebdp2 opened this issue May 8, 2020 · 4 comments
Closed

SeaBIOS as heads payload? #718

mikebdp2 opened this issue May 8, 2020 · 4 comments

Comments

@mikebdp2
Copy link

mikebdp2 commented May 8, 2020

Compared to a Linux kernel which is currently used by heads, SeaBIOS has a much smaller source code/binaries - means, a significantly smaller attack surface and less space consumed in CBFS - and yet SeaBIOS supports a TPM. Linux kernel flashed into a BIOS chip as a heads payload - is quickly outdated, so the people have to choose between constantly updating it or sacrificing some security.

Also, SeaBIOS supports booting the LZMA-compressed floppy-based hobby OS like KolibriOS or FreeDOS added to CBFS, which provides some really interesting capabilities: i.e. add a KolibriOS https://kolibrios.org/ (tiny opensource OS written on ASM, with GUI and lots of apps all inside a 1.44MB) - and if it supports your Ethernet controller: you can browse the Internet with a simple web browser, or have a secure chat with your friends using a IRCC client with a custom encryption mod like http://board.kolibrios.org/viewtopic.php?t=3734 - all under a simple OS. Which doesn't suffer from the vulnerabilities of a complex OS like Linux, with SystemD (https://linux.slashdot.org/story/17/07/29/1647255/systemd-named-lamest-vendor-at-pwnie-security-awards) and - even if you choose something like Void (runit) or Artix (OpenRC) to avoid a SystemD - still many other issues.

SeaBIOS source code is relatively tiny (just ~50k code lines, compared to Linux kernel's ~27.8 million or Tianocore's ~1 million) and really easy to modify, as I've proved with some custom mods like https://review.coreboot.org/c/coreboot/+/32351

@osresearch Do you think, given that SeaBIOS supports a TPM and consumes much less space in CBFS, a custom fork of SeaBIOS with some additions could become a better payload for heads?

@tlaurion
Copy link
Collaborator

tlaurion commented May 8, 2020

@mikebdp2

Compared to a Linux kernel which is currently used by heads, SeaBIOS has a much smaller source code/binaries - means, a significantly smaller attack surface and less space consumed in CBFS - and yet SeaBIOS supports a TPM.

As answered in the other tickets you opened, Heads addressed threat model is to use the TPM as early as possible to establish attestable root of trust to be able to measure coreboot itself from coreboot romstage cache, where other propositions requires all the chain to be trusted to be able to take any measurements of later steps. Here, relying in seabios using TPM to measure anything would be forward measurements, while firmware itself could have been compromised already, meaning only what is going to be trusted to launch operating system can be validated forward, not validating earlier prior stages, which are considered required to an established RoT. Heads is already criticized for not using ACM/TXT in its root of trust(coreboot being measured by the CPU so the root of trust cannot be hacked), going SEABIOS would be considered a regression to the project in that sense.

Linux kernel flashed into a BIOS chip as a heads payload - is quickly outdated, so the people have to choose between constantly updating it or sacrificing some security.

Heads is used as a static root of trust in this scenario. No unnecessary modules are in the monolitic kernel and additional modules needs to be loaded prior of use, modifying the TPM measurements by calling a insmod wrapper, which extends TPM measurements to invalidate what is later used to secure the boot process. and used in TOTP/HOTP. If the PCRs do not match, TOTP/HOTP default boot won't match and fail.

Heads relies on cryptsetup, gpg2, kernel cryptomodules, lvm and kexec basically, to offer what it offers. When a user defines a boot default and decides to create a Disk Unlock Key to unlock LUKS encrypted container, the TPM measurements are used in combination with TPM measured LUKS header, sealed inside of the TPM NVRAM space, to generate a new LUKS key which is added in the LUKS header. The released key stored in password protected NVRAM space can only be released if TPM measurements are valid, LUKS header is valid and Disk Unlock Key typed to unlock NVRAM space is valid. Consequently, the default boot can only launch if the Disk Unlock Key is typed on that computer, protecting the user from video recorded LUKS passphrase being typed in public space, so that a bad actor cannot simply clone SSD in 15 minutes and decrypt content at leasure at a later time.

Also, SeaBIOS supports booting the LZMA-compressed floppy-based hobby OS like KolibriOS or FreeDOS added to CBFS, which provides some really interesting capabilities: i.e. add a KolibriOS https://kolibrios.org/ (tiny opensource OS written on ASM, with GUI and lots of apps all inside a 1.44MB) - and if it supports your Ethernet controller: you can browse the Internet with a simple web browser, or have a secure chat with your friends using a IRCC client with a custom encryption mod like http://board.kolibrios.org/viewtopic.php?t=3734 - all under a simple OS.

That may be interesting for #590

Which doesn't suffer from the vulnerabilities of a complex OS like Linux, with SystemD (https://linux.slashdot.org/story/17/07/29/1647255/systemd-named-lamest-vendor-at-pwnie-security-awards) and - even if you choose something like Void (runit) or Artix (OpenRC) to avoid a SystemD - still many other issues.

Yet again, Heads linux payload is secured by the TPM in the sense that once the user decides to drop in recovery shell to go interactive, TPM measurements are extended and TPM measurements cannot be used to launch default boot options either.

SeaBIOS source code is relatively tiny (just ~50k code lines, compared to Linux kernel's ~27.8 million or Tianocore's ~1 million) and really easy to modify, as I've proved with some custom mods like https://review.coreboot.org/c/coreboot/+/32351

@osresearch Do you think, given that SeaBIOS supports a TPM and consumes much less space in CBFS, a custom fork of SeaBIOS with some additions could become a better payload for heads?

The current avenue is to drop custom patch and rely on coreboot VBOOT+Measured boot to rely on upstream coreboot in the future.
Relying on SEABIOS might be interesting if user is willing to drop librem-hotp-validation, Disk Unlock Key usage and verified boot components currently scripted inside of Heads. But the current roadmap, on my side, is a bit different: https://fosdem.org/2020/schedule/event/firmware_hodorateatria/

The current trust lanscape is: We have to trust firmware (currently just CBFS BIOS region, I think we need to extend that to whole SPI unlocked region, including other blobs). Then, coreboot measures also with TPM the payload, which contains the tools requires to establish the rest of the trust (sha256sum, gpg, kexec, lvm, cryptsetup... and flashrom, altogether. Else, what is telling you that the firmware you are going to upgrade to, internally, is good (good being signed, integrity validated). Then what tells you that your flashrom, that you use to go TPM-less with Nitrokey/Librem Key, was not tampered with to verify (backup and measure with precedent tools named)? TPM-less is also a stalled project ATM.

Linux payload is minimally trusted right now. Like said previously:

  • a call to recovery extends TPM and invalidates measurements..
  • depending on Librem Key/ Nitrokey requires usb modules already being loaded which comes with its subset of risks
  • insmod is a wrapper to busybox insmod
  • The whole gui-init or generic-init is a jailed in user experience. Going "in" linux payload invalidates root of trust by calling recovery above
  • Linux as a payload is trusted in the sense that it is used to support required hardware of a mainboard. For example, I will need to update the kernel to support later board versions which replaced their sdcard reader from Ricoh to Realtek, which is not provided in modules options of the actual kernel. Other then that, vulnerabilities that can be used to attack from withing the recovery shell would modify /boot content, which would be invalidated by externally signed digests verified against public key inside of CBFS measured by TPM, or attempt to gain persistence by modifying the ROM itself, which would be catched by TPM early measurements and invalidate default boot or remote attestation through TOTP/HOTP. Note that the same logic is applied when verifying bootable ISOs against detached signed ISOs for supported distributions. First firmware is remotely attested. Then when use wants to boot ISO on removable media, ISO is verified against public keys, and if verified, GRUB configuration is proposed for user to boot. Here again, Heads was criticized in the past for TOCTU, since the ISO itself is not copied in ram prior of verifying integrity prior of booting from it. Critics implied that content of sdcard could change between moment of verification and boot from it, just like what is actually enforced also in the verified boot part relying on GPG to enforce verified boot. SEABIOS would also be a regression on that point.

Thanks for challenging the situation. I think other questions will be more specific and they are more then welcome!

@paulmenzel
Copy link
Contributor

@mikebdp2, after reading https://trmm.net/Heads and https://trmm.net/Heads_FAQ, I do not understand your request to use SeaBIOS. Your motivation to use SeaBIOS seems to be to save space and to use it’s boot menu. But that is not the goal of the Heads project at all. Also, the main objective of SeaBIOS (“C-BIOS”) is to provide legacy BIOS services.

Heads is not just another Linux distribution -- it combines physical hardening of specific hardware
platforms and flash security features with custom Coreboot firmware and a Linux boot loader in
ROM.

The main argument for a Linux payload is, that it’s the same code base as the Linux kernel you are going to start, and the GNU/Linux distribution allows to write your own scripts giving you all the flexibility you need in an environment you need. (How do you do two factor authentication with SeaBIOS.) Despite the larger code base, your LOC comparison is unsound, as the rom/boot kernel (what was the naming again?) only uses a fraction of that.

Also, you are mistaken, that it’s required to update the ROM kernel often. The majority of the found security issues found in the Linux kernel, depending on the configuration, do not apply to it, so no updates are needed. Once it works, you are not supposed to update it anymore.

What would be used as the boot loader in your scenario?

Having said that, your use cases are of course valid, but they not align with this project. With the comments here in mind, I recommend to clarify your vision, and recommend to start a new coreboot/payload distribution for your use case.

@tlaurion
Copy link
Collaborator

@paulmenzel @mikebdp2 the rest of the information pertinent is under #717. Feel free to close this ticket if your question has been answered.

@mikebdp2
Copy link
Author

@mikebdp2 Thank you! Please answer at #717 before we could continue there as well (these discussions are interdependent a bit)

@tlaurion tlaurion closed this as not planned Won't fix, can't repro, duplicate, stale Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants