Re: ecryptfs headsup

[Tyler Hicks <tyhicks () canonical com>]

On 2012-07-10 15:13:40, Tyler Hicks wrote:
> 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?

Sorry, I forgot to add Dustin to cc. 

Tyler

Attachment: signature.asc
Description: Digital signature