Re: ecryptfs headsup

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2012 08:08 AM, Dustin Kirkland wrote:
> 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?

So it sounds like a non privileged user on an Ubuntu machine can
insert a USB stick/etc with a file system that gets automatically
mounted, said file system can contain setuid root binaries for example
which the user can then execute, elevating privileges?

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP/a5wAAoJEBYNRVNeJnmTHT0P/1BCOUexoMZhapvsSpoZZaY7
//5EJljz7NlzfdzLQ52zQ9FxjnTSzZMUCHq6dY2tLQxXUKjkSv+L4llMaRq3lIFe
unl7TPj2qaf/ZHWV6Av+S14z4ChB/CJuSQVuIUBCioKSs6uJjEB7X+GG+wNAcGZ7
H2l5ZDjERRc6v7wLL1OP+NwtSsYj4Pv+j0NJe1rJ7yh76mWwDpBlYCgWMUeJG5kg
FnJWFS10YTLHuKb+rjwQfC4NN0ncPH1zVJo2ZjmvDJHtPbSpxbkDLBpulUDm+Arc
s8eCjfOyArgHY87NlCOsfC9Cgr3TXcw39cyzX8RFyI2fl4Nk8bxj+N73ee7b4fgf
PCmxBkddvEal7GDTQBihkaN1HgyGl36Qt1IlFTlVa71lfn7Lpr854Q+SeEMRxIIu
7bPCRgoxJW/yMWn3dUBf7qQ0Vd6zFFZf1YH4iFxwULgNW2Tk1RTDLA5oUXsPw/Rc
nijnjWpjTS32TxbjE/7nTSlrBo4uPTCZkvjW67b7bSBHQBRhJQG9B6rkbWZlS7rQ
7yBCHiCcokO9yQ1W//6Om+XrGAPTZwCYhU3WiA4poLG0anLwnoSU8ASGaF2ajnMc
Sre4vuBGRyW2ZIFMHUj5fSSlbNgF1Q3DgTooKT6c9gsr+LT8LMfPpNhd9B5PfF3L
wKbOz7Ongn7yLZXpsDDb
=N1iI
-----END PGP SIGNATURE-----