Bug 898884 - (CVE-2014-6278) VUL-0: CVE-2014-6278: bash: more code execution via fd redirection
VUL-0: CVE-2014-6278: bash: more code execution via fd redirection
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Major
: ---
Assigned To: Dr. Werner Fink
Security Team bot
. maint:released:sle11-sp1:59886 CVSS...
Depends on:
  Show dependency treegraph
Reported: 2014-09-28 20:36 UTC by Marcus Meissner
Modified: 2016-12-01 14:08 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

parse-exportfunc.patch (2.86 KB, patch)
2014-09-30 08:07 UTC, Marcus Meissner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 SMASH SMASH 2014-09-29 06:25:09 UTC
Affected packages:

SLE-11-SP3: bash
SLE-11-SP3-UPTU: bash
SLE-12: bash
Comment 2 Marcus Meissner 2014-09-29 07:13:10 UTC
This is also suppressed by the mitigation patch with BASH_FUNC_ prefix
Comment 3 Marcus Meissner 2014-09-30 08:07:11 UTC
Created attachment 608456 [details]

From: Chet Ramey <chet.ramey@case.edu>

Here's a more complete patch that solves this class of problem.
Comment 4 Marcus Meissner 2014-09-30 08:07:55 UTC
(discussion is ongoing when this is going public. might be today)
Comment 5 Swamp Workflow Management 2014-09-30 13:25:25 UTC
An update workflow for this issue was started.
This issue was rated as important.
Please submit fixed packages until 2014-10-07.
When done, reassign the bug to security-team@suse.de.
Comment 6 Dr. Werner Fink 2014-09-30 14:46:46 UTC
There is a problem:  bash 3.1 (SLES-10) and bash 3.2 (SLES-11) do not know the type sh_input_line_state_t and this makes the patch  parse-exportfunc.patch useless.
Comment 7 Marcus Meissner 2014-09-30 15:05:24 UTC
env 'BASH_FUNC_FOO()=() { 0;}>r[0${$(}0 {>"$(id >/dev/tty)"; }' bash -c echo

uid=0(root) gid=0(root) Gruppen=0(root),64(pkcs11)
uid=0(root) gid=0(root) Gruppen=0(root),64(pkcs11)
bash: : Datei oder Verzeichnis nicht gefunden
<empty line>

<empty line>
Comment 8 Marcus Meissner 2014-10-01 06:58:58 UTC
We were not able to reproduce this under bash 3.2 (SLE11 and older).

- The code just might not be affected at all due to missing features.

The patch is not backportable, as the parser looks quite different in bash 4.x compared to bash 3.x.
Comment 9 Dr. Werner Fink 2014-10-01 10:40:16 UTC
After some investigation I found out that the type sh_input_line_state_t was introduced by the upstream patch bash42-012:

 Bash-Release:   4.2
 Patch-ID:       bash42-012
 Bug-Reported-by:        Rui Santos <rsantos@grupopie.com>
 Bug-Reference-ID:       <4E04C6D0.2020507@grupopie.com>
 Bug-Reference-URL:      http://lists.gnu.org/archive/html/bug-bash/2011-06/msg00079.html
 When calling the parser to recursively parse a command substitution within
 an arithmetic expansion, the shell overwrote the saved shell input line and
 associated state, resulting in a garbled command.

and this add two functions save_input_line_state() and restore_input_line_state() which then are called in parse.y in the functions xparse_dolparen() and this last function does only exists in bash-4.2. From the changelog I can identify:

        - new function: xparse_dolparen, helper function for parsing
          command substitutions in $(...).  Called from subst.c to extract
          a command substitution during word expansion.  From bash-4.0-devel

this leads me to the conviction that bash-3.2 and below could be not affected
Comment 10 Swamp Workflow Management 2014-10-01 12:07:17 UTC
bugbot adjusting priority
Comment 11 Marcus Meissner 2014-10-01 14:30:04 UTC
From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Wed, 1 Oct 2014 07:21:34 -0700
Subject: [FD] the other bash RCEs (CVE-2014-6277 and CVE-2014-6278)

Good morning! This is kinda long.

== Background ==

If you are not familiar with the original bash function export
vulnerability (CVE-2014-6271), you may want to have a look at this


Well, long story short: the initial maintainer-provided patch for this
issue [1] (released on September 24) is *conclusively* broken.

After nagging people to update for a while [5] [7], I wanted to share
the technical details of two previously non-public issues which may be
used to circumvent the original patch: CVE-2014-6277 and

Note that the issues discussed here are separate from the three
probably less severe problems publicly disclosed earlier on: Tavis'
limited-exploitability EOL bug (CVE-2014-7169) and two likely
non-exploitable one-off issues found by Florian Weimer and Todd Sabin
(CVE-2014-7186 and CVE-2014-7187).

== Required actions ==

If you have installed just the September 24 patch [1], or that and the
follow-up September 26 patch for CVE-2014-7169 [2], you are likely
still vulnerable to RCE and need to update ASAP, as discussed in [5].

You are safe if you have installed the unofficial function prefix
patch from Florian Weimer [3], or its upstream variant released on
September 28 [4]. The patch does not eliminate the problems, but
shields the underlying parser from untrusted inputs under normal

Note: over the past few days, Florian's patch has been picked up by
major Linux distros (Red Hat, Debian, SUSE, etc), so there is a
reasonable probability that you are in good shape. To test, execute
this command from within a bash shell:

foo='() { echo not patched; }' bash -c foo

If you see "not patched", you probably want upgrade immediately. If
you see "bash: foo: command not found", you're OK.

== Vulnerability details: CVE-2014-6277 (the more involved one) ==

The following function definition appearing in the value of any
environmental variable passed to bash will lead to an attempt to
dereference attacker-controlled pointers (provided that the targeted
instance of bash is protected only with the original patches [1][2]
and does not include Florian's fix):

() { x() { _; }; x() { _; } <<a; }

A more complete example leading to a deref of 0x41414141 would be:

HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print
"A"x1000}'`; }" bash -c :

bash[25662]: segfault at 41414141 ip 00190d96 sp bfbe6354 error 4 in

(If you are seeing 0xdfdfdfdf, see note later on).

The issue is caused by an uninitialized here_doc_eof field in a REDIR
struct originally created in make_redirection(). The initial segv will
happen due to an attempt to read and then copy a string to a new
buffer through a macro that expands to:

strcpy (xmalloc (1 + strlen (redirect->here_doc_eof)), (redirect->here_doc_eof))

This appears to be exploitable in at least one way: if here_doc_eof is
chosen by the attacker to point in the vicinity of the current stack
pointer, the apparent contents of the string - and therefore its
length - may change between stack-based calls to xmalloc() and
strcpy() as a natural consequence of an attempt to pass parameters and
create local variables. Such a mid-macro switch will result in an
out-of-bounds write to the newly-allocated memory.

A simple conceptual illustration of this attack vector would be:

-- snip! --
char* result;
int len_alloced;

main(int argc, char** argv) {

  /* The offset will be system- and compiler-specific */;
  char* ptr = &ptr - 9;

  result = strcpy (malloc(100 + (len_alloced = strlen(ptr))), ptr);

  printf("requested memory = %d\n"
         "copied text = %d\n", len_alloced + 1, strlen(result) + 1);
-- snip! --

When compiled with the -O2 flag used for bash, on one test system,
this produces:

requested memory = 2
copied text = 28

This can lead to heap corruption, with multiple writes possible per
payload by simply increasing the number of malformed here-docs. The
consequences should be fairly clear.

[ There is also a latter call to free() on here_doc_eof in
dispose_cmd.c, but because of the simultaneous discovery of the much
simpler bug '78 discussed in the next section, I have not spent a
whole lot of time trying to figure out how to get to that path. ]

Perhaps notably, the ability to specify attacker-controlled addresses
hinges on the state of --enable-bash-malloc and --enable-mem-scramble
compile-time flags; if both are enabled, the memory returned by
xmalloc() will be initialized to 0xdf, making the prospect of
exploitation more speculative (essentially depending on whether the
stack or any other memory region can be grown to overlap with
0xdfdfdfdf). That said, many Linux distributions disable one or both
flags and are vulnerable out-of-the-box. It is also of note that
relatively few distributions compile bash as PIE, so there is little
consolation to be found in ASLR.

Similarly to the original vulnerability, this issue can be usually
triggered remotely through web servers such as Apache (provided that
they invoke CGI scripts or PHP / Python / Perl / C / Java servlets
that rely on system() or popen()-type libcalls); through DHCP clients;
and through some MUAs and MTAs. For a more detailed discussion of the
exposed attack surface, refer to [6].

== Vulnerability details: CVE-2014-6278 (the "back to the '90s" one) ==

The following function definition appearing in the value of any
environmental variable passed to bash 4.2 or 4.3 will lead to
straightforward put-your-command-here RCE (again, provided that the
targeted instance is not protected with Florian's patch):

() { _; } >_[$($())] { echo hi mom; id; }

A complete example looks like this:

HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c :


GET /some/script.cgi HTTP/1.0
User-Agent: () { _; } >_[$($())] { id >/tmp/hi_mom; }

Note that the PoC does not work as-is in more ancient versions of
bash, such as 2.x or 3.x; it might have been introduced with
xparse_dolparen() starting with bash 4.2 patch level 12 few years
back, but I have not investigated this in a lot of detail. Florian's
patch is strongly recommended either way.

The attack surface through which this flaw may be triggered is roughly
similar to that for CVE-2014-6277 and the original bash bug [6].

== Additional info ==

Both of these issues were identified in an automated fashion with
american fuzzy lop:


The out-of-the-box fuzzer was seeded with a minimal valid function
definition ("() { foo() { foo; }; >bar; }") and allowed to run for a
couple of hours on a single core.

In addition to the issues discussed above, the fuzzer also hit three
of the four previously-reported CVEs.

I initially shared the findings privately with vendors, but because of
the intense scrutiny that this codebase is under, the ease of
reproducing these results with an open-source fuzzer, and the
now-broad availability of upstream mitigations, there seems to be
relatively little value in continued secrecy.

== References ==

[1] http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-025
[2] http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-026
[3] http://www.openwall.com/lists/oss-security/2014/09/25/13
[4] http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027
[5] http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html
[6] http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html
[7] http://www.pcworld.com/article/2688932/improved-patch-tackles-new-shellshock-attack-vectors.html

PS. There are no other bugs in bash.
Comment 12 Marcus Meissner 2014-10-01 14:35:43 UTC
As SUSE has released a bash with the function prefix hardening, this new issue can not be exploited by attackers.
Comment 16 Bernhard Wiedemann 2014-10-06 09:00:19 UTC
This is an autogenerated message for OBS integration:
This bug (898884) was mentioned in
https://build.opensuse.org/request/show/254104 Factory / bash
https://build.opensuse.org/request/show/254106 13.1 / bash
Comment 21 Swamp Workflow Management 2014-10-20 13:06:14 UTC
openSUSE-SU-2014:1310-1: An update that fixes 5 vulnerabilities is now available.

Category: security (moderate)
Bug References: 898812,898884
CVE References: CVE-2014-6271,CVE-2014-6277,CVE-2014-6278,CVE-2014-7169,CVE-2014-7187
Sources used:
openSUSE 13.1 (src):    bash-4.2-68.12.1
Comment 28 Swamp Workflow Management 2016-11-22 15:04:25 UTC
SUSE-SU-2016:2872-1: An update that solves four vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1000396,1001299,1001759,898812,898884
CVE References: CVE-2014-6277,CVE-2014-6278,CVE-2016-0634,CVE-2016-7543
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP1 (src):    bash-4.2-82.1
SUSE Linux Enterprise Software Development Kit 12-SP1 (src):    bash-4.2-82.1
SUSE Linux Enterprise Server 12-SP1 (src):    bash-4.2-82.1
SUSE Linux Enterprise Desktop 12-SP1 (src):    bash-4.2-82.1
Comment 29 Swamp Workflow Management 2016-12-01 14:08:07 UTC
openSUSE-SU-2016:2961-1: An update that solves four vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1000396,1001299,1001759,898812,898884
CVE References: CVE-2014-6277,CVE-2014-6278,CVE-2016-0634,CVE-2016-7543
Sources used:
openSUSE Leap 42.1 (src):    bash-4.2-81.1