[<prev] [next>] [day] [month] [year] [list]
Message-ID: <678df6c4-a201-8088-2fc6-737d14905b9d@halfdog.net>
Date: Tue, 19 Jan 2016 20:10:50 +0000
From: halfdog <me@...fdog.net>
To: oss-security@...ts.openwall.com
Subject: Overlayfs and devpts issues in namespaces
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
<Seems that message did not get through, so resending>
Hi,
Solar Designer wrote:
> On Wed, Jan 13, 2016 at 10:26:18PM +0000, halfdog wrote:
>> About the title of the thread: The second topic mentionend in
>> initial mail "Overlayfs and devpts issues in namespaces", was
>> the devpts issue. I combined those two in one thread, because one
>> vulnerability makes discovery of second quite simple - that is
>> why I discovered both nearly at same time. The later one is
>> still undisclosed. From the Ubuntu bug report notifications I
>> know, that they are at least trying to get rid of the
>> problematic pt_chown SUID binary, but there seem to be other
>> devpts issues they know about.
>
> Since you brought the devpts issue in here on January 4, you must
> post about it to oss-security no later than on January 18
> (Monday), or you may choose to do it today (Thursday). (Friday and
> the weekend are worse.)
The writeup is ready since weeks, the first one is out already. The
user namespaces topic proved more problematic than initially thought:
two more local root privilege escalation variants were found,
overlayfs is vulnerable since enabled (e.g. Ubuntu Trusty up to now).
This was the first time, I tried to cooperate with others for fixing
via Linux distros instead only via Ubuntu and upstream, but even with
patch available, this did not speed up the process from discovery to
patching. So embargo time has ended but no patch available yet.
With that in mind, what would be best next steps for all those known
and also future issues?
As I know about the problems with uncoordinated full disclosure, but
bearing in mind, that full disclosure is also a method of enabling
those wanting to protect themselves, I am inclined to try this procedure:
* Send a pre-announce about 3 more userns related issues allowing
local root gain, thus proofing needs to audit the code more closely.
* Request developers to provide a mitigation workaround as kernel
module, that, as long as loaded a) disables userns as such or variant
b) just disables mounting within userns when not being host-uid-0.
Such a module should mitigate worst effects for production
environments but may leave other platforms (embedded? phones?)
unprotected.
* Module should be very simple to develop and perhaps distribute as
e.g. Ubuntu PPA addon-package to current kernel. So give whole public
2 days time for mitigation module.
* No matter if module is available or not (if not, that means that the
issues is irrelevant from security perspective). Hence full disclosure
cannot do any further harm.
Opinions?
hd
PS: As the number of issues currently in processing are way too large
for sparetime handling, coordination is getting worse. So quite
likely, different parties might be out of sync already.
- --
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlaemC8ACgkQxFmThv7tq+411wCgjLx73cl3pKj/mvhIJC0EcrYb
8AAAni5TlXemvoPf/xei0tYHpjNhJA6q
=klHo
-----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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
