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 1147189 - (CVE-2014-6277) CVE-2014-6277 bash: uninitialized here document closing delimiter pointer use
CVE-2014-6277 bash: uninitialized here document closing delimiter pointer use
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=20140927,reported=...
: Reopened, Security
Depends On:
Blocks: 1141602
  Show dependency treegraph
 
Reported: 2014-09-27 21:47 EDT by Vincent Danen
Modified: 2018-07-16 07:40 EDT (History)
43 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-23 03:18:53 EST
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 Vincent Danen 2014-09-27 21:47:46 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2014-6277 to
the following vulnerability:

Name: CVE-2014-6277
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277
Assigned: 20140909
Reference: http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html

GNU Bash through 4.3 bash43-026 does not properly parse function
definitions in the values of environment variables, which allows
remote attackers to execute arbitrary code or cause a denial of
service (uninitialized memory access, and untrusted-pointer read and
write operations) via a crafted environment, as demonstrated by
vectors involving the ForceCommand feature in OpenSSH sshd, the
mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts
executed by unspecified DHCP clients, and other situations in which
setting the environment occurs across a privilege boundary from Bash
execution.  NOTE: this vulnerability exists because of an incomplete
fix for CVE-2014-6271 and CVE-2014-7169.
Comment 1 Vincent Danen 2014-09-27 21:55:29 EDT
As noted in bug 1146319 comment 51:

"""
variables-affix-4.2.patch

This is the hardening patch which adds function name mangling.  It does not fix this bug (CVE-2014-7169), but it makes exploitation over the network impossible via the known vectors.  The latter also applies to function parser bugs which may be discovered in the future.

Erratas released by Red Hat which fix CVE-2014-7169 (using the upstream patch) also contain this hardening.  Other vendors may have only applied the upstream fix for CVE-2014-7169, without this hardening patch.
"""

The blog report recommends the use of this command to determine if installed bash version is vulnerable:

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

The aim of this check is to verify if the tested bash version includes function name mangling patch as described above.  Versions without the change should be assumed to be remotely exploitable.
Comment 2 Tomas Hoger 2014-09-29 05:20:55 EDT
Note that the underlying parser flaw has not been disclosed publicly yet.  It may exist in the latest released bash packages for Red Hat Enterprise Linux.

However, the bash updates released via RHSA-2014:1306, RHSA-2014:1311, and RHSA-2014:1312 include a function name mangling patch mentioned in the comment 1 above.  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 7 Malcolm Frazier 2014-10-06 13:34:44 EDT
Good morning,

Today I noticed that my systems are still vulnerable to CVE-2014-6277 and there currently aren't any upgrades to address this issue. What I am observing is that the community dropped the ball on CVE-2014-6277 and it's still an issue and patch for CVE-2014-6278 does not fix it.

failed: [xxxxx] => {"changed": true, "cmd": "curl https://shellshocker.net/shellshock_test.sh | bash ", "delta": "0:00:00.403765", "end": "2014-10-06 09:52:14.181340", "rc": 2, "start": "2014-10-06 09:52:13.777575"}
stderr:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2533  100  2533    0     0  10492      0 --:--:-- --:--:-- --:--:--     0
bash: line 16:  8785 Segmentation fault      bash -c "f() { x() { _;}; x() { _;} <<a; }" 2> /dev/null
stdout: CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-6277 (segfault): VULNERABLE
CVE-2014-6278 (Florian's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
...ignoring


[malcolm@xxxx~]$ cat /etc/redhat-release
CentOS release 6.5 (Final)
[malcolm@xxxxx ~]$ curl https://shellshocker.net/shellshock_test.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
101  2533  101  2533    0     0   3882      0 --:--:-- --:--:-- --:--:--  4743
CVE-2014-6271 (original shellshock): not vulnerable
bash: line 16: 32344 Segmentation fault      bash -c "f() { x() { _;}; x() { _;} <<a; }" 2> /dev/null
CVE-2014-6277 (segfault): VULNERABLE
CVE-2014-6278 (Florian's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
[malcolm@xxx ~]$ rpm -qa bash
bash-4.1.2-15.el6_5.2.x86_64
Comment 8 Malcolm Frazier 2014-10-06 15:20:11 EDT
I would also like to point out that Redhat stated that known injection vectors have been mitigated. This leads me to two questions, are attackers capable of DoSing my system via CVE-2014-6277? My second question would be, are attackers capable of compromising my system using an unknown attack vector via CVE-2014-6277? If the answer to either of these is "Yes", I wouldn't believe this issue to be mitigated.
Comment 9 Charlie Brady 2014-10-07 11:05:41 EDT
The shell script at https://shellshocker.net/fixbash  builds bash-4.3 with all the patches from upstream, including the latest bash43-030 from Oct 5th. The results with that build configuration are:

bash-4.3$ sh shellshock_test.sh 
CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-6277 (segfault): not vulnerable
CVE-2014-6278 (Florian's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
bash-4.3$
Comment 10 Charlie Brady 2014-10-07 11:19:41 EDT
RHEL6 uses bash-4.1. Here is the results of latest upstream patches applied to bash-4.1:

bash-4.1$ ls
bash-4.1    bash41-004  bash41-008  bash41-012  bash41-016
bash41-001  bash41-005  bash41-009  bash41-013  bash41-017
bash41-002  bash41-006  bash41-010  bash41-014  bash-4.1.tar.gz
bash41-003  bash41-007  bash41-011  bash41-015
bash-4.1$ PATH=$PWD/bash-4.1:$PATH
bash-4.1$ which bash
~/bash-shellshocker/bash-4.1/bash
bash-4.1$ curl https://shellshocker.net/shellshock_test.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
101  2533  101  2533    0     0   5542      0 --:--:-- --:--:-- --:--:-- 34229
CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-6277 (segfault): not vulnerable
CVE-2014-6278 (Florian's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
bash-4.1$
Comment 11 Malcolm Frazier 2014-10-07 12:12:15 EDT
Hi Charlie, thank you for the information. I sent proof of concept code to secalert@redhat.com and security@centos.org this morning that verifies this is still an issue, hopefully an update is released so that manual patching isn't necessary.
Comment 12 Florian Weimer 2014-10-07 17:05:09 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 #1.
Comment 15 Tomas Hoger 2014-10-08 16:31:30 EDT
This parser bug was corrected upstream in bash 4.3p29, 4.2p52, 4.1p16, 4.0p43, 3.2p56, 3.1p22, 3.0p21 and 2.05b p12.

http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-029
Comment 16 Charlie Brady 2014-10-08 16:52:08 EDT
"... it makes exploitation over the network impossible via the known vectors."

But what about unknown vectors?
Comment 17 Johnny Hughes 2014-10-09 08:19:18 EDT
Based on comment #12 , I would gather that the segfault issue produced by:

https://shellshocker.net/shellshock_test.sh

is going to be looked at as an RHBA and not an RHSA.

Since most media outlets are pointing to the shellshocker.net scripts as the way to tell if a machine is vulnerable and since that script says RHEL (and therefore CentOS) are still vulnerable to it, I would suggest that you update your page here:

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

to address this script failure and that you do not think it is really a security issue.

Also, will the bugfix be done from this bug entry for the CVE or does someone need to specifically open a different bug for the segfault  issue if Red Hat feels the CVE is already addressed by the current releases?
Comment 21 Tomas Hoger 2014-10-10 16:37:07 EDT
Noting some more context here, as there's continued confusion around various issues related to the Shellshock issue.

The first issue that got named Shellshock is CVE-2014-6271 (bug 1141597).  Besides uncovering specific bash parser bug, it demonstrated a more important issue - that the bash parser was commonly exposed to untrusted inputs (scripts) that it was never designed to be able to handle safely.  The reason was that bash was inspecting *all* environment variables and handled any as function definition if its value started with the "() {" string (without quotes).  There are multiple use cases in which bash is run with environment variables containing untrusted input - CGI scripts, restricted SSH access, DHCP client, setuid programs which preserve selected environment variables.  More details can be found in the following article:

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

While the original fix only addressed specific parser bug, additional changes were considered to remove parser exposure altogether.  As all of the proposed changes would break backwards compatibility in some way, they were not initially applied.  Quick discovery of additional parser problems showed that such incompatible changes need to be applied sooner rather than later to prevent other parser bugs form becoming security issues.  A summary of how these mitigations were approached can be found in the following post from the original Shellshock issue reporter:

http://seclists.org/oss-sec/2014/q4/218

The change that was applied to Red Hat packages, and later upstream, was that bash was changed to only import function definitions from variables with specific names - BASH_FUNC_foo() (Red Hat packages) or BASH_FUNC_foo%% (upstream bash) to define function named foo.  See comment 2 above for the list of errata where this change was applied.

The change does not fix any specific parser bug, it prevents parser from being exposed to untrusted inputs.  In CGI or DHCP use case, bash will no longer attempt to import functions with values from remote.  SSHD's AcceptEnv is unlikely to allow passing those variable from remote.  Similar for other use cases, where a single variable with untrusted content could previously lead to arbitrary code execution.

There are arguments that this change insufficiently protects setuid applications that pass all or almost all environment variables to additional programs they spawn.  However, such setuid applications should be considered flawed.  There are many other environment variables that may allow code execution in spawned programs, ranging form obvious and rather generic as PATH, PYTHONPATH, or PERLLIB, to other more application specific.  There are multiple other variables that make bash execute code - BASH_ENV/ENV, or SHELLOPTS+PS4 (which work when bash is executed as /bin/sh in non-interactive mode):

http://seclists.org/oss-sec/2014/q3/873

With the described change in place, other parser bugs, such as this issue, are no longer considered security.
Comment 22 Tomas Hoger 2014-10-10 16:39:15 EDT
(In reply to Johnny Hughes from comment #17)
> Since most media outlets are pointing to the shellshocker.net scripts as the
> way to tell if a machine is vulnerable and since that script says RHEL (and
> therefore CentOS) are still vulnerable to it

The shellshocker.net test was rather inconsistent in how it handled CVE-2014-6277 and CVE-2014-6278 tests.  In case of CVE-2014-6277, input that triggers crash was executed directly - test did not even try to make bash process it via function import form environment.  This test checked if the specific parser bug was fixed or not.

On the other hand, the CVE-2014-6278 test does not try to test specific parser bug.  It only checks if bash imports functions from arbitrary environment variable.  So even though this bug has not been fixed in Red Hat bash packages, test reports them as not vulnerable, thanks to the change described in comment 2.

However, the shellshocker test was updated recently.  Test for CVE-2014-6277 was modified to only try to trigger the bug if bash imports function for arbitrary environment variable.  Hence the test now reports "not vulnerable" with the latest released bash packages in Red Hat Enterprise Linux.

https://github.com/wreiske/shellshocker/commit/676c811
Comment 23 Vincent Danen 2014-10-14 10:10:57 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.
Comment 24 john.haxby@oracle.com 2014-10-31 09:03:50 EDT
The statement in comment 23 says that this is a bug without a security impact, but then it is also closed as NOTABUG.

A bug without a security impact is still a bug.  Do you intend to fix this later (eg reduce its priority) or not fix it at all (WONTFIX)?
Comment 26 Huzaifa S. Sidhpurwala 2014-12-23 03:16:59 EST
(In reply to john.haxby@oracle.com from comment #24)
> The statement in comment 23 says that this is a bug without a security
> impact, but then it is also closed as NOTABUG.
> 
> A bug without a security impact is still a bug.  Do you intend to fix this
> later (eg reduce its priority) or not fix it at all (WONTFIX)?

This bug is filed against "Security Response" component. Closing this as NOTABUG means this is not a security issue. If you are worried about the non-security impact, file a different bug.

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