oss-sec mailing list archives
Re: Re: ecryptfs headsup
From: Dustin Kirkland <dustin.kirkland () gazzang com>
Date: Fri, 13 Jul 2012 15:13:44 -0500
On Wed, Jul 11, 2012 at 8:16 PM, Tyler Hicks <tyhicks () canonical com> wrote:
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?
Yeah, the other thing I'd add is that in order to perform this attack (create a filesystem on a USB drive, have physical access to the system, plug in the USB drive), the attacking user could just as easily drop their favorite LiveISO on that same USB drive, reboot the system, and mount the hard drive with root access. I do see the difference, in that the current issue allows for a live attack against a running system, as opposed to an offline attack against a system at rest. In any case, I have tested the fixes and just released ecryptfs-utils-99 which contains the no-set-uid fixes from Sebastian Krahmer and Tyler Hicks (thanks!). We'll be following that release with another one shortly, that fixes a regression (race condition in a bit of a corner-case, when using pam_ecryptfs and encrypted file names on a system where ecryptfs is built as a kernel module). Cheers, -- :-Dustin Dustin Kirkland Chief Architect Gazzang, Inc. www.gazzang.com
Current thread:
- Re: ecryptfs headsup, (continued)
- 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)