oss-sec mailing list archives
Re: Re: ecryptfs headsup
From: Tyler Hicks <tyhicks () canonical com>
Date: Wed, 11 Jul 2012 18:16:05 -0700
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
Current thread:
- Re: ecryptfs headsup, (continued)
- Re: ecryptfs headsup Kurt Seifried (Jul 10)
- Re: ecryptfs headsup Sebastian Krahmer (Jul 10)
- Re: ecryptfs headsup Marcus Meissner (Jul 10)
- Re: ecryptfs headsup Dan Rosenberg (Jul 10)
- Re: ecryptfs headsup Tyler Hicks (Jul 10)
- Re: ecryptfs headsup Tyler Hicks (Jul 10)
- Re: ecryptfs headsup Dustin Kirkland (Jul 11)
- Re: ecryptfs headsup Kurt Seifried (Jul 11)
- Re: Re: ecryptfs headsup Tyler Hicks (Jul 11)
- Re: Re: ecryptfs headsup Kurt Seifried (Jul 11)
- Re: Re: ecryptfs headsup Tyler Hicks (Jul 11)
- Re: Re: ecryptfs headsup Dustin Kirkland (Jul 13)
- Re: Re: ecryptfs headsup Jason A. Donenfeld (Jul 13)
- Re: Re: ecryptfs headsup Jason A. Donenfeld (Jul 14)
- Re: Re: ecryptfs headsup Sebastian Krahmer (Jul 16)
- Re: Re: ecryptfs headsup Justin Ossevoort (Jul 16)
- Re: ecryptfs headsup Sebastian Krahmer (Jul 10)
- Re: ecryptfs headsup Kurt Seifried (Jul 10)