Multiple vulnerabilities were found in abrt allowing privilege escalation. ============================== 1. Insecure temporary directory and symlink usage in sosreport A vulnerability allowing to elevate privileges from an unprivileged user to root on a default installation of RHEL 7/7.1 was reported. When a process receives SIGSEGV, abrt will save diagnostic information in /var/tmp/abrt/ccpp-*$pid on RHEL 7. Unless /etc/abrt/abrt.conf contains the line "PrivateReports = yes", directories created here by abrt will be chown()'d to the user who owned the crashing process. After saving some initial information it will call post-create scripts, one of the default ones on RHEL is /usr/sbin/sosreport. /usr/sbin/sosreport will be invoked as root and work with a temporary directory named /var/tmp/abrt/ccpp-*$pid/sosreport-$hostname-$date. It will save a number of files collected from the system in this directory and then archive it. Since the directory is owned by root we cannot modify files inside it while sosreport is running, but we do own the parent directory and can simply rename the temporary directory and make a new one. /usr/sbin/sosreport will then write files into our crafted temp directory and will follow any symlinks we make inside. By also renaming some of the temporary files that sosreport works with we can exploit sosreport to write a file with crafted data at an arbitrary location as root. ============================== 2. Insecure temporary directory usage in abrt-action-install-debuginfo-to-abrt-cache A vulnerability was reported allowing to create symlinks and files at arbitrary locations as the abrt user. abrt-action-install-debuginfo-to-abrt-cache is a wrapper for abrt-action-install-debuginfo with the setuid bit for userid abrt. By default it creates a temporary directory in /var/tmp/abrt-tmp-debuginfo-RANDOM_SUFFIX and downloads debug rpm files to this location before extracting them to /var/cache/abrt-di. The random suffix is not quite random but in fact highly predictable, and we can create this directory before executing the suid wrapper. By controlling the "unpacked.cpio" file we can trick abrt-action-install-debuginfo into extracting a cpio file that we control. By extracting two carefully created cpio archives we can leverage this to create files or symlinks anywhere on the file system as the abrt user. This only works on non-redhat systems such as CentOS 7 or RHEL installations that do not use the official RHN yum repositories. ============================== 3. Insecure symlink handling in abrt-hook-ccpp A vulnerability allowing to elevate privileges from the abrt user to root was reported. If a program starting with the name "abrt" crashes, abrt-hook-ccpp will write the coredump to /var/tmp/abrt/$filename-coredump or /var/spool/abrt/$filename-coredump. From abrt-hook-ccpp.c: if (last_slash && strncmp(++last_slash, "abrt", 4) == 0) { /* If abrtd/abrt-foo crashes, we don't want to create a _directory_, * since that can make new copy of abrtd to process it, * and maybe crash again... * Unlike dirs, mere files are ignored by abrtd. */ if (snprintf(path, sizeof(path), "%s/%s-coredump", g_settings_dump_location, last_slash) >= sizeof(path)) error_msg_and_die("Error saving '%s': truncated long file path", path); int abrt_core_fd = xopen3(path, O_WRONLY | O_CREAT | O_TRUNC, 0600); The call to xopen3() does not include the flag O_NOFOLLOW and is therefore vulnerable to a symlink attack. This vulnerability is not exploitable on RHEL installations with default configuration. It can be exploitable if the system is configured to use non-RHN yum repositories. This is because yum is normally not usable by non-root users if the only configured repositories are RHN.
*** Bug 1262292 has been marked as a duplicate of this bug. ***
*** Bug 1262296 has been marked as a duplicate of this bug. ***
Acknowledgements: Red Hat would like to thank Philip Pettersson of Samsung for reporting this issue.
Three abrt related issues are discussed in this flaw. More details about each of these issues are already noted in comment #0. Here is some additional analysis: 1. Insecure temporary directory and symlink usage in sosreport: ABRT ships with "PrivateReports = yes" in RHEL-7.1 and the configuration file contains the following comment: # Disable this option if you want to allow regular users to have file system # rights to read the problem data stored in DumpLocation. # # Caution: # THE PROBLEM DATA CONTAINS EXCERPTS OF /var/log/messages, dmesg AND sosreport # data GENERATED BY abrtd UNDER THE USER root. ABRT discourages the administrators from removing "PrivateReports=yes". Note: if you remove the line from the configuration, ABRT considers the option enabled, so you have to add "PrivateReports=no" to the configuration file. The above warning is already enabled in the versions of abrt shipped with Red Hat Enterprise Linux 7.2. Because of the above, we do not consider this issue as a security flaw. Note: The "PrivateReports" option was considered as a part of the fix for CVE-2015-1870 (https://bugzilla.redhat.com/show_bug.cgi?id=1212868#c3) and CVE-2015-1869. This fix was not backported to Fedora and therefore Fedora 21 and Fedora 22 are affected by this issue. 2. Insecure temporary directory usage in abrt-action-install-debuginfo-to-abrt-cache: An attacker would have to convince the administrator to install attacker's package and the package has to be signed with the imported RPM GPG key, otherwise ABRT would remove the crash data immediately after its creation. So, in order to exploit this issue, a specially-crafted debuginfo file needs to be installed on a system, this is unlikely to happen for a system, subscribed to Red Hat Network, unless the attacker can pull-off a successful MITM attack. This issue has been assigned CVE-2015-5273 3. abrt: incorrect permissions on /var/spool/abrt This issue may allow privesc from abrt to root user. This issue is being tracked as CVE-2015-5287 (bug #1266837)
(In reply to Huzaifa S. Sidhpurwala from comment #10) > > 1. Insecure temporary directory and symlink usage in sosreport: > > Note: The "PrivateReports" option was considered as a part of the fix for > CVE-2015-1870 (https://bugzilla.redhat.com/show_bug.cgi?id=1212868#c3) and > CVE-2015-1869. This fix was not backported to Fedora and therefore Fedora 21 > and Fedora 22 are affected by this issue. Fedora 2[1234] does not need the PrivateReports option because ABRT hooks create problem directories owned by root:abrt with mode 750 by default and users are allowed to take ownership of directories latter on (when the post-mortem analysis is finished) by calling ABRT D-Bus method "ChownProblemDir". Users are allowed to take ownership of abrt problem drirectories because the directories do not contain security sensitive data (the default configuration of abrt does not store such data in the problem directories) and abrtd (and other abrt processes running as root) refuse to read/write/touch directories that are not owned by root:abrt with mode 750. RHEL users are not allowed to take ownership of the abrt problem directories because the directories contains sosreport.
(In reply to Huzaifa S. Sidhpurwala from comment #10) > > 2. Insecure temporary directory usage in > abrt-action-install-debuginfo-to-abrt-cache: > An attacker would have to convince the administrator to install attacker's > package and the package has to be signed with the imported RPM GPG key, > otherwise ABRT would remove the crash data immediately after its creation. > > So, in order to exploit this issue, a specially-crafted debuginfo file needs > to be installed on a system, this is unlikely to happen for a system, > subscribed to Red Hat Network, unless the attacker can pull-off a successful > MITM attack. > > This issue has been assigned CVE-2015-5273 > I am terribly sorry! The analysis of the (2) issue is not accurate because I forgot about the possibility to run the suid wrapper with arbitrary command line arguments, thus the attacker does not need to generate a valid abrt directory stored in /var/spool/abrt. Hence there is no need to install any additional package to be able to exploit this issue. By passing BUILD_ID to the suid wrapper, the attacker can force the suid wrapper to download & unpack any rpm package that is available in one of the configured repositories and that provides the file /usr/lib/debug/.build-id/${BUILD_ID:0:2}/${BUILD_ID:2}.
Created attachment 1087873 [details] Amended patch replacing functions accepting path with functions accepting file descriptor
Created attachment 1087874 [details] Test case: abrt-hook-ccpp not saving core files in /var/spool/abrt
Created attachment 1087876 [details] Test case: abrt-action-install-debuginfo-to-abrt-cache using secure temporary directory
Created attachment 1087877 [details] Test case: correctness of file system attributes of the /var/spool/abrt directory
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:2505 https://rhn.redhat.com/errata/RHSA-2015-2505.html
Created abrt tracking bugs for this issue: Affects: fedora-all [bug 1284557]
abrt-2.7.1-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
abrt-2.6.1-8.fc22, libreport-2.6.4-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-de4d7b3b1f
abrt-2.6.1-8.fc22, libreport-2.6.4-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.