Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Apr 2015 17:23:59 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Problems in automatic crash analysis frameworks

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?
But how would this trigger the

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.


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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ