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.
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.
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.
Further details: http://seclists.org/fulldisclosure/2014/Oct/9 http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html
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
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.
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$
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$
Hi Charlie, thank you for the information. I sent proof of concept code to secalert and security this morning that verifies this is still an issue, hopefully an update is released so that manual patching isn't necessary.
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.
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
"... it makes exploitation over the network impossible via the known vectors." But what about unknown vectors?
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?
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.
(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
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.
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)?
(In reply to john.haxby 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.