Bug 1157689 (CVE-2014-7817)

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.

Testing final patch for this with test case...

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>

        * 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 '`'.

Next steps?

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?

I got the go ahead from secalert (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.

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.

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.

This issue is public now:

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

Acknowledgement:

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

Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1167569]

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

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

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

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.

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.