[Ubuntu Chicago] [ChicagoLinux] Ubuntu encrypted Private directories
eddiemartinez at gmail.com
Mon Nov 3 02:45:24 GMT 2008
Yes, the flaw is in the last step... the user password is used as an
Initilization Vector in generating the second passphrase for ~/Private. The
goal for any security system (and i wont claim this is a flaw, or a benefit
in the Ubuntu implementation), is to make the second key impossible to guess
from the first, or vice versa.
In this instance, I believe they are using KDF to make a secondary key based
upon the IV of the first MD5 key.
Also, there are ways to gain access to a computer (openssh server, ftp,
etc.) that can be used to compromise a computer. In my response to Jim on
the Chicago-Ubuntu list, I make that point that if someone does this:
find openssh-server on an ubuntu machine
connect ssh user at whatever.com
type in the password: letmein
sudo -i: letmein
(here you set a new password)
In doing so, you would be changing the md5sum in which would actually take
the attacker farther away from deriving the ~/Private passphrase than they
were when they first connected to my machine, if I am understanding the
implimentation correctly (and i could be wrong).
Also, using a seperate /home, /var, /log, etc, would not useful in this
instance, as it would require connecting to a partition already mounted,
decrypted and running the ssh daemon.
On Sun, Nov 2, 2008 at 8:32 PM, Christopher Allan Webber <
cwebber at dustycloud.org> wrote:
> The real question isn't whether or not the machine is rooted, IMO, it's
> how hard it is to get the password from running /etc/shadow against a
> rainbow table.
> And, I haven't done it before, but I understand that's pretty trivial.
> At that point, you don't just "get access to the machine so you can
> change the password", you get the *actual password*. So if you can get
> access to /etc/shadow, and can run the md5 hash against the rainbow
> table, and indeed that gives you the user's *password*, then it would be
> my understanding that if this is the *same* password used to encrypt the
> private directory, then whammo, you have access to the private
> Now of course, I don't have a whole ton of experience in security
> workflows, but it seems to me like the way to break this system is:
> - Get *physical access* to the system (ie, steal someone's laptop)
> - Put in a boot disk to get access to the drive, and thus get access to
> - Take the user's md5 hash, run it against the rainbow table
> - Get the user's password
> - Use the user's password to unlock the encrypted directory
> And voila! You have access to the encrypted directory. And since the
> only protection that encryption really gives is against someone stealing
> data by getting local access to your machine, you might as well leave it
> unencrypted anyway (or better, don't use the user's password & PAM for
> the passphrase on the key, and have real encryption).
> I could be missing something though. Thoughts?
> "Eddie Martinez" <eddiemartinez at gmail.com> writes:
> > I'm not expert but it sounds to me like it would be easier to crack the
> > hashed login password/passphrase than it would be to attack the ~/private
> > dir... The benefit comes from having a machine rooted and still having
> > private directory to be called 'secure' because those two would be
> > independent, as you mentioned. The section about, "The pam_ecryptfs
> > captures the user's login password and uses that to unwrap their
> encrypted ~/
> > Private mount passphrase" indicates that libpam/pam are used by the
> > pam_ecryptfs module as part of the KDF function for generating the secret
> > for ~/Private.... This is actually more secure than rooting a machine or
> > editing /etc/shadow because doing so changes the md5 hash of the password
> in /
> > etc/passwd. If someone roots a machine and does 'passwd' and generates a
> > root password, they will be locking themselves out of the secret key
> which was
> > used to encrypt ~/Private in the first place (asssuming no backup).
> > http://en.wikipedia.org/wiki/Key_derivation_function
> > At least this is my understanding, but I would still suggest SHA-512
> > of md5 for PAM, as well as grub passwd, seperate /home, /swap, /var,
> > encrypted using something like AES 256, non standard passphrases/user
> > the whole nine yards.
> > What I do find strange in the implementation of this, from the guides
> > I've seen is the need to do a syslink to tell ~/private where the actual
> > are located, as well as their handling of .ssh, but if anyone can talk
> > this, I'd be more than interested to hear about it on the list.
> > On Sun, Nov 2, 2008 at 5:56 PM, Jim Campbell <jwcampbell at gmail.com>
> > Hi All,
> > At yesterday's ChiGLUG meeting a couple of us finished up the Ubuntu
> > discussion by talking about the encrypted Private directories feature
> > is new to Ubuntu in version 8.10. Someone had brought up whether the
> > setup of the encrypted directories use PAM to mount the encrypted
> > and I wasn't fully sure.
> > I did some checking today, and found some info that I thought I'd
> > https://wiki.ubuntu.com/EncryptedPrivateDirectory
> > https://help.ubuntu.com/community/EncryptedPrivateDirectory
> > From one of the pages, "The pam_ecryptfs module captures the user's
> > password and uses that to unwrap their encrypted ~/Private mount
> > passphrase. It also executes mount.ecryptfs_private on login, and
> > umount.ecryptfs_private on logout." Without knowing too much about
> it, it
> > seems to me that the pam_ecryptfs module would be different than the
> > standard pam or libpam module, but I'm not a 1337 hax0r or anything.
> > also know we've got some security experts in ChiGlug and
> > so I thought I'd just bring these up as a point of discussion.
> > I guess, to me, it seems like you're still toast if someone knows
> > username and password (as per usual), but it prevents someone who
> > root access from being able to easily get at the data in the
> > directory. Seems like they could still hack on shadow passwords
> > if they got access, and the setup isn't as strong as encrypting an
> > /home and /swap partition, but this just makes things one step more
> > difficult. Any other thoughts on this?
> > Jim
> > --
> > Ubuntu-us-chicago mailing list
> > Ubuntu-us-chicago at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-us-chicago
> > _______________________________________________
> > ChicagoLinux-Discuss mailing list
> > ChicagoLinux-Discuss at chicagolug.org
> > https://www.chicagolug.org/lists/listinfo/chicagolinux-discuss
> ChicagoLinux-Discuss mailing list
> ChicagoLinux-Discuss at chicagolug.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-us-chicago