Re: Re: ecryptfs headsup

[Tyler Hicks <tyhicks () canonical com>]

On 2012-07-11 17:27:41, Kurt Seifried wrote:
> On 07/11/2012 10:48 AM, Kurt Seifried wrote:
> > > 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?
>
> Please use CVE-2012-3409 for the ecryptfs mount.ecryptfs_private which
> allows setuid and dev enabled filesystems, this affects multiple Linux
> vendors.
>
> Just to confirm: this only affects systems with a setuid
> mount.ecryptfs_private?

There are two separate issues here. The first is with the attack vector
described above.

An attacker could trivially craft a lower encrypted filesystem on a USB
drive. It would be automatically mounted in most distros these
days and the mount flags would most likely contain MS_NOSUID. However,
setuid and setgid bits in the USB drive's filesystem would still be
honored if a setuid-root mount.ecryptfs_private was available on the
system because it was not forcing the MS_NOSUID mount flag on the mounts
that it set up.

If we distill that down a little more, it means that it is possible to
mount eCryptfs, *without* MS_NOSUID, on top of a filesystem that is
mounted with MS_NOSUID and eCryptfs will happily honor the setuid and
setgid bits at its layer. I tend to lean towards that being a
non-security, but serious, filesystem stacking bug but I could be
convinced otherwise. It would definitely be an administrator error, but
I don't know what behavior an admin should expect in this situation. Any
thoughts?

Tyler

Attachment: signature.asc
Description: Digital signature