Bug 1262252 - (CVE-2015-5273) CVE-2015-5273 abrt: Insecure temporary directory usage in abrt-action-install-debuginfo-to-abrt-cache
CVE-2015-5273 abrt: Insecure temporary directory usage in abrt-action-install...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20151123,repor...
: Security
: 1262292 1262296 (view as bug list)
Depends On: 1266853 1284557
Blocks: 1262260 1262302
  Show dependency treegraph
 
Reported: 2015-09-11 05:38 EDT by Adam Mariš
Modified: 2016-05-04 18:49 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It was found that the ABRT debug information installer (abrt-action-install-debuginfo-to-abrt-cache) did not use temporary directories in a secure way. A local attacker could use the flaw to create symbolic links and files at arbitrary locations as the abrt user.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-04 19:21:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Amended patch replacing functions accepting path with functions accepting file descriptor (1.67 KB, patch)
2015-10-30 04:50 EDT, Jakub Filak
no flags Details | Diff
Test case: abrt-hook-ccpp not saving core files in /var/spool/abrt (9.13 KB, patch)
2015-10-30 04:51 EDT, Jakub Filak
no flags Details | Diff
Test case: abrt-action-install-debuginfo-to-abrt-cache using secure temporary directory (3.08 KB, patch)
2015-10-30 04:53 EDT, Jakub Filak
no flags Details | Diff
Test case: correctness of file system attributes of the /var/spool/abrt directory (2.03 KB, patch)
2015-10-30 04:56 EDT, Jakub Filak
no flags Details | Diff

  None (edit)
Description Adam Mariš 2015-09-11 05:38:57 EDT
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.
Comment 2 Adam Mariš 2015-09-14 07:42:55 EDT
*** Bug 1262292 has been marked as a duplicate of this bug. ***
Comment 3 Adam Mariš 2015-09-14 07:43:05 EDT
*** Bug 1262296 has been marked as a duplicate of this bug. ***
Comment 4 Adam Mariš 2015-09-15 12:36:30 EDT
Acknowledgements:

Red Hat would like to thank Philip Pettersson of Samsung for reporting this issue.
Comment 10 Huzaifa S. Sidhpurwala 2015-09-28 03:17:07 EDT
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)
Comment 12 Jakub Filak 2015-09-29 01:59:17 EDT
(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.
Comment 13 Jakub Filak 2015-09-29 02:20:55 EDT
(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}.
Comment 23 Jakub Filak 2015-10-30 04:50 EDT
Created attachment 1087873 [details]
Amended patch replacing functions accepting path with functions accepting file descriptor
Comment 24 Jakub Filak 2015-10-30 04:51 EDT
Created attachment 1087874 [details]
Test case: abrt-hook-ccpp not saving core files in /var/spool/abrt
Comment 25 Jakub Filak 2015-10-30 04:53 EDT
Created attachment 1087876 [details]
Test case: abrt-action-install-debuginfo-to-abrt-cache using secure temporary directory
Comment 26 Jakub Filak 2015-10-30 04:56 EDT
Created attachment 1087877 [details]
Test case: correctness of file system attributes of the /var/spool/abrt directory
Comment 27 errata-xmlrpc 2015-11-23 09:26:33 EST
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
Comment 28 Adam Mariš 2015-11-23 10:07:36 EST
Created abrt tracking bugs for this issue:

Affects: fedora-all [bug 1284557]
Comment 29 Fedora Update System 2015-11-28 15:22:10 EST
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.
Comment 30 Fedora Update System 2016-02-03 18:26:23 EST
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
Comment 31 Fedora Update System 2016-02-04 19:21:13 EST
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.

Note You need to log in before you can comment on or make changes to this bug.