6 ms·

Shellshock still unfixed except in Debian unstable

25 points by r0muald 12y ago

hk__2 12y ago
Bashcheck is all green on OSX 10.9.5 with Homebrew’s Bash (4.3.30(1)-release).
- tzs 12y ago
  Almost all green with the bash that comes with OS X 10.9 with Apple's patch applied: $ ./bashcheck Testing /bin/bash ... GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13) Variable function parser inactive, bugs not exploitable Not vulnerable to CVE-2014-6271 (original shellshock) Not vulnerable to CVE-2014-7169 (taviso bug) Found non-exploitable CVE-2014-7186 (redir_stack bug) Test for CVE-2014-7187 not reliable without address sanitizer Found non-exploitable CVE-2014-6277 (lcamtuf bug #1) Not vulnerable to CVE-2014-6278 (lcamtuf bug #2) Has anyone received Apple's patch via software update? It did not show up for my Macs. I had to go to their site and download it.
deleted 12y ago
[deleted]
antoncohen 12y ago
Ubuntu patched CVE-2014-6277 and CVE-2014-6278 today: http://www.ubuntu.com/usn/usn-2380-1/ http://www.ubuntu.com/usn/usn-2380-1/ Red Hat's initial patches were more complete than upstream's patches, so updated Red Hat (and CentOS) systems are not vulnerable to CVE-2014-6277 and CVE-2014-6278. RH still contains the parsing bug(s) which is why the Shellshock test script shows a problem, but there is no known exploit so they consider it a regular bug and not a security bug: https://bugzilla.redhat.com/show_bug.cgi?id=1147189 https://bugzilla.redhat.com/show_bug.cgi?id=1147189 https://bugzilla.redhat.com/show_bug.cgi?id=1147414 https://bugzilla.redhat.com/show_bug.cgi?id=1147414
MrShankly 12y ago
From this reddit comment[1]: #debian-security at OFTC : [20:41] <clopez> PSA: #shellshock still unfixed except in Debian unstable [20:41] <clopez> http://evolvisforge.blog.tarent.de/archives/93 http://evolvisforge.blog.tarent.de/archives/93 [20:42] <clopez> is that true? I don't think so... but I guessed that better ask [20:43] <clopez> (this appeared on planet.debian.org) [20:43] <adsb> no. there are still parser bugs, but they are no longer exploitable [20:44] <adsb> (and some argument as to whether some of the later stuff should even have been given CVEs) [20:44] <clopez> oh... I see, thanks [1] http://www.reddit.com/r/linux/comments/2is3a4/shellshock_still_unfixed_except_in_debian_unstable/cl4y9l6 http://www.reddit.com/r/linux/comments/2is3a4/shellshock_sti...
skywhopper 12y ago
Ubuntu Quantal is well past end of life, so fixes won't be coming.
geofft 12y ago
There's a bit of a question about what "fixed" means here. It seems like most of these packages have applied the prefix-and-suffix mitigation measure: namely, while the function importer code is still present, it only works on environment variables with specific, uncommon names. It's basically the case that in any context where you can set environment variables with arbitrary names, you can do other sorts of evil. Several distros have not released patches for the later parser vulnerabilities _now that that codepath isn't reachable_ unless you're able to make an environment variable with the specific sort of odd name it requires. The test program here does specifically check for all the known patches with custom variable names, and maybe it's good to fix them, but it seems slightly disingenuous to suggest this is "unfixed". Remote attackers shouldn't be able to create environment variables with these names anyway. I think I'd prefer a bash that has applied the prefix-and-suffix hardening and not the patches for the lcamtuf bugs, than one that's fixed all the parser bugs we know about but still allows function imports without the prefix-and-suffix requirement.... there are probably parser bugs we don't know about.
andor 12y ago
Patching and building bash is just a horrible experience. You have to download the base version and all patches separate, and then apply each patch one by one. Some patches even expect different base directories than others (e.g. "bash-20120427", "bash-4.2-patched", "bash-4.2.47"), it's completely inconsistent. I made a quick and dirty Makefile to automate this, and then found out that bash doesn't link properly on my other system :-( On my Fedora laptop I can't even apply the patches, because GNU (!) patch doesn't accept "../" in paths anymore: "Ignoring potentially dangerous file name ../bash-4.2-patched/subst.h". If anybody still cares, here's the Makefile: https://gist.github.com/andreasf/3d508a59432476614b71 https://gist.github.com/andreasf/3d508a59432476614b71 It's for Bash 4.2 (current is 4.3.x), and it downloads and executes stuff from Github, so take care.
cbd1984 12y ago
Ubuntu was patched when this was still relatively new news.
bradleyland 12y ago
One of the VPS providers I use has provided a shellscript that has worked consistently for me, even on older distributions where a patched package isn't available: https://github.com/pbkwee/deshellshock/blob/master/deshellshock.sh https://github.com/pbkwee/deshellshock/blob/master/deshellsh...

25 points by r0muald 12y ago

hk__2 12y ago

Bashcheck is all green on OSX 10.9.5 with Homebrew’s Bash (4.3.30(1)-release).

tzs 12y ago
Almost all green with the bash that comes with OS X 10.9 with Apple's patch applied: $ ./bashcheck Testing /bin/bash ... GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13) Variable function parser inactive, bugs not exploitable Not vulnerable to CVE-2014-6271 (original shellshock) Not vulnerable to CVE-2014-7169 (taviso bug) Found non-exploitable CVE-2014-7186 (redir_stack bug) Test for CVE-2014-7187 not reliable without address sanitizer Found non-exploitable CVE-2014-6277 (lcamtuf bug #1) Not vulnerable to CVE-2014-6278 (lcamtuf bug #2) Has anyone received Apple's patch via software update? It did not show up for my Macs. I had to go to their site and download it.

deleted 12y ago

[deleted]

antoncohen 12y ago

Ubuntu patched CVE-2014-6277 and CVE-2014-6278 today: http://www.ubuntu.com/usn/usn-2380-1/ http://www.ubuntu.com/usn/usn-2380-1/ Red Hat's initial patches were more complete than upstream's patches, so updated Red Hat (and CentOS) systems are not vulnerable to CVE-2014-6277 and CVE-2014-6278. RH still contains the parsing bug(s) which is why the Shellshock test script shows a problem, but there is no known exploit so they consider it a regular bug and not a security bug: https://bugzilla.redhat.com/show_bug.cgi?id=1147189 https://bugzilla.redhat.com/show_bug.cgi?id=1147189 https://bugzilla.redhat.com/show_bug.cgi?id=1147414 https://bugzilla.redhat.com/show_bug.cgi?id=1147414

MrShankly 12y ago

From this reddit comment[1]: #debian-security at OFTC : [20:41] <clopez> PSA: #shellshock still unfixed except in Debian unstable [20:41] <clopez> http://evolvisforge.blog.tarent.de/archives/93 http://evolvisforge.blog.tarent.de/archives/93 [20:42] <clopez> is that true? I don't think so... but I guessed that better ask [20:43] <clopez> (this appeared on planet.debian.org) [20:43] <adsb> no. there are still parser bugs, but they are no longer exploitable [20:44] <adsb> (and some argument as to whether some of the later stuff should even have been given CVEs) [20:44] <clopez> oh... I see, thanks [1] http://www.reddit.com/r/linux/comments/2is3a4/shellshock_still_unfixed_except_in_debian_unstable/cl4y9l6 http://www.reddit.com/r/linux/comments/2is3a4/shellshock_sti...

skywhopper 12y ago

Ubuntu Quantal is well past end of life, so fixes won't be coming.

geofft 12y ago

There's a bit of a question about what "fixed" means here. It seems like most of these packages have applied the prefix-and-suffix mitigation measure: namely, while the function importer code is still present, it only works on environment variables with specific, uncommon names. It's basically the case that in any context where you can set environment variables with arbitrary names, you can do other sorts of evil. Several distros have not released patches for the later parser vulnerabilities _now that that codepath isn't reachable_ unless you're able to make an environment variable with the specific sort of odd name it requires. The test program here does specifically check for all the known patches with custom variable names, and maybe it's good to fix them, but it seems slightly disingenuous to suggest this is "unfixed". Remote attackers shouldn't be able to create environment variables with these names anyway. I think I'd prefer a bash that has applied the prefix-and-suffix hardening and not the patches for the lcamtuf bugs, than one that's fixed all the parser bugs we know about but still allows function imports without the prefix-and-suffix requirement.... there are probably parser bugs we don't know about.

andor 12y ago

Patching and building bash is just a horrible experience. You have to download the base version and all patches separate, and then apply each patch one by one. Some patches even expect different base directories than others (e.g. "bash-20120427", "bash-4.2-patched", "bash-4.2.47"), it's completely inconsistent. I made a quick and dirty Makefile to automate this, and then found out that bash doesn't link properly on my other system :-( On my Fedora laptop I can't even apply the patches, because GNU (!) patch doesn't accept "../" in paths anymore: "Ignoring potentially dangerous file name ../bash-4.2-patched/subst.h". If anybody still cares, here's the Makefile: https://gist.github.com/andreasf/3d508a59432476614b71 https://gist.github.com/andreasf/3d508a59432476614b71 It's for Bash 4.2 (current is 4.3.x), and it downloads and executes stuff from Github, so take care.

cbd1984 12y ago

Ubuntu was patched when this was still relatively new news.

bradleyland 12y ago

One of the VPS providers I use has provided a shellscript that has worked consistently for me, even on older distributions where a patched package isn't available: https://github.com/pbkwee/deshellshock/blob/master/deshellshock.sh https://github.com/pbkwee/deshellshock/blob/master/deshellsh...