The 2.6.28 Linux kernel used by each of the Ubuntu Jaunty Alphas (1-6) included a bug that may have written arbitrary kernel memory into your eCryptfs file headers.
Hardy and Intrepid are NOT affected. And the actual encrypted data content in your eCryptfs files is NOT affected.
However, if you run 'strings' on your encrypted data, you may see some cleartext data used as padding in the first 2 pages of the file headers. You can check this with something like:
For more information about the technical details and the fix for this bug, please reference:
The Ubuntu Jaunty Beta kernel includes the fix, which will correctly zero the 2 pages of kernel memory allocated for these file headers and prevent such data leakage on any eCryptfs file writes thereafter.
However, any files encrypted with a previous Jaunty Alpha kernel will need to be re-encrypted with the new kernel. Also in Ubuntu Jaunty Beta, I have included a new utility in ecryptfs-utils-73 to help you clean your files: ecryptfs-rewrite-file.
In that manpage, I give a hint for recursively re-encrypting all files in your eCryptfs mount point. Something along the lines of this:
To run this, I *strongly* recommend logging out of all graphical desktop sessions, and logging in via the tty console (ctrl-alt-f1), or via ssh. This will minimize the number of background processes you have running, and prevent races reading/writing the files in your home directory.
As a point of reference, when I ran this on my home directory, it took my dual-core, 2.4GHz t61p about 15 minutes to re-encrypt 2GB of data (25,000 files). I strongly recommend that you do the same, at your earliest possible convenience.
One final note... If you are the type that prefers to run 25-rounds-of-shred to thwart complex data recovery from magnetic disks, then you might consider backing up your cleartext data, shredding your disk, and reinstalling from scratch. In which case, I'm sorry (on multiple levels).
Do you consider this article interesting? Share it on your network of Twitter contacts, on your Facebook wall or simply press "+1" to suggest this result in searches in Google, Linkedin, Instagram or Pinterest. Spreading content that you find relevant helps this blog to grow. Thank you!
Hardy and Intrepid are NOT affected. And the actual encrypted data content in your eCryptfs files is NOT affected.
However, if you run 'strings' on your encrypted data, you may see some cleartext data used as padding in the first 2 pages of the file headers. You can check this with something like:
$ umount.ecryptfs_private && cd ~/.Private && mount.ecryptfs_private
$ find . -type f | xargs strings | egrep ".{20}"
For more information about the technical details and the fix for this bug, please reference:
- The original bug report (thanks to Florian Streibelt for the report!)
- The upstream git commit
The Ubuntu Jaunty Beta kernel includes the fix, which will correctly zero the 2 pages of kernel memory allocated for these file headers and prevent such data leakage on any eCryptfs file writes thereafter.
However, any files encrypted with a previous Jaunty Alpha kernel will need to be re-encrypted with the new kernel. Also in Ubuntu Jaunty Beta, I have included a new utility in ecryptfs-utils-73 to help you clean your files: ecryptfs-rewrite-file.
In that manpage, I give a hint for recursively re-encrypting all files in your eCryptfs mount point. Something along the lines of this:
$ cd $HOME/Private || cd $HOME
$ find . -xdev -print0 | xargs -r -0 /usr/bin/ecryptfs-rewrite-file
$ ecryptfs-umount-private
$ sync
$ ecryptfs-mount-private
To run this, I *strongly* recommend logging out of all graphical desktop sessions, and logging in via the tty console (ctrl-alt-f1), or via ssh. This will minimize the number of background processes you have running, and prevent races reading/writing the files in your home directory.
As a point of reference, when I ran this on my home directory, it took my dual-core, 2.4GHz t61p about 15 minutes to re-encrypt 2GB of data (25,000 files). I strongly recommend that you do the same, at your earliest possible convenience.
One final note... If you are the type that prefers to run 25-rounds-of-shred to thwart complex data recovery from magnetic disks, then you might consider backing up your cleartext data, shredding your disk, and reinstalling from scratch. In which case, I'm sorry (on multiple levels).
0 comments:
Post a Comment