9 ms·

Chkboot

50 points by jakobdabo 11y ago

aftbit 11y ago
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 11y ago
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.
mjg59 11y ago
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.
- rogerbinns 11y ago
  Like all tamper detection it can be subverted as you describe. However it does raise the bar/costs for the attacker since their subversion has to be larger and more complex as it takes longer to write, needs more skill, more places to have bugs etc.
- 616c 11y ago
  I think what you are looking for is TRESOR. https://www1.informatik.uni-erlangen.de/tresor https://www1.informatik.uni-erlangen.de/tresor It has been on HN before. I doubt anyone is running it on tablet to secure their lights, TV, and toiles though. (Everyone, forgive the joke; but I loved this presumed user's artcile on Android light controls in hotels: https://news.ycombinator.com/item?id=11266796 https://news.ycombinator.com/item?id=11266796)
- jakobdabo 11y ago
  If the attacker can modify the kernel then I think you have already lost the battle. This script, as it says in README, checks that the files in /boot have not been altered between reboots.
  - mjg59 11y ago
    > If the attacker can modify the kernel then I think you have already lost the battle. By that argument, if the attacker can modify the contents of /boot then you've lost and this doesn't buy you anything.
    - jakobdabo 11y ago
      My understanding is (I may be wrong) that this script protects from physical attacks when the attacker covertly modifies your /boot partition (where the kernel resides along with the initramfs) while your computer is turned off. The attacker can not modify the other partitions because they are encrypted.
      - mjg59 11y ago
        The attacker modifies the on-disk copy of the kernel such that when userspace tries to read the kernel it gets given a backed up copy of the unmodified kernel. Chkboot says everything is fine, but in reality the system is backdoored.
        jakobdabo 11y ago
        I agree then, sorry I failed to see your point in your first comment.
  - keeperofdakeys 11y ago
    Here is a great talk by mjg59 about using the TPM, and why it's required https://www.youtube.com/watch?v=rML5DfYUh_k https://www.youtube.com/watch?v=rML5DfYUh_k
- zokier 11y ago
  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.
  - ycmbntrthrwaway 11y ago
    The attacker can compress non-random part of /boot partition to free some space for his "rootkit". The rootkit will reconstruct hard drive contents before running OS or just make it look like it is reconstructed through virtualization.
  - rdancer 11y ago
    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+calls https://www.google.co.uk/search?q=rootkit+intercepting+open+... [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-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
    - 11y ago
zokier 11y ago
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.
mercora 11y ago
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...
devit 11y ago
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.
cyphar 11y ago
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 11y ago
  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.

50 points by jakobdabo 11y ago

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 11y ago

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.

mjg59 11y ago

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.

rogerbinns 11y ago
Like all tamper detection it can be subverted as you describe. However it does raise the bar/costs for the attacker since their subversion has to be larger and more complex as it takes longer to write, needs more skill, more places to have bugs etc.
616c 11y ago
I think what you are looking for is TRESOR. https://www1.informatik.uni-erlangen.de/tresor https://www1.informatik.uni-erlangen.de/tresor It has been on HN before. I doubt anyone is running it on tablet to secure their lights, TV, and toiles though. (Everyone, forgive the joke; but I loved this presumed user's artcile on Android light controls in hotels: https://news.ycombinator.com/item?id=11266796 https://news.ycombinator.com/item?id=11266796)
jakobdabo 11y ago
If the attacker can modify the kernel then I think you have already lost the battle. This script, as it says in README, checks that the files in /boot have not been altered between reboots.
- mjg59 11y ago
  > If the attacker can modify the kernel then I think you have already lost the battle. By that argument, if the attacker can modify the contents of /boot then you've lost and this doesn't buy you anything.
  - jakobdabo 11y ago
    My understanding is (I may be wrong) that this script protects from physical attacks when the attacker covertly modifies your /boot partition (where the kernel resides along with the initramfs) while your computer is turned off. The attacker can not modify the other partitions because they are encrypted.
    - mjg59 11y ago
      The attacker modifies the on-disk copy of the kernel such that when userspace tries to read the kernel it gets given a backed up copy of the unmodified kernel. Chkboot says everything is fine, but in reality the system is backdoored.
      - jakobdabo 11y ago
        I agree then, sorry I failed to see your point in your first comment.
- keeperofdakeys 11y ago
  Here is a great talk by mjg59 about using the TPM, and why it's required https://www.youtube.com/watch?v=rML5DfYUh_k https://www.youtube.com/watch?v=rML5DfYUh_k
zokier 11y ago
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.
- ycmbntrthrwaway 11y ago
  The attacker can compress non-random part of /boot partition to free some space for his "rootkit". The rootkit will reconstruct hard drive contents before running OS or just make it look like it is reconstructed through virtualization.
- rdancer 11y ago
  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+calls https://www.google.co.uk/search?q=rootkit+intercepting+open+... [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-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
  - 11y ago

zokier 11y ago

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.

mercora 11y ago

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...

devit 11y ago

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.

cyphar 11y ago

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 11y ago
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.