oss-sec mailing list archives
Re: ecryptfs headsup
From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 11 Jul 2012 10:48:48 -0600
-----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, MarcusThis 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-----
Current thread:
- ecryptfs headsup Sebastian Krahmer (Jul 10)
- 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)