Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bash 'shellshock' bug is wormable

blog.erratasec.com

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Bash 'shellshock' bug is wormable

#101

Post by quesera »

bodyfour wrote: post #64
quesera wrote: post #30

Earlier quoted context omitted.

Or "I don't run UNIXes that default to bash, or hide it under /bin/sh, etc." Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays. On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow. BSDs won't have bash unless someone has gone out of their way to install it, whic…

> On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside: $ ls -ld /bin/sh /bin/bash -r-xr-xr-x 1 root wheel 1228240 Sep 21 21:37 /bin/bash -r-xr-xr-x 1 root wheel 1228304 Sep 21 21:37 /bin/sh $ /bin/sh --version GNU bash, version…

Yikes, yes. Thanks for pointing that out!

There might be more of an impact than expected on OSX, too -- no telling what Apple does with their system services.

We've seen mention of dhcp-client and CUPS. The latter, at least, could also be an issue on OSX.

Re: Bash 'shellshock' bug is wormable

#102

Post by stephenr »

samuellb wrote: post #99
TeMPOraL wrote: post #92

Earlier quoted context omitted.

Still, isn't sh quite often implemented as an alias/symlink for bash nowdays?

Yes, but Debian and Ubuntu has changed their default shell to Dash (in 2006 I think), and embedded systems usually use some lightweight shell such as BusyBox. So far from all systems do.

Just to clarify a little:

By default Debian still uses Bash for interactive user shells, but since Squeeze (early 2011), /bin/sh is provided by Dash.

Dash is used because it's faster than Bash and has less dependencies so its more resilient to failures.

for more info see https://wiki.debian.org/Shell, https://wiki.debian.org/DashAsBinSh and https://packages.debian.org/wheezy/dash

Re: Bash 'shellshock' bug is wormable

#103

Post by monort »

pbhjpbhj wrote: post #89
LeoPanthera wrote: post #8

Earlier quoted context omitted.

It's hard, but not impossible. Apparently your DHCP client passes responses from the DHCP server to bash. Let's say, for the sake of argument, that your ISP's DHCP server is compromised. A worm could then spread to your system from it. This is entirely hypothetical, but not impossible.

What responses does it pass, does it not sanitise them? Can anyone link to details of what DHCP does that's relevant here? Thanks.

Looking at http://code.metager.de/source/xref/isc-dhcp-debian/client/dh...

It seems that server_name from DHCP response is passed to environment variable without sanitising.

  3437		if (check_option_values(NULL, DHO_HOST_NAME,
  3438					lease->server_name,
  3439					strlen(lease->server_name)) == 0 ) {
  3440			client_envadd (client, prefix, "server_name",
  3441				       "%s", lease->server_name);
And script that is run after that (dhclient-script) is written in bash at least on Debian.

Re: Bash 'shellshock' bug is wormable

#104

Post by djb_hackernews »

janlin1999 wrote: post #96
patio11 wrote: post #91

Earlier quoted context omitted.

I think you underestimate attack vectors. d6c477a79ea7a633c2bb0e358e32399c1b18eb7d <-- Will ruin 1+ HNers' day sooner rather than later if they don't patch. Successful exploit doesn't require the exploit writer even knowing that vector existed to say nothing of successfully guessing a URL.

What does "d6c477a79ea7a633c2bb0e358e32399c1b18eb7d" mean? Also, I'm learning about this and am primarily concerned about the possibility of remote exploits -- if a web server returns 404 for an invalid URL, how does the attack vector work if the exploit writer does not successfully guess a URL? Thanks.

Take for example your favorite web app server, rails, django, etc. whatever it may be. (Not saying these are necessarily exploitable, but potentially)

Now imagine that for EVERY request, no matter if it is a valid path or not, one of the things it does is load all of the headers for the request into bash variables...

Re: Bash 'shellshock' bug is wormable

#105

Post by count »

cperciva wrote: post #18
patio11 wrote: post #2

Yep. We're currently basically waiting to see which completes first: a) a patch for bash which actually works gets released and then trickles into the various ways to get it on every machine in the world or b) someone writes ~10 lines of payload code (download rootkit, execute, connect to IRC channel, join botnet, etc) and then just hits everything in IP4 space with a for loop. Optionally, the for loop gets distribut…

I run no Linux/Unix/MacOS/compatible/etc machine which connects other machines How about "I don't run bash"? There are other perfectly good shells, you know...

As you well know, as long as your system doesn't use bash for anything, even implicitly :) Many folks are thinking that just because they switched their user's login shell to 'ksh' to be one of the cool ruby kids, that they're safe.

Re: Bash 'shellshock' bug is wormable

#106

Post by idorosen »

For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here:

https://github.com/ido/macosx-bash-92-shellshock-patched

Re: Bash 'shellshock' bug is wormable

#107

Post by eropple »

stephenr wrote: post #57
erikb wrote: post #50

Earlier quoted context omitted.

This more of a "should be", right? Maybe most shell scripts should use "sh" but I see "bash" way more often.

I guess it comes down to how you interpret things. I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script. If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".

You're overreaching. I write scripts against bash, not sh, because it's a better scripting language for what I need. It's more readable and its constructs are easier (for me) to follow. I don't care about POSIX-compatibility when bash can be installed literally anywhere. It's a dependency for the devops stuff that I run and maintain, much like Ruby is a dependency and all the gems in my Gemfile.

It's a considered decision, not a sign of "indecency".

Re: Bash 'shellshock' bug is wormable

#108

Post by wiredfool »

verroq wrote: post #72
schniggie wrote: post #67

CVE-2014-6271 cgi-bin reverse netcat shell https://gist.github.com/schniggie/5eeeb8ac943b5c2bb356

Approximate 0% of production systems have netcat. Just pick your favourite one liner from http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-ch... .

It's in the cloud images for Ubuntu 14.04.

Re: Bash 'shellshock' bug is wormable

#110

Post by agwa »

fabulist wrote: post #24

Test your local machine: export evil='() { :;}; echo vulnerable'; bash -c echo; Vulnerable computers will print 'vulnerable'. Test a CGI: curl -i -X HEAD " http://website" -A '() { :;}; echo "Warning: Server Vulnerable"' Vulnerable scripts will emit a "Warning" header. If you get a 405 error, try it with a GET request. I don't know the PoC fo new version which wiggles around the patch. I've tried the PoC on ksh, csh,…

> Its advisable to rename bash, and replace it with a symlink to dash; it shouldn't break any scripts

It most certainly will. dash provides a tiny subset of bash's functionality. Even scripts using #!/bin/sh often contain bashisms; a script using #!/bin/bash is certain to contain bashisms.

If you really want to swap out bash, swapping it out with ksh is likely to break fewer scripts (though it could still break scripts - ksh and bash are similar but not the same - so I don't recommend you do this).

And neither dash nor ksh have this "feature" of exporting functions through environment variables.

Post reply on HN