Bug 1157689 (CVE-2014-7817) - CVE-2014-7817 glibc: command execution in wordexp() with WRDE_NOCMD specified
Summary: CVE-2014-7817 glibc: command execution in wordexp() with WRDE_NOCMD specified
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2014-7817
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20141120,repor...
Depends On: 1153288 1167569 1170118 1170121 1170487 1171296
Blocks: 1157695
TreeView+ depends on / blocked
 
Reported: 2014-10-27 13:54 UTC by Vasyl Kaigorodov
Modified: 2019-06-08 20:15 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It was found that the wordexp() function would perform command substitution even when the WRDE_NOCMD flag was specified. An attacker able to provide specially crafted input to an application using the wordexp() function, and not sanitizing the input correctly, could potentially use this flaw to execute arbitrary commands with the credentials of the user running that application.
Clone Of:
Environment:
Last Closed: 2015-07-10 02:55:57 UTC


Attachments (Terms of Use)
CVE-2014-7817-wordexp.diff (5.91 KB, patch)
2014-10-28 03:22 UTC, Carlos O'Donell
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:2023 normal SHIPPED_LIVE Moderate: glibc security and bug fix update 2014-12-19 01:31:32 UTC
Red Hat Product Errata RHSA-2015:0016 normal SHIPPED_LIVE Moderate: glibc security and bug fix update 2015-01-07 22:17:41 UTC

Description Vasyl Kaigorodov 2014-10-27 13:54:49 UTC
Tim Waugh from Red Hat has reported the below issue:

The wordexp() function will perform command substitution even when explicitly told not to, when expanding "$((`...`))".
...
#include <wordexp.h>
int main (void)
{
  wordexp_t we;
  return wordexp ("$((1`touch /tmp/x`))", &we, WRDE_NOCMD);
}

glibc-2.20-5.fc21.x86_64
...

This can allow a local authenticated attacker to execute arbitrary commands with the credentials of a process calling wordexp() on an attacker-supplied data.

Comment 1 Carlos O'Donell 2014-10-27 15:53:58 UTC
I can confirm this on glibc master. This is a bug in wordep in glibc. The bug is in the function parse_arth (and technicall parse_backtick and parse_comm should be hardened), it fails to check for WRDE_NOCMD when processing backticks. The expectation in the code was that higher levels would check for WRDE_NOCMD, and they do, but parse_arith does not, and that's sufficient to show the flaw in the design. Each of the parse_* functions that handles part of the input should be defensive and return errors if any unchecked expansions might pass them code which should be executed on the shell, particularly if you're about to call exec_comm.

The attached patch fixes the issue in parse_arith, parse_backtick and parse_comm. The parse_backtick and parse_comm are the *only* two functions that call the shell for expansion and in each of them we now check for WRDE_NOCMD. That should harden the entire interface against accidental execution of commands like "$((1`echo +1`))".

Could someone please look into which RHEL versions have tha vulnerability?

It looks like:
- Upstream (no OS).
- Fedora Rawhide
- Fedora F21
- Fedora 20

Are all impacted by this.

Comment 2 Carlos O'Donell 2014-10-27 16:03:11 UTC
Testing final patch for this with test case...

Comment 3 Carlos O'Donell 2014-10-28 03:22:28 UTC
Created attachment 951233 [details]
CVE-2014-7817-wordexp.diff

Patch attached.

CVE-2014-7817:

The function wordexp() fails to properly handle the WRDE_NOCMD
flag when processing arithmetic inputs in the form of "$((... ``))"
where "..." can be anything valid. The backticks in the arithmetic
epxression are evaluated by in a shell even if WRDE_NOCMD forbade
command substitution. This allows an attacker to attempt to pass
dangerous commands via constructs of the above form, and bypass
the WRDE_NOCMD flag. This patch fixes this by checking for WRDE_NOCMD
in parse_arith(). The patch also hardens parse_backticks() and
parse_comm() to check for WRDE_NOCMD flag and return an error instead
of ever running a shell.

We expand the testsuite and add 3 new regression tests of roughtly
the same form but with a couple of nested levels.

On top of the 3 new tests we add fork validation to the WRDE_NOCMD
testing. If any forks are detected during the execution of a wordexp()
call with WRDE_NOCMD, the test is marked as failed. This is slightly
heuristic since vfork might be used, but it provides a higher level
of assurance that no shells were executed as part of command substitution
with WRDE_NOCMD in effect. In addition it doesn't require libpthread or
libdl, instead we use the public implementation namespace function
__register_atfork (already part of the public ABI for libpthread).

Tested on x86_64 with no regressions.

2014-10-27  Carlos O'Donell  <carlos@redhat.com>

        * wordexp-test.c (__dso_handle): Add prototype.
        (__register_atfork): Likewise.
        (__app_register_atfork): New function.
        (registered_forks): New global.
        (register_fork): New function.
        (test_case): Add 3 new tests for WRDE_CMDSUB.
        (main): Call __app_register_atfork.
        (testit): If WRDE_NOCMD set registered_forks to zero, run test, and
        if fork count is non-zero fail the test.
        * posix/wordexp.c (parse_arith): Return WRDE_NOCMD if WRDE_NOCMD flag
        is set and parsing '`'.
        (parse_comm): Return WRDE_NOCMD if WRDE_NOCMD flag is set.
        (parse_backtick): Return WRDE_NOCMD if WRDE_NOCMD flag is set and
        parsing '`'.

Comment 4 Carlos O'Donell 2014-10-28 03:31:02 UTC
Next steps?

Comment 5 Carlos O'Donell 2014-10-28 15:00:56 UTC
How serious do we think this CVE is?

How likely is it to impact users?

I don't have a good grasp on this.

My testing shows that:

- glibc usptream (Vulnerable)
- Fedora 21 (Vulnerable)
- Fedora 20 (Vulnerable)
- Fedora 19 (Vuldnerable)
- RHEL 5 (Vulnerable)
- RHEL 6 (VUlnerable)
- RHEL 7 (Vulnerable)

The bug appears to have been present since the initial rewrite in 1997.

To exploit the bug you need:
(a) Access to the system, either local or remote.
(b) An application with higher privs that will run your input directly without checking for shell backticks or subshells, which is feasible given the expectation of WRDE_NOCMD

What is the probabiliy of this?

How much do we need to patch?

Comment 6 Carlos O'Donell 2014-10-29 18:40:26 UTC
I got the go ahead from secalert@redhat.com (Vincent Danen) to contact upstream maintainers privately.

Upstream glibc maintainers contacted privately about the CVE. If they agree to the embargo I will share the details and the fix. This should provide us with useful feedback about the perceived severity.

Comment 7 Vasyl Kaigorodov 2014-11-07 16:46:47 UTC
After an internal discussion Red Hat Product Security did assess this as having Moderate impact on the products we ship.
I will prepare this flaw for further processing on Monday.

Comment 8 Carlos O'Donell 2014-11-07 18:22:11 UTC
Upstream glibc maintainers have reviewed CVE in private.

We see only mailx as alredy vulnerable to wordexp attack, but it does not use WRDE_NOCMD and therefore can't be fixed by this CVE fix.

In addition to mailx the alsa-lib package uses wordexp with WRDE_NOCMD to parse configuration files. It is the only package to date that has been identified as posing a possible threat. It would require though that a non-root user convince root to install a special .asoundrc or convince root to modify the default configuration to include malicious shell code. If the user could already do either of those things they wouldn't need the exploit.

My opinion is that this is a moderate to low severity CVE.

Comment 9 Francisco Alonso 2014-11-20 09:18:34 UTC
This issue is public now:

https://sourceware.org/ml/libc-alpha/2014-11/msg00519.html

Comment 10 Vasyl Kaigorodov 2014-11-21 09:22:28 UTC
Acknowledgement:

This issue was discovered by Tim Waugh of the Red Hat Developer Experience Team.

Comment 11 Huzaifa S. Sidhpurwala 2014-11-25 05:23:07 UTC
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1167569]

Comment 12 Huzaifa S. Sidhpurwala 2014-11-27 05:25:33 UTC
Statement:

This issue affects the version of glibc package as shipped with Red Hat Enterprise Linux 5, 6 and 7. Red Hat Product Security has rated this issue as having Moderate security impact.

Red Hat Enterprise Linux 5 is now in Extended Life Cycle phase of the support and maintenance life cycle. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata

Comment 18 errata-xmlrpc 2014-12-18 20:31:39 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2014:2023 https://rhn.redhat.com/errata/RHSA-2014-2023.html

Comment 19 errata-xmlrpc 2015-01-07 17:18:14 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2015:0016 https://rhn.redhat.com/errata/RHSA-2015-0016.html

Comment 20 Fedora Update System 2015-03-04 10:25:22 UTC
glibc-2.18-19.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2015-03-04 10:26:56 UTC
glibc-2.20-8.fc21 has been pushed to the Fedora 21 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.