Date: Wed, 15 Apr 2015 20:05:30 -0700 From: Tavis Ormandy <taviso@...gle.com> To: Tyler Hicks <tyhicks@...onical.com> Cc: oss-security@...ts.openwall.com, Assign a CVE Identifier <cve-assign@...re.org>, security <security@...ntu.com>, Stéphane Graber <stgraber@...ntu.com> Subject: Re: Re: Problems in automatic crash analysis frameworks On Wed, Apr 15, 2015 at 12:55 PM, Tavis Ormandy <taviso@...gle.com> wrote: > On Wed, Apr 15, 2015 at 11:48 AM, Tavis Ormandy <taviso@...gle.com> wrote: >> FWIW, I verified this is exploitable. >> > > Here's the script I used to verify, it should create the file > /etc/rootfiletest. By using the partial trick or creating parse > errors, this is easy to turn into a root shell. It looks like there's a new patch here: https://launchpadlibrarian.net/203416094/apport.diff In get_parentns_pid code, it looks like it has the same problem as before in that there's no guarantee ppid isn't recycled (possibly by root). Also, you can easily get an untrusted process reparented to init. If you're not convinced of this, try this: $ bash -c 'sleep 600 & echo $!; disown -ah' 28396 $ egrep '(PPid|Name):' /proc/28396/status Name: sleep PPid: 1 I'm almost certain it's not possible for the core_patten handler to perform any meaningful analysis on the parent process. This code is definitely not sufficient: os.chdir("/proc/%s/" % ppid) ... with open("status", "r") as fd: .... if line.startswith("Uid:"): Because you can just wait for ppid to be recycled before the chdir(). The UDS inode validation is a neat idea, but I don't think it works - the obvious case is reparenting to init and then using one of the inode numbers init uses, but even if you special-case init, pid recycling is possible. I saw the duplicate inode checks, but that doesn't work....it's racy, and you can just use a netlink socket or similar. Once you've passed this check, it's a controlled lxc.Container() and you can use my previous PoC to verify that is exploitable. Tavis.
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