bash "Shell Shock" vulnerability
those of you who haven't been up into the small hours looking at the bash shellshock bug: summarized here: http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/ which gives the following useful test env X="() { :;} ; echo busted" `which bash` -c "echo completed" and claims the bug exists from version 1.13 .. 4.3. It can be exploited with wget, ssh, http... They quote NIST thus: GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code 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. Authentication: Not required to exploit Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service More details, and an http exploit, are in http://seclists.org/oss-sec/2014/q3/650 Anyone on OS-X, it affects their bash, sh, csh, tcsh, zsh, ksh; ie, all the distributed shells. happy days...
On Fri, 26 Sep 2014 05:35:42 AM Douglas Ray wrote:
Anyone have dash to hand?
chris@quad:/var/tmp$ env X="() { :;} ; echo busted" `which dash` -c "echo completed" completed -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On 26/09/2014 5:22 AM, Douglas Ray wrote:
those of you who haven't been up into the small hours looking at the
... if you were looking at this then, then you were already probably far too late on this. This looks like something that must be fixed ASAP. In relation to Debian, it's been patched for Wheezy or Squeeze-LTS -- big problem if you are still on Squeeze. This looks like a very serious issue that very quickly become exploited. I would hate to think about all those boxes running busybox and how they might or might not be effected, but definitely a case of making sure that such equipment is NOT Internet accessible by any process ... lock down access to internal IP addresses, better still limit specific IP address(es). Cheers A.
On Fri, 26 Sep 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 26/09/2014 5:22 AM, Douglas Ray wrote:
those of you who haven't been up into the small hours looking at the
... if you were looking at this then, then you were already probably far too late on this.
wget -U "() { test;};/usr/bin/touch /tmp/VULNERABLE" \ http://www.example.com/cgi-bin/whatever Above is a test for a vulnerable cgi-bin script courtesy of https://twitter.com/hernano . ssh root@localhost "() { :;} ; touch /tmp/ohno" Above is a test I wrote for ssh where ~root/.ssh/authorized_keys allows access but with the "command=" option (which sets the original command to the SSH_ORIGINAL_COMMAND variable). Note that this doesn't do anything useful in the case where unrestricted ssh access is granted.
This looks like something that must be fixed ASAP. In relation to Debian, it's been patched for Wheezy or Squeeze-LTS -- big problem if you are still on Squeeze.
I've just tested the new version of bash for Wheezy, it fixes the bug.
This looks like a very serious issue that very quickly become exploited.
I would hate to think about all those boxes running busybox and how they might or might not be effected, but definitely a case of making sure that such equipment is NOT Internet accessible by any process ... lock down access to internal IP addresses, better still limit specific IP address(es).
It seems that interpreted languages aren't a good choice when taking unsanitised input from untrusted sources. The cgi-bin issue should have been dealt with by the web server sanitising input (as well as Bash not working in that way). The ssh issue is due to sshd not being a good replacement for sudo. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Douglas, please cite the CVE when discussing vulnerabilities: https://security-tracker.debian.org/tracker/CVE-2014-7169 Russell Coker <russell@coker.com.au> writes:
ssh root@localhost "() { :;} ; touch /tmp/ohno" is a test I wrote for ssh where ~root/.ssh/authorized_keys [has] "command=" option (which sets the original command to the SSH_ORIGINAL_COMMAND variable).
Ah, thanks, I had suspected this but not bothered to check it yet. If the account's login shell isn't bash, and the forced command doesn't ever create a bash process (e.g. rrsync [sic]), it should still be OK. (AFAICT)
On 26/09/2014 1:11 PM, hannah commodore wrote:
On 26 Sep 2014, at 12:30, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
I would hate to think about all those boxes running busybox and how they might or might not be effected,
busybox and dash are unaffected.
Okay.
on Debian systems, /bin/sh symlinks to dash
Patched squeeze-lts system, was just squeeze before this: # ls -lart /bin/bash /bin/sh lrwxrwxrwx 1 root root 4 Mar 1 2012 /bin/sh -> dash -rwxr-xr-x 1 root root 975488 Sep 23 01:46 /bin/bash /bin/bash is still there. A.
Andrew McGlashan writes:
on Debian systems, /bin/sh symlinks to dash /bin/bash is still there.
On Debian and Ubuntu, bash is Essential: yes, meaning that it can be implicitly depended upon, and if you remove it from your system then *all bets are off*. CVE-2014-7169 might prod people to reconsider that, but I wouldn't bet on it (too much inertia). OTOH, I didn't expect Debian to make sh -> dash the default, either.
Douglas Ray wrote:
those of you who haven't been up into the small hours looking at the bash shellshock bug:
summarized here: http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/ which gives the following useful test env X="() { :;} ; echo busted" `which bash` -c "echo completed" and claims the bug exists from version 1.13 .. 4.3.
Just out of curiosity, I thought would try out the above test; on the CLI interface on my Netcomm NB64W ADSL2+ router; (standard issue iPrimus ). Thought there was a reasonable chance it used BASH; I can TELNET 192.168.1.1 to a login prompt ; but the u/n ADMIN password doesn't seem to be the same as that for the WEB interface; anyone have any suggestions for a default p/w; or is iPrimus likely to have just locked the CLI down with no access possible ? As mentioned nothing urgent; but responses appreciated ! regards Rohan McLeod
The latest bash patchlevel 27 (a day and a half ago) at savannah seems to fix things - 4.3.27 (yes, anonymous checkout). [back up your originals] git clone git://git.savannah.gnu.org/bash.git ./configure make make test sudo make install (default install is in /usr/local/bin/, you probably want it in /bin) I'd be interested to know on which systems this compiles / tests without errors. cheers Douglas
My mileage with the savannah bash code (4.3.27 is still current): Installs have been pretty straightforward; I get unicode errors 'cause I don't bother setting up utf-8. OpenBSD 5.5 (amd64) "make tests" gives apx 1000 unicode errors OpenBSD 5.0 (amd64) ditto OS-X 10.6.8 "make tests" gives 1 line unicode mismatch xubuntu 14.04.1 (amd64) "make tests" gives apx 100 unicode errors These are fairly vanilla systems; had installed bison on the openbsds, and a few libraries, but I don't think they were needed for this. The only system with a real compromise was OS-X, the /bin/sh being a bash. (OpenBSD ships with bash uninstalled in any case; ksh for users and sh is sh.) cheers, Douglas On 30/09/14 3:10 AM, Douglas Ray wrote:
The latest bash patchlevel 27 (a day and a half ago) at savannah seems to fix things - 4.3.27 (yes, anonymous checkout).
[back up your originals] git clone git://git.savannah.gnu.org/bash.git ./configure make make test sudo make install
(default install is in /usr/local/bin/, you probably want it in /bin)
I'd be interested to know on which systems this compiles / tests without errors.
cheers Douglas _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On 2 October 2014 00:22, Douglas Ray <dougray@cpan.org> wrote:
... The only system with a real compromise was OS-X, the /bin/sh being a bash.
Apple have released an updated version of bash http://support.apple.com/kb/HT1222 http://support.apple.com/kb/HT6495 http://support.apple.com/kb/DL1769 ... But: a) only first 2 CVEs are fixed. $ bash --version GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc. $ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" /bin/sh -c ls Game Over b) the security fix is not pushed to all Macs by default. Thanks, John
(OpenBSD ships with bash uninstalled in any case; ksh for users and sh is sh.)
cheers, Douglas
On 30/09/14 3:10 AM, Douglas Ray wrote:
The latest bash patchlevel 27 (a day and a half ago) at savannah seems to fix things - 4.3.27 (yes, anonymous checkout).
[back up your originals] git clone git://git.savannah.gnu.org/bash.git ./configure make make test sudo make install
(default install is in /usr/local/bin/, you probably want it in /bin)
I'd be interested to know on which systems this compiles / tests without errors.
cheers Douglas _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Hi, On 2/10/2014 7:22 AM, John Mann wrote:
On 2 October 2014 00:22, Douglas Ray <dougray@cpan.org <mailto:dougray@cpan.org>> wrote:
... The only system with a real compromise was OS-X, the /bin/sh being a bash.
Apple have released an updated version of bash http://support.apple.com/kb/HT1222 http://support.apple.com/kb/HT6495 http://support.apple.com/kb/DL1769 ...
But: a) only first 2 CVEs are fixed.
Thanks, I was working on an email earlier -- I'll send that soon, just want to test if the /normal/ software update process will find the update by itself yet.... I've downloaded the dmg file to install it if it doesn't do so itself.
$ bash --version GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc.
$ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" /bin/sh -c ls Game Over
b) the security fix is not pushed to all Macs by default.
Dumb, it should be.... it's only tiny, it won't hurt to fix it for everyone -- but it is *Apple*, what can we expect; they've screwed up all the iOS 8 updates so far :( -- glad I don't rely on them! I wonder if I'll every pull the trigger on an iPhone one day, probably not, but who knows. Cheers A.
On Thu, Oct 02, 2014 at 07:22:57AM +1000 John Mann said:
On 2 October 2014 00:22, Douglas Ray <dougray@cpan.org> wrote:
... The only system with a real compromise was OS-X, the /bin/sh being a bash.
Apple have released an updated version of bash http://support.apple.com/kb/HT1222 http://support.apple.com/kb/HT6495 http://support.apple.com/kb/DL1769 ...
But: a) only first 2 CVEs are fixed.
$ bash --version GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc.
$ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" /bin/sh -c ls Game Over
b) the security fix is not pushed to all Macs by default.
Fixes for older versions of OS X are available here: http://tenfourfox.blogspot.com.au/2014/09/bashing-bash-one-more-time-updated... Sam
participants (9)
-
Andrew McGlashan -
Chris Samuel -
Douglas Ray -
hannah commodore -
John Mann -
Rohan McLeod -
Russell Coker -
Sam Varghese -
trentbuck＠gmail.com