Hacker News Reader

Comment by mjg59 | Hacker News Reader

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.

View on HN

I think what you are looking for is 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)

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.

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.

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

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

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

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

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.

You won't likely have the opportunity to ask the attacker either. This uncertainty is an inherent part of the problem.

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.

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.

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

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.

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.

I agree then, sorry I failed to see your point in your first comment.

Here is a great talk by mjg59 about using the TPM, and why it's required https://www.youtube.com/watch?v=rML5DfYUh_k

Reply on news.ycombinator.com