Bug 1319799 - Embed initrd into the kernel to prevent the Evil Abigail attack on a secure UEFI system
Summary: Embed initrd into the kernel to prevent the Evil Abigail attack on a secure U...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-21 14:44 UTC by Artem S. Tashkinov
Modified: 2021-09-24 02:21 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-13 04:18:05 UTC
Type: Bug


Attachments (Terms of Use)

Description Artem S. Tashkinov 2016-03-21 14:44:16 UTC
Currently Fedora's kernel and its modules are signed to allow booting in a secure UEFI environment, however all this protection falls apart since initrd is generated by the end user's PC so initrd can be trivially modified to contain any malware if the attacker has a physical access to the PC.

I propose to embed initrd into the kernel to prevent this kind of attack. Of course the following things have to be taken into consideration:

1) All storage drivers and options (LVM/MD/iSCSI/etc) must be built-in.

2) There must be a way to specify the root partition using just a single line of grub.cfg (if I'm not mistaken it's already possible since systemd is quite smart).

3) Since the aforementioned drivers can occupy quite a lot of space, I guess no other drivers (DRM and such) should be built-in, and instead the system should boot-up in the generic VGA mode (80x25) until the kernel is able to start the appropriate platform drivers.

Such a unified combo of the kernel and initrd could be an optional RPM package while for a usual situation initrd will keep on being generated.

Of course this still allows the attacker to modify grub.cfg but inspecting this file visually is a lot easier than verifying than initrd hasn't been tampered with.

https://blog.gdssecurity.com/labs/2015/12/23/introducing-evilabigail.html

While I was writing this proposal down, a different idea crossed my mind. As far as I remember, GRUB has certain hashing algos available, so in addition to this proposal, upon building a new initrd, it must be hashed and this hash must be shown to the user.

Upon booting GRUB will calculate the hash of a currently installed initrd and the user will be able to verify that the initrd is the one created during an update process. Also if the root partition is encrypted, the attacker will have no way of knowing the initrd hash sum.

Comment 1 Artem S. Tashkinov 2021-05-13 04:18:05 UTC
For the lack of interest.

Comment 2 Artem S. Tashkinov 2021-09-24 02:21:33 UTC
Funny Lennart is now talking about just the same.

http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html


Note You need to log in before you can comment on or make changes to this bug.