Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ