brent timothy saner on 20 May 2009 13:56:00 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] kon-boot: there goes the neighborhood

Brian Vagnoni wrote:
> I imagine encrypting the system partitions would extremely impair this type of attack; correct?

correct. fulldisk encryption would render this virtually[1] useless. 
however, physical access is a huge risk, so.. :)

[1] there are attack vectors that are possible with any ol' livedisc 
even with a fulldisk encrypt. example case follows:

1. / is encrypted, except for a /boot partition (or, at the very least, 
an initrd- this is NECESSARY because an unencrypted "kernel" of sorts is 
necessary to understand and know how to access the encrypted volumes.

2. attacker replaces initrd with keystroke logging, key snarfer, etc. 
unknown to you.

3. you boot normally, putting in your password or make the key available 
(via a decrypt usb stick, etc.).

4. system boots, etc. with the initrd having passed malicious code on to 
the live kernel, or any other part of the running system that will send 
the collected key to the attacker.

5. the attacker now has your disk encryption key.

plus there's always the "coldboot" exploit discovered by princeton[2]. 
there is, however, work being done on a mechanism to prevent this 


1. NEVER trust /boot after someone else has had access to your machine, 
or it's been left somewhere out of your eyesight, etc. alternatively, it 
may be a wise idea to install grub and initrd's and kernels to a usb 
stick if your BIOS supports booting from usb (or to cd, etc.). it would 
be wise to make a copy of a known pristine /boot and overwrite the 
possibly-compromised /boot from livecd (don't forget to overwrite the 
MBR with a pristine copy, too! you can find tutorials on using dd to 
backup/restore the MBR online).

2. password-protect grub that disallows editing of run options. this is 
not a very strong mechanism, but every little bit helps.

3. disable booting from CD/USB/PXE/etc. from the BIOS, and 
password-protect the BIOS. again, this is very weak (most BIOS have a 
backdoor password- or you can just clear the CMOS). but again, it 
doesn't hurt.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --