oss-sec mailing list archives

Re: Re: Problems in automatic crash analysis frameworks


From: Tavis Ormandy <taviso () google com>
Date: Wed, 15 Apr 2015 20:05:30 -0700

On Wed, Apr 15, 2015 at 12:55 PM, Tavis Ormandy <taviso () google com> wrote:
On Wed, Apr 15, 2015 at 11:48 AM, Tavis Ormandy <taviso () google 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.


Current thread: