Re: Problems in automatic crash analysis frameworks

[Tavis Ormandy <taviso () google com>]

On Wed, Apr 15, 2015 at 8:23 AM, Florian Weimer <fweimer () redhat com> wrote:
> On 04/14/2015 03:30 PM, Tavis Ormandy wrote:
>
> > This code trusts the /proc/pid/exe symlink, even though it is possible
> > to link it anywhere you want.
> >
> > https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c#L368
> >
> >         sprintf(buf, "/proc/%lu/exe", (long)pid);
> >         int src_fd_binary = open(buf, O_RDONLY); /* might fail and
> > return -1, it's ok */
>
> Does opening /proc/PID/exe really perform symlink resolution?  Or does
> the kernel create temporary /proc/PID entries for non-executable file?
>
> This feature is supposedly disabled by default.  As far as I can see, it
> can disclose the program text of execute-only binaries to users, which
> has been treated as a vulnerability in the past.

Ack, I knew /proc/pid/exe was magic, but for some reason I thought
when it was marked deleted symlink resolution did work.

I tested it and I think you're correct, it's just the execute-only disclosure.

> Upstream has posted patches for some of the vulnerabilities:
>
>   <https://github.com/abrt/abrt/pull/950>
>   <https://github.com/abrt/libreport/pull/343>
>
> There's still some debate how to best address the creation of the
> user-owned directory.  My proposal is to change from root:root to
> user:abrt as late as possible.
>
> (The Hotspot crash dump copying is disabled in the sources, so no patch
> for that is planned right now.)
>
> We also need to move off the /var/tmp/abrt directory (the code for
> creating the directory looks racy), back to /var/spool/abrt.
>
> I have not looked at how directory creation is handled for the other
> crash handlers (say Python).
>
> --
> Florian Weimer / Red Hat Product Security