Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1147414 - (CVE-2014-6278) CVE-2014-6278 bash: incorrect parsing of function definitions with nested command substitutions
CVE-2014-6278 bash: incorrect parsing of function definitions with nested com...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Red Hat Product Security
impact=none,public=20140929,reported=...
: Security
: 1148661 (view as bug list)
Depends On:
Blocks: 1141602
  Show dependency treegraph
 
Reported: 2014-09-29 04:40 EDT by Huzaifa S. Sidhpurwala
Modified: 2018-07-16 07:44 EDT (History)
32 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-22 00:40:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (38.32 KB, text/plain)
2014-10-05 17:30 EDT, Max
no flags Details

  None (edit)
Description Huzaifa S. Sidhpurwala 2014-09-29 04:40:40 EDT
A security flaw was found in bash, which could be exploited remotely via applications which parse untrusted user scripts via bash. This flaw is different from CVE-2014-6277, CVE-2014-7169 and CVE-2014-7186.
Comment 1 Tomas Hoger 2014-09-29 07:32:18 EDT
This issue is mentioned publicly in Michal Zalewski's blog post:

http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html

It does not provide any details of the issue other than describing it as:

  ... I also bumped in the sixth and most severe issue so far, essentially
  permitting very simple and straightforward remote code execution
  (CVE-2014-6278) on the systems that are patched against the first bug. It's
  a "put your commands here" type of a bug similar to the original report. I
  will post additional details in a couple of days to give people enough time
  to upgrade.

However, the bash updates for Red Hat Enterprise Linux released via RHSA-2014:1306, RHSA-2014:1311, and RHSA-2014:1312 include a function name mangling patch as described in bug 1146319 comment 51.  It prevents exploitation of this issue by making bash only use environment variables with specific names (currently BASH_FUNC_*()) to define functions from its environment.  This change blocks currently known exploitation vectors and is also recommended by Michal Zalewski, the original reporter of this issue.

Links to errata that introduced the function name mangling patch:

https://rhn.redhat.com/errata/RHSA-2014-1306.html
https://rhn.redhat.com/errata/RHSA-2014-1311.html
https://rhn.redhat.com/errata/RHSA-2014-1312.html

Knowledge base article for the "Shellshock" vulnerability, that also explains the function name mangling change in the "How does this impact systems" section:

https://access.redhat.com/articles/1200223

This bug will be updated with further details of this particular issue once they are made public.
Comment 11 Eric Blake 2014-10-02 00:28:55 EDT
*** Bug 1148661 has been marked as a duplicate of this bug. ***
Comment 15 Max 2014-10-05 17:30:25 EDT
Another user experienced a similar problem:

This was caused by attempting Exploit 7 (CVE-2014-6277) listed on shellshocker.net:
bash -c "f() { x() { _;}; x() { _;} <<a; }" 2>/dev/null || echo vulnerable

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        bash -c 'f() { x() { _;}; x() { _;} <<a; }'
crash_function: strlen
executable:     /usr/bin/bash
kernel:         3.16.3-200.fc20.x86_64
package:        bash-4.2.48-2.fc20
reason:         bash killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000
Comment 16 Max 2014-10-05 17:30:27 EDT
Created attachment 944106 [details]
File: backtrace
Comment 17 Stuart D Gathman 2014-10-06 12:22:18 EDT
Another user experienced a similar problem:

Running bash check script at https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/bin/bash -c 'f(){ x(){ _;};x(){ _;}<<a;}'
crash_function: strlen
executable:     /usr/bin/bash
kernel:         3.16.3-200.fc20.i686
package:        bash-4.2.48-2.fc20
reason:         bash killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000
Comment 20 Florian Weimer 2014-10-07 17:02:12 EDT
We can reproduce this parser bug.  But we treat this as a regular bug, not a security bug, because of the fixes mentioned in comment #2.
Comment 23 Tomas Hoger 2014-10-08 16:38:41 EDT
This parser bug was corrected upstream in bash 4.3p30, 4.2p53, 4.1p17, 4.0p44, 3.2p57, 3.1p23, 3.0p22 and 2.05b p13.

http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-030
Comment 25 Vincent Danen 2014-10-14 10:15:02 EDT
Statement:

Red Hat no longer considers this bug to be a security issue. The change introduced in bash errata RHSA-2014:1306, RHSA-2014:1311 and RHSA-2014:1312 removed the exposure of the bash parser to untrusted input, mitigating this problem to a bug without security impact.

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