Opened 10 years ago
Closed 10 years ago
#45162 closed defect (fixed)
bash @4.3.25: Vulnerable to code execution in environment variables (CVE-2014-7169)
Reported by: | kost.hc@… | Owned by: | raimue (Rainer Müller) |
---|---|---|---|
Priority: | High | Milestone: | |
Component: | ports | Version: | 2.3.1 |
Keywords: | Cc: | cooljeanius (Eric Gallager), neverpanic (Clemens Lang), hahn.seb@…, breiter (Brian Reiter), sierkb@… | |
Port: | bash |
Description
Bash is still vulnerable to the shellshock bash:
$ sudo port selfupdate Password: ---> Updating MacPorts base sources using rsync MacPorts base version 2.3.1 installed, MacPorts base version 2.3.1 downloaded. ---> Updating the ports tree ---> MacPorts base is already the latest version The ports tree has been updated. To upgrade your installed ports, you should run port upgrade outdated
$ sudo port install bash ---> Computing dependencies for bash ---> Cleaning bash ---> Scanning binaries for linking errors ---> No broken files found.
$ bash --version GNU bash, version 4.3.25(1)-release (x86_64-apple-darwin13.2.0) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
It is not vulnerable to this:
$ env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" /bin/sh: warning: X: ignoring function definition attempt /bin/sh: error importing function definition for `X' stuff
But still vulnerable to this:
$ env X='() { (a)=>\' sh -c "echo date"; cat echo sh: X: line 1: syntax error near unexpected token `=' sh: X: line 1: `' sh: error importing function definition for `X' Fri Sep 26 00:48:31 CEST 2014
If you need more info, check this URL: http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
Attachments (2)
Change History (27)
comment:2 Changed 10 years ago by mf2k (Frank Schima)
Owner: | changed from macports-tickets@… to raimue@… |
---|
In the future, please Cc the port maintainers (port info --maintainers bash
) so that this can actually get fixed.
comment:3 Changed 10 years ago by mf2k (Frank Schima)
For reference the actual test is (as mentioned by the reporter in the description):
$ rm -f echo $ env X='() { (a)=>\' sh -c "echo date"; cat echo sh: X: line 1: syntax error near unexpected token `=' sh: X: line 1: `' sh: error importing function definition for `X' Fri Sep 26 11:29:03 MDT 2014
The fact that the date prints out is the bug. In a properly patched system, here is the output:
$ rm -f echo $ env X='() { (a)=>\' sh -c "echo date"; cat echo date cat: echo: No such file or directory
comment:4 Changed 10 years ago by raimue (Rainer Müller)
Status: | new → assigned |
---|---|
Summary: | Bash still vulnerable → bash @4.3.25: Vulnerable to code execution in environment variables (CVE-2014-7169) |
Duplicate of
comment:6 Changed 10 years ago by neverpanic (Clemens Lang)
Cc: | cal@… added |
---|
It seems Debian pushed two new versions of bash with security fixes:
- 4.2+dfsg-0.1+deb7u2 with a fix for CVE-2014-7169, see https://tracker.debian.org/news/573425
- 4.2+dfsg-0.1+deb7u3 fixing an out-of-bound array access in the bash parser and a patch that moves all exported function definitions into a separate "namespace".
The patches in question are:
- http://sources.debian.net/src/bash/4.3-9.2/debian/patches/CVE-2014-7169.diff/ (CVE-2014-7169)
- http://sources.debian.net/src/bash/4.3-9.2/debian/patches/parser-oob.patch/ (out-of-bounds access in parser)
- http://sources.debian.net/src/bash/4.3-9.2/debian/patches/variables-affix.patch/ (namespaced function exports)
I'll test those in a second and attach a patch.
comment:7 Changed 10 years ago by sierkb@…
As of late, an official fix for CVE-2014-7169 has been published by GNU project: http://ftp.gnu.org/gnu/bash/, patch 26 for Bash 4.3 http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-026, see also http://seclists.org/oss-sec/2014/q3/734.
Please update MacPorts' bash portfile in version, patchlevel and checksums of the patches accordingly from 4.3.25 to this new availlable patch level 4.3.26 as soon as possible.
Changed 10 years ago by neverpanic (Clemens Lang)
Attachment: | bash-port-debian-patches-fixes-cve-2014-7169.diff added |
---|
Patch against the Portfile porting all three changes from debian
Changed 10 years ago by neverpanic (Clemens Lang)
Attachment: | bash-port-debian-patches.diff added |
---|
Patch against the Portfile updating to 4.3.26 and porting Debian's patches
comment:8 follow-up: 9 Changed 10 years ago by neverpanic (Clemens Lang)
The official fix in patchlevel 26 is the same as in Debian's CVE-2014-7169.diff
. I've attached a patch that updates the port and also ports Debian's patches. I'll leave it up to you to decide whether you also want Debian's patches or just upstream's fix.
I've verified that function exports work after this patch. When they get exported into environment variables, they are prefixed with BASH_FUNC_
and suffixed with ()
.
comment:9 Changed 10 years ago by sierkb@…
Replying to cal@…:
The official fix in patchlevel 26 is the same as in Debian's
CVE-2014-7169.diff
. I've attached a patch that updates the port and also ports Debian's patches. I'll leave it up to you to decide whether you also want Debian's patches or just upstream's fix.
More details:
Debian's additional so far non-official patches seem to be these here: https://lists.debian.org/debian-devel-changes/2014/09/msg03214.html, brought onto the table by Red Hat (Florian Weimer, Huzaifa Sidhpurwala) as so far non-upstream patches (not yet officially completely verified and assimilated upstream by the GNU Bash project) and discussed here: seclists.org (oss-sec): Fwd: Non-upstream patches for bash http://seclists.org/oss-sec/2014/q3/712. Additional to the official patch against CVE-2014-7169, they add so-far-non-upsteam fixes against CVE-2014-7186 https://access.redhat.com/security/cve/CVE-2014-7186 and CVE-2014-7187 https://access.redhat.com/security/cve/CVE-2014-7187. If these additional so-far-non-upstream-patches maybe will be followed by a further official upstream patch by the GNU project (the chance is not zero, that this might happen), is out of my knowledge at this time of writing.
I back the statement in comment:8, it's up to you, as the maintainer of this port, wether you want to be conservative and be on par with the current upstream status or anticipate its status by going a (yet unofficial) step ahead.
comment:10 Changed 10 years ago by larryv (Lawrence Velázquez)
Cc: | hahn.seb@… added |
---|
Has duplicate #45173.
comment:11 follow-up: 12 Changed 10 years ago by breiter (Brian Reiter)
The NetBSD and FreeBSD solution is an excellent mitigation. It removes the whole misfeature of passing function definitions to child shells by default.
https://svnweb.freebsd.org/ports?view=revision&revision=369341
comment:12 Changed 10 years ago by neverpanic (Clemens Lang)
Replying to brian.reiter@…:
The NetBSD and FreeBSD solution is an excellent mitigation. It removes the whole misfeature of passing function definitions to child shells by default.
That may be your opinion, but doing this breaks people's scripts, and is not something I'd be willing to do, unless bash upstream is also going to. I think the Debian patch reduces the attack surface for future bugs in function importing from the environment to situations where attackers control the variable name, which mitigates the remote code execution problems.
comment:13 Changed 10 years ago by raimue (Rainer Müller)
I committed an update to bash @4.3.26 in r125830.
I think at this point it also makes sense to also take the other patches from Debian, especially for the new issues CVE-2014-7186 and CVE-2014-7187.
Clemens (cal@), what is the source of the patches you posted? I would like to add a proper "Upstream: <URL>" or "Origin: <URL>" attribution in the patch files so we can reconstruct where they came from originally.
comment:14 Changed 10 years ago by neverpanic (Clemens Lang)
I got them from the Debian URLs posted above. Not sure where they got them from.
comment:16 Changed 10 years ago by hahn.seb@…
In the meantime, there's an official 4.3.27 out. I assume attaching a patch would make it more work for you compared than just making it yourself ;)
comment:17 Changed 10 years ago by raimue (Rainer Müller)
Update to bash @4.3.27 committed in r125869.
comment:18 Changed 10 years ago by neverpanic (Clemens Lang)
Patchlevel 27 contains the namespaced function exports, but as far as I can see the parser OOB accesses are still unfixed. AFAIK meanwhile CVE numbers have been assigned for those, too.
comment:20 Changed 10 years ago by sierkb@…
Just for the record:
Ticket #45234: Checksum (sha1) mismatch for bash43-028
comment:21 Changed 10 years ago by sierkb@…
Please update to bash @4.3.29 (Patchlevel 29, published 10/03/2014 upstream at ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/).
comment:22 Changed 10 years ago by sierkb@…
comment:23 Changed 10 years ago by sierkb@…
Please update to bash @4.3.30, Patchlevel 30, published 10/05/2014 upstream at
ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/,
http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-030,
https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00040.html,
http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ca6a2ba40c709c2b45a56e49d21d0dfc66e21974
comment:25 Changed 10 years ago by raimue (Rainer Müller)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
With all the patches in place, I consider this particular issue as fixed. If new security vulnerabilities arise, please open a new ticket.
Ticket you already have: https://trac.macports.org/ticket/45150
But the ticket fixes CVE-2014-6271 (first bug), but bash is still vulnerable to second test/bug (CVE-2014-7169): http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169
Take a look here for the tests: https://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/146851#146851