Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Apr 2015 14:52:01 -0700
From: Tavis Ormandy <>
To: "" <>
Subject: Re: Problems in automatic crash analysis frameworks

On Friday, April 17, 2015, Florian Weimer <> wrote:
> A quick update on the abrt situation.
> Most of these issues center around file ownership and contents under
> so-called problem directories (subdirectories of /var/tmp/abrt or
> /var/spool/abrt).  Problem directories are owned by root and have mode
> 750 on Red Hat Enterprise Linux 6, which suggest that with this older
> abrt version, exploits are only possible if uploads are enabled in some
> way (see below).
> abrt writes coredumps to existing world-writable files owned by other
> users, disclosing coredump contents across user boundaries.  This
> affects a default configuration, but requires an application to crash
> while its current directory is world-writable, so exploiting it seems
> difficult.  We have assigned CVE-2015-3142.
> <>
> By default, abrt automatically runs post-crash actions on problem
> directories (event handling scripts).  These scripts have symlink issues
> and other race conditions.  This is more or less a repeat of the main
> abrt-hook-ccpp issue Tavis' reported, but at a higher level.  It means
> that hardening the file system access in abrt-hook-ccpp is insufficient.
>  We have assigned CVE-2015-1869:
> <>
> The default event handling scripts add a sosreport file (containing
> files which are not world-readable) and user-controlled excerpts from
> /var/log/messages to the user-readable problem directory.  This is an
> information disclosure flaw, CVE-2015-1870:
> <>
> abrt has an upload functionality which allows, after non-default but
> documented/supported configuration, other systems to upload crash
> reports.  This indirectly allows one to create a problem directory with
> symbolic links and unintended permissions, enabling further attacks.  We
> treat this as a vulnerability, CVE-2015-3147:
> <>
> As explained in the parallel thread, abrt needs to disable user coredump
> files in fs.suid_dumpable=2 mode, like the kernel does, and we don't
> treat this as a vulnerability:
> <>
> It makes sense to have separate abrt-hook-ccpp implementation that does
> not write user coredump files.  It would not have to write to arbitrary
> file system locations, so it can be restricted with SELinux.  This
> enhancement is tracked as:
> <>
> There is a backlog of other issues for which I have not yet filed bugs.

Appreciate the updates Florian.


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