Re: Re: Problems in automatic crash analysis frameworks

[Tavis Ormandy <taviso () google com>]

On Wed, Apr 15, 2015 at 9:05 AM, Tyler Hicks <tyhicks () canonical com> wrote:
> On 2015-04-14 17:16:08, Tyler Hicks wrote:
> > On 2015-04-14 14:10:12, Tavis Ormandy wrote:
> > > On Tue, Apr 14, 2015 at 2:08 PM, Tavis Ormandy <taviso () google com> wrote:
> > > > On Tue, Apr 14, 2015 at 1:35 PM, Tavis Ormandy <taviso () google com> wrote:
> > > > > On Tue, Apr 14, 2015 at 9:02 AM, Marc Deslauriers
> > > > > <marc.deslauriers () canonical com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On 2015-04-14 11:55 AM, cve-assign () mitre org wrote:
> > > > > > > This is mostly a question for the persons who assigned CVE-2015-1318
> > > > > > > and CVE-2015-1862. Should these CVE assignments be interpreted to
> > > > > > > mean:
> > > > > > >
> > > > > > >   CVE-2015-1318 - in Apport, an unprivileged user can use a
> > > > > > >                   namespace-based attack because there is an execve by
> > > > > > >                   root after a chroot into a user-specified directory
> > > > > >
> > > > > > Yes, I assigned CVE-2015-1318 to that specific issue in Apport.
> > > > > >
> > > > > > Marc.
> > > > >
> > > > > It looks like this is the patch for Apport:
> > > > >
> > > > > http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2943#data/apport
> > > > >
> > > > > It's far more complicated than I expected, and not obviously correct.
> > > > > It could probably use some review, I'll think about it today.
> > > > >
> > > > > Tavis.
> > > >
> > > > Wait, my first thought is that it's not obvious to me that
> > > > /proc/net/unix is guaranteed to be newline delimited, newline is a
> > > > perfectly valid name in a filename, no?
> > > >
> > > > > > > import socket
> > > > > > > socket.socket(socket.AF_UNIX, socket.SOCK_STREAM).bind('test\ntest')
> > > > > > > sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
> > > > > > > sock.bind('/tmp/foo\nbar')
> > > > > > > sock.listen(1)
> > > >
> > > > $ grep -A1 foo /proc/net/unix
> > > > 0000000000000000: 00000002 00000000 00010000 0001 01 4772228 /tmp/foo
> > > > bar
> > >
> > > And with complete control over this line, it seems like it's game over.
> > >
> > >                 container = lxc.Container(path[-2], real_path)
> > >
> > > I'm calling this re-broken.
> >
> > I've pointed Stéphane Graber to your analysis (and put him on cc). He's
> > working on a fix.
> >
> > Even though it isn't clear if all of the checks added in revision 2943
> > can be bypassed, it is worth coming up with another approach.
>
> Hi Tavis - We've opened a bug to track the issue that you discovered:
>
>   https://launchpad.net/bugs/1444518
>
> Stéphane has prepared a patch that is more resilient to a malicious
> /proc/net/unix:
>
>   https://launchpadlibrarian.net/203372380/apport.diff
>
> Any feedback that you have would be appreciated. Thanks again!
>
> Tyler

Thanks Tyler, I'll think about this morning. I'm not sure if these
observations are important, but my first thought is It's definitely
possible to make the st_uid of /proc/ppid 0, you could just do su
$USER for example.

Also, you can at least trust /proc/pid is stopped while the core
handler is running, but ppid is still running. I think this matters,
because the pid might be recycled.

Tavis.