Re: CVE Request: ro bind mount bypass using user namespaces

[Kenton Varda <kenton () sandstorm io>]

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 () mitre 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 () sandstorm 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-----