[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55315C2B.6050207@redhat.com>
Date: Fri, 17 Apr 2015 21:16:59 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Problems in automatic crash analysis frameworks
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.
