Date: Fri, 17 Apr 2015 14:52:01 -0700 From: Tavis Ormandy <taviso@...gle.com> To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com> Subject: Re: Problems in automatic crash analysis frameworks On Friday, April 17, 2015, 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. > Appreciate the updates Florian. Tavis
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ