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 15:54:47 -0500
From: Grandma Eubanks <>
Subject: Re: Problems in automatic crash analysis frameworks

Just to enter into the fray, I reported a simple dmesg_restrict bypass and
found a lot of these recent more recent 'information' disclosures a while
ago with minimal changes:

Not a lot of people seem to be looking at this from a triggerable angle
with the unix domain socket. A simple test I've been running with that
allows triggers for a lot of these is:

import socket
from os import strerror

s = socket.socket(socket.AF_UNIX,socket.SOCK_STREAM)
conn = s.connect_ex("/var/run/abrt/abrt.socket")
if (conn != 0):
    print("ERROR:\t%s" % strerror(conn))
    conn = s.connect_ex("/var/run/abrt/abrt.socket")

print("Connected, sending...")

s.send("POST / HTTP/1.1\r\n\r\n")


By reading some code and looking at the different types of analyzers, most
of these very recent CVE's easily triggerable without actually needing to
cause a real crash (just change executable= to any validly installed
package without 'ProcessUnpackaged' set and some other required fields as
found by reading through the proper event handler code). And plus, with a
little dbus play:

def kill_user_notification():
    # get current notification counter value
    bus = dbus.SessionBus()
    bus_object =
        object_method =
        id_value = ((object_method("",0,"","","","","",1)))

    # kill notification and abrt notification
    bus = dbus.SessionBus()
    bus_object =
    object_method =

You no longer trigger notification windows.

On Fri, Apr 17, 2015 at 2:16 PM, 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.
> --
> 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