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 09:04:47 -0700
From: Tavis Ormandy <>
Subject: Re: Problems in automatic crash analysis frameworks

On Wed, Apr 15, 2015 at 8:23 AM, Florian Weimer <> 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.
>>         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:
>   <>
>   <>
> 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