On Sat, 2010-06-05 at 18:21 +0200, Arno Wagner wrote: > So we are talking about a data-change attack here? This one is > not very relevant, because it requires to steal and give back the > encrpted medium or to get access that allows changing the on-disk > data (requires root permissions in most cases), but not to get > enough permissions to sniff the passphrase when it is input by > the the user the next time. See later parts of my previous mail. > So it is even worse: The attacker cannot judge where to change things > and the attacker cannot judge whether a change done was efecctive, > ineffective and/or becomes obvious to the attacked user. See later parts of my previous mail. > Well, dm-crypt does, but the rest of the system does not. If you > can change the data on disk, then you have root access (typically, > some admin may have screwed up and given user access to a block > device representing a dm-crypt partition). No? Why you can simply take a laptop that was powered off, and mount it on another machine... > > With "using it correctly" I basically mean, that it only works, if > > really the whole system (e.g. laptop HDD) or so is encrypted. Not only > > the data partitions and swap, but also the root-filesystem itself. > > The critical place is now the bootloader and /boot (kernel+initrd). > > There's no way to encrypt and therefore secure those guys against > > compromise. > And thereby you actually do not need to encrypt the root filesystem > at all in most cases, as it does increase security only marginally. Actually it makes a lot of sense... if booting, e.g. from a usb stick that is always with you (and therefore secure from attacks). > > A simple (and I guess the only way) to avoid this, is if you take > > bootloader/kernel/initrd always with you, e.g. on a small USB-stick that > > can be attached to your keyring. > > The attacker having physical access or breaking into a running > system and getting root permissions was your attack scenario. Uhm? I rather talked about physical access,... on a powered off system. But in principle it does not matter whether powered off or not, as you can add hotpluggable volumes to the system. > In the first case, a determined attacker could still install a > (potentially physical) keyboard sniffer or patch attack code into > the BIOS chips and maybe unused disk areas. BIOS chip and other hardware CPU, etc.) is of course always an issue we can never really solve. keyboard sniffers can be partially knocked out by using e.g. encrypted keys (gpg, openssl) to unlock the passphrase. An attacker would only sniff the passphrase for the encrypted key,.. not the key to decrypt the keyslot itself. > In the second scenario, > you cannot take the bootloader/kernel/initrd with you. Why not? Simply after the system was booted,.. unplug the stick... > If you put all non-encrypted parts of your system on portable storage > and take it with you, yes that helps a lot. It is not perfect though, > as an attacker could break into your system while you are using it. > And takeing the storage with you does not protect against hardware/BIOS > keyboard sniffers at all. > > Keep in mind however, that these are high-effort attacks and > are unlikely to be conducted against you due to cost reasons, > unless you are specifically targetted. As I said... > > So much for the intro ;) Now where does the attack on this come in? > > I guess an attacker could exchange one of your encrypted volumes with a > > non-encrypted (!) volume (that is compromised of course), or you could > > Why is that a problem? Decryping a non-encrypted filesystem (as you would > do on access) is immediately obvious, as the filesystem will be > unaccessible, with all data turned to random bytes.. Yes yes,... read my whole email before commenting ;) > There will be no script "around" if your secure initramfs is still secure. Yes yes,... read my whole email before commenting ;) > > As it has no knowledge that setting up the mapping failed (perhaps just > > a warning was given) it may simply try to mount via LABEL=root. > > And this will most likely work. The attacker gave us an evil volume, one > > that is simply not encrypted. He guessed the right LABEL or he new the > > UUID (this is for example leaked out with many bug-report tools in > > Debian) and the scripts actually mounting the root-fs will simply do so > > and hand control over from the still secure initramfs image from your > > USB stick to the compromised volume. > > I see the issue. *G* > My conclusions: > > 1. This is not a dm-crypt or LUKS problem at all I'm strongly sure that I said this sometimes :) > 2. Helpful automatization that tries to "access something" in the > presence of errors is a security risk. This is well known. Whether > Debian currently overdoes it in the automation department I cannot > say. I use Debian a lot, but I do not use "crypttab" as it strikes > me as a not too good idea in the first place. However I would be > surprised if information from "crypttab" was used for unencrypted > mounting at all. No it would not, but you have e.g. /etc/crypttab: # <target name> <source device> <key file> <options> rootfs /dev/sda1 whatEver luks /etc/fstab: LABEL=root / ext4 defaults 0 1 Now cryptsetup's initramfs scripts fail to set up the device,... but just give a warning or so. Then comes the initramfs script, which would do the actual mounting of the root-fs. It will not look for /dev/mapper/rootfs, but simply use /dev/disk/by-label/rootfs and that one might be there, if an attacker simply replaced the disk by a non-encrypted one. > And the user should either get an error message > or not be asked the passphrase. Both would be highly suspicuous. > > 3. Just mount your encrypted volume manually and the attack goes away. Quite impractical for daily use... especially on the root-fs > 4. The whole scenario is unrealistic. An attacker with physical access > (required to change data on a non-running system) would leave some > kind of keyboard sniffer/recorder and collect the passphrase later. Not necessarily. If he already has a copy of the disk, and just want's to access the data,... he only needs the key... > IMO the whole thing is a nice thought experiment, but not a practical > risk. I've tried it already with a friend,... worked quite well... the hacked root-fs-volume even sent me the contents of his boot-usb-stick including his key. Of course that one was still gpg encrypted,.. but then I can do dictionary attacks and so on. > It may be something to put on the list of things to make sure > an implementation does not mess up. > Side note: Known keyboard sniffing possibilities: > - Chip in your PC (cheap) > - Chip in your keyboard (cheap) > - Patched BIOS (very expensive as it would need to patch the system) > - Sound recording of your keyboard while you type (moderately expensive) > - Camera pointing at keyboard (moderately expensive) > - Electromagnetic emanations (moderately expensive) > > I am sure there are a few others as well. Of course,.. but there's nothing we can do at the disk-encryption-level agains all these.. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
