Re: ecryptfs headsup

[Dustin Kirkland <dustin.kirkland () gazzang com>]

On Tue, Jul 10, 2012 at 5:15 PM, Tyler Hicks <tyhicks () canonical com> wrote:
> 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?

Hi Tyler, et al.-

I don't have any objections at all with adding nosuid and nodev to the
hardcoded mount.ecryptfs_private options.

Actually, I seem to recall this coming up recently before.  I can't
find the bug or email thread (must have been IRC), but I recall
offering to commit, test, and release that change immediately.  I
believe I was asked to wait to do that until a CVE had been
published...  I can't find any record of that conversation though, so
that's just from memory.

Shall I go ahead and commit/test/release that now, Tyler?

-- 
:-Dustin

Dustin Kirkland
Chief Architect
Gazzang, Inc.
www.gazzang.com