Date: Tue, 10 Jul 2012 15:13:41 -0700 From: Tyler Hicks <tyhicks@...onical.com> To: oss-security@...ts.openwall.com Cc: Marcus Meissner <meissner@...e.de>, Kurt Seifried <kseifried@...hat.com>, Dan Rosenberg <dan.j.rosenberg@...il.com> Subject: Re: ecryptfs headsup On 2012-07-10 16:48:26, Dan Rosenberg wrote: > On 07/10/2012 10:30 AM, Marcus Meissner wrote: > > On Tue, Jul 10, 2012 at 04:21:13PM +0200, Sebastian Krahmer wrote: > >> > >> It is a potential privilege escalation since the pam module > >> was not setting uid/gid(list) appropriately and the suid > >> binary did not clear environment before exec'ing umount. > >> I do not know whether MS_NOSUID was really needed (and maybe > >> MS_NODEV is, but I was not able to create dev files). > >> Unfortunally we found ecryptfs not really stable inside the kernel > >> and Marcus is still rebooting :) > > > > This means ... > > > > So far we have not yet found a specific security issue. > > > > Ciao, Marcus > > > > This reminds me... > > If an unprivileged user can mount ecryptfs shares (e.g. via the setuid-root > mount helper shipped on Ubuntu) and has the ability to mount user-controlled > filesystems (either network filesystems via setuid mount helpers like mount.cifs > or mount.nfs, or formatted USB drives via physical access), it's possible to > escalate privileges to root because the setuid ecryptfs helper does not mount > filesystems with the nosuid or nodev flags. > > An attacker can create an ecryptfs filesystem on his own machine on a network > filesystem or USB drive, and then mount that ecryptfs filesystem on the victim > machine for a setuid-root backdoor. Hard-coding nosuid and nodev into the > setuid ecryptfs helper would resolve this, but I'm not sure that's workable for > Ubuntu home directories. This vulnerability is limited to physical access via formatted USB drives because the eCryptfs filesystem code does not work on top of network filesystems. Additionally, I believe that the encrypted home source and destination mount points were hard-coded up until ecryptfs-utils version 86. Versions before that should not be vulnerable to the setuid-root binary on a USB drive attack mentioned above. Dustin - Would you have any objections to forcing the nosuid and nodev mount options in the mount.ecryptfs_private helper? Tyler [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ