Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Jul 2012 16:48:26 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
CC: Marcus Meissner <meissner@...e.de>, 
 Kurt Seifried <kseifried@...hat.com>
Subject: Re: ecryptfs headsup

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.

-Dan

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