On Tue, Aug 14, 2001 at 05:28:36PM +0200, Bernhard Rosenkraenzer wrote:
> Workaround:
> - Don't use suspend-to-disk even if it happens to work with your OS, use
> encrypted partitions if supported by the OS
Warning, the encrypted partitions won't automagically solve anything if
you don't unmount them completly and you make sure all cleartext
istances of the secret key are been deleted from memory before starting
the suspend to disk.
Just to make an example the twofish cryptoloop plugin doesn't clear the
cleartext of the secret key during losetup -d:
static int fish2_release(struct loop_device *lo)
{ if (lo->key_data!=NULL)
{
kfree(lo->key_data);
lo->key_data=NULL;
}
return(0);
}
You see, there's no memset(lo->key_data, 0, ..) in the release operation.
So the page will stay in some kernel freelist, waiting somebody else to
allocate and clobber it, but if nobody allocate and clobber the secret
key before the next suspend to disk, the secret key will be dumped to
disk in clear text by the bios.
I didn't even checked if losetup cares to clear the secret key memory
before doing munmap/exit but I guess it's not the case either (but again
since the kernel side doesn't what losetup does is not interesting).
So in short even if you do:
losetup -e twofish /dev/loop0 filename
...
losetup -d /dev/loop0
suspend to disk
the attacker will most certainly be allowed to reconstruct the secret
key from the suspend-partition and to access all your data. (of course
if the suspend to disk happens with the cryptoloop mounted the attacker
will have the guarantee to be able to decrypt the volume)
So the crypto partitions must be used with extreme care too when used at
the same time of suspend-to-disk, NOTE: this is _not_ a bug in the
cryptoloop, this is just an issue that arise from the usage of the
suspend-to-disk feature of the laptops. However certainly I'd agree it
would be nice to add the feature to the linux software so that after a
losetup -d /dev/loop0 we get to a state where it's safe to 'suspend to
disk'. (on the kernel side a one liner in the above function should be
enough, the userspace side of losetup is probably more than one line if
it's not just clearing it)
btw, I don't care much about the bios-floppy case, that will probably
never be abused in real life (and I would never left the "boot from
floppy" the default, if something "boot from cdrom" :), I instead mostly
care about the "stolen laptop in suspend mode" case, which can more
probably happen in real life and where all the same security
considerations about the cryptoloop vs suspend-to-disk applies too.
In short to be secure you should never suspend to disk after the first
losetup -e. Also make sure to cleanup the suspend partition properly if
you happen to suspend to disk after a losetup -e. (I wouldn't trust a
second suspend-to-disk after a reboot to overwrite the previous data,
suspend-to-disk is lazy and it could save only the unknwon-contents in
memory)
Of course all of this assumes the bios is dumping the ram of the machine
to the suspend-partition without using crypto and without asking to the
user to type (or plugin somehow) a "suspend-to-disk" secret key before
every dump and every restore.
Andrea
This archive was generated by hypermail 2b30 : Tue Aug 14 2001 - 18:43:03 PDT