Bug 1266837 - (CVE-2015-5287) CVE-2015-5287 abrt: incorrect permissions on /var/spool/abrt
CVE-2015-5287 abrt: incorrect permissions on /var/spool/abrt
Status: NEW
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
Depends On: 1266853
Blocks: 1262260
  Show dependency treegraph
 
Reported: 2015-09-28 03:23 EDT by Huzaifa S. Sidhpurwala
Modified: 2016-05-04 18:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It was discovered that the kernel-invoked coredump processor provided by ABRT did not handle symbolic links correctly when writing core dumps of ABRT programs to the ABRT dump directory (/var/spool/abrt). A local attacker with write access to an ABRT problem directory could use this flaw to escalate their privileges.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Huzaifa S. Sidhpurwala 2015-09-28 03:23:08 EDT
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.

Note: This security flaw has been split from bug #1262252.
Comment 2 Huzaifa S. Sidhpurwala 2015-11-20 03:27:13 EST
Acknowledgements:

Red Hat would like to thank Philip Pettersson of Samsung for reporting this issue.
Comment 3 errata-xmlrpc 2015-11-23 09:26:38 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

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