Date: Wed, 13 Aug 2014 00:18:40 -0700 From: Kenton Varda <kenton@...dstorm.io> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com Subject: Re: CVE Request: ro bind mount bypass using user namespaces I'm happy with however you want to assign credit here, but for clarification: I actually observed that all these bits could be modified. My first observation was with nosuid. But, I thought they were just the same issue applied to different bits in the same bitfield. I specifically used the RO bit in my PoC. Looking back, it looks like I didn't explicitly point out which other bits were affected, but Eric quickly re-discovered them, and also discovered from reviewing the code that the other bits had even fewer guards against modification compared to the RO bit. Andrew Lutomirski has further discovered that this problem can be used to escalate a regular user to root privileges on typical Linux configurations, independent of any sandboxing effort. Thanks, -Kenton On Tue, Aug 12, 2014 at 10:49 PM, <cve-assign@...re.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We are assigning two CVE IDs because the available information is that > there were two discoverers. Even if the discoverer information is > later clarified, there will still be these two CVE IDs. > > > > https://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-linus&id=db181ce011e3c033328608299cd6fac06ea50130 > > > > Kenton Varda <kenton@...dstorm.io> discovered that by remounting a > > read-only bind mount read-only in a user namespace the > > MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user > > to the remount a read-only mount read-write. > > Use CVE-2014-5206. > > > > > https://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-linus&id=9566d6742852c527bf5af38af5cbb878dad75705 > > > > While investigating the issue where in "mount --bind -oremount,ro ..." > > would result in later "mount --bind -oremount,rw" succeeding even if > > the mount started off locked I realized that there are several > > additional mount flags that should be locked and are not. > > Use CVE-2014-5207. > > - -- > CVE assignment team, MITRE CVE Numbering Authority > M/S M300 > 202 Burlington Road, Bedford, MA 01730 USA > [ PGP key available through http://cve.mitre.org/cve/request_id.html ] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (SunOS) > > iQEcBAEBAgAGBQJT6vjTAAoJEKllVAevmvmsEI4H+wWrFmadZJwDhgU8i5IfiVIl > Oz/iPTeSCelGIH6BA5GAMbaEmMUf/ay0Jpa31y6MhOiw1KMsGGFvzGkLoy3Pb/T5 > G682hBmQbZD1OnBdk3z2EnMd5i0/B3kzc1rXi4m9QJcmi216xnJnD0+lEVbRj5nf > jruRJplaRiwYuXszZSWhAOBVMFb5MJ/4aNmUkKdpiywQjOWhykgjNNyxXby9Rxpo > AkoLecJPn/IJ4mRmLTp3vo1x/GZUXmXFvKfsJdB5Ps+kOnX7ptMyap4GTjSvXcIc > FSJ9Zfad0iAnflEQTAKEVHFu5vSzbUdWVC+qMapVjZXRnku8y3UzYJVEvqQDUTc= > =Qzne > -----END PGP SIGNATURE----- >
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