
Chkboot - jakobdabo
https://github.com/grazzolini/chkboot
======
mjg59
This doesn't help if an attacker modifies the kernel to provide the correct
data regardless of the actual filesytem contents. You really need either UEFI
Secure Boot or a TPM-based measured boot to have confidence that /boot hasn't
been tampered with.

~~~
zokier
Could you comment on my idea of slight extension of chkboot-style
verification:

a) Use signatures instead of hashes and keep the "correct" signature secret.
This would prevent attacker from hard-coding correct looking output into the
tampered system.

b) Do not store the correct signature anywhere where the potentially tampered
system could read it. I'm thinking using smartphone or possibly some usb
module for verification, or maybe just rely on users memory (assisted with
something akin to SSH randomart fingerprints)

c) Fill free space on /boot with random data and calculate the signature for
the whole partition. This is to detect if attacker attempts to store backup
copies of untampered files.

To me it's not immediately obvious how attacker could tamper with boot files
without detection, presuming that their ability to tamper is restricted to the
hard drive (i.e. no firmware attacks etc).

edit: for clarification, I'm talking only hypothetically here, I'm not
considering this sort of system for personal use nor would I be recommending
it to anyone else.

~~~
rdancer
The attacker is not going to keep the SHA256 hashes, but the whole of the
original /boot. (Where, you're asking? Anywhere you forgot _Ring 0_ could
store data, and a few places you never even knew about.) Subsequently, he will
intercept system calls to open(2) and friends, and serve the saved data. This
is a fairly old technique: on the first page of a Google search[1], you can
find a Phrack article from 2009[2]. In fact the seminal work I believe is
_Reflections on Trusting Trust_ by Ken Thompson, set in print in 1984.

[1]
[https://www.google.co.uk/search?q=rootkit+intercepting+open+...](https://www.google.co.uk/search?q=rootkit+intercepting+open+calls)

[2] [http://phrack.org/issues/66/16.html](http://phrack.org/issues/66/16.html)

[3]
[https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...](https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)

~~~
zokier
> Where, you're asking? Anywhere you forgot Ring 0 could store data, and a few
> places you never even knew about

Could you be bit more specific about this?

~~~
kentonv
The BIOS has some flash memory. Various devices have flashable firmware. If
the machine is on the network, storage could be remote. Maybe the attacker
plugged a flash drive into a USB port. Maybe the attacker left a bluetooth-
accessible device nearby.

Or the attacker could just use the hard drive. Pick a random block. Chances
are decent the corruption won't be noticed anytime soon, especially if the
block is, say, at the end of the ext4 journal, which was probably clean at
shutdown anyway.

------
cyphar
This doesn't provide additional security. If your bootloader is compromised,
it could boot into a compromised kernel (bootkit) that will fake any syscalls
that attempt to figure out if the system is compromised. No, signatures and
hashes won't help (you can just return the old files, or store your changes to
the files and return the file contents with your changes reverted).

It's the same problem as UEFI defining that a certain UEFI variable will be
set if you booted securely -- but a malicious kernel could just fake that UEFI
variable.

Instead, you should have authenticated encryption for both /boot and your root
filesystem. GRUB has been able to boot from encrypted partitions for a while,
we should push for that to be the default (I'm not sure if it's authenticated
encryption though).

~~~
nailer
Good, I'm not the only one. I was waiting for the readme to mention how they'd
solved the chicken / egg problem here: you can't guarantee integrity of boot
until you've loaded the OS, and you can't load the OS until you've guaranteed
the integrity of boot. I was thinking I'd missed something.

------
aftbit
This script is really hard to use. There are two invocations:

    
    
        # chkboot
    

Checks for changes (once) then updates the file list. If you run chkboot
again, it will erase the changes list!

    
    
        $ chkboot-check
    

This basically just runs `cat` on a file made by chkboot.

Also, there's a long-standing bug where `chkboot -u` just doesn't work, making
the mkinitcpio hook useless.

A better interface would be:

    
    
        # chkboot-update
    

Updates hashes.

    
    
        # chkboot-verify
    

Checks hashes and writes any failures to syslog/stderr/logfile. Return code
tells you if it was successful.

Since you need root permissions to access many of the files in /boot, you
really can't avoid running chkboot-verify as root.

------
616c
I looked into the options and the best I feel available is separate /boot on a
USB key AND wrapping that key inside a tiny LUKS volume, so you need the key
inside of it and a password, which is poor man's two-factor for booting full-
disk crypto.

[https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651](https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651)

But as I know LUKS and other disk systems in Unix decrypt, and do not MAC then
encrypt, I wonder if I am wasting even more of my time I do not have to begin
with.

------
mercora
It seems like most people do not know that grub can actually boot kernels from
an encrypted boot partition. It does not protect the MBR or EFI partition, so
a manipulated stage1 loader might be able to pull off some attack but i am
always surprised how few people really use that...

------
zokier
I agree with mjg59 that this sort of system does not provide true security.
That said, I think it might be slightly more effective if the system verifies
the whole /boot partition instead of just the files within, especially if free
space is filled with random bytes.

edit: I also think it might be ever so slightly better to calculate signatures
instead of plain hashes. That would make it bit more difficult for attacker to
forge correct values.

------
devit
Look into [https://github.com/QubesOS/qubes-
antievilmaid](https://github.com/QubesOS/qubes-antievilmaid) and
[https://github.com/mjg59/tpmtotp](https://github.com/mjg59/tpmtotp) for
better attempts to provide an effective but still partial solution to this
problem.

