back to article Bash bug: Shellshocked yet? You will be ... when this goes WORM

Much of the impact of the Shellshock vulnerability is unknown and will surface in the coming months as researchers, admins and attackers (natch) find new avenues of exploitation. The vulnerability, called Shellshock by researcher Robert Graham, existed in the Bash command interpreter up to version 4.3 and affected scores of …

bash is a bloated pig.

most embedded devices use busybox, not bash.

5
11
Silver badge

I'm currently helping beta-test a new OS version for a NAS box from a well-known vendor which is BusyBox based, and we had a report from another tester overnight indicating that it too was vulnerable (at least if I'm interpreting his report correctly - I'm not a Unix guru but the test code is repeated in some of the posts below so I think it is the same item).

So running busybox might not mitigate things quite so well, unfortunately. But I can see it's going to be worth checking myself tonight to confirm.

3
0
Anonymous Coward

"when this becomes a worm "

Yep - this one could beat the Morris Worm as the worst ever!

1
0

This post has been deleted by its author

BusyBox

Hard to say. BusyBox uses the Almquist shell (ash), initially a clone of the System V.4 Bourne shell and was developed for BSD versions of Unix. GNU Bash was hand coded by the Free Software Foundation back in the 1980's and has nothing to do with ash other than both were designed to run existing (at the time) Bourne shell scripts. That said, the current crop of one-liner tests for the bug are designed to test whether or not the version of Bash that you are using is vulnerable, NOT whether ash is vulnerable. Make sense?

0
0
Boffin

Oh $!#t.

$ bash -version

GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12)

Copyright (C) 2007 Free Software Foundation, Inc.

So we all OSX users are screwed?

2
0
Silver badge

Depends...

If there was some way to remotely pass environment variables through bash, then yes, you might already have been screwed. I would expect that there is a patched version available for OSX by now. Go find it.

2
3

Re: Oh $!#t.

"So we all OSX users are screwed?"

Depends. A security patch may have been applied without upgrading the bash version. I do not use OSX, so do not know how their security patch policy works.

On my systems (openSUSE):

$ env x='() { :;}; echo "vulnerable"' bash -c 'echo "hello"'

vulnerable

hello

-- sorry about the extra line-feeds added by El Reg.

and

$ env x='() { :;}; echo "vulnerable"' bash -c 'echo "hello"'

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

hello

6
0
Silver badge

Re: Oh $!#t.

bash -version

GNU bash, Version 4.3.25(1)-release (x86_64-apple-darwin13.2.0)

But then again I use MacPorts to manage most of my command line stuff as you can't rely on Apple to update the stuff.

1
1
Silver badge

Re: Oh $!#t.

You'll have to wait for a security update for OS X. They usually bundle several up and release them every quarter or so so as not to scare the fanbois. Yay Apple.

But I don't think it will affect anyone unless they're using OS X Server facing the Internet.

2
0

Re: Oh $!#t.

I picked a bad day to quit smoking

30
0
Silver badge
Joke

Re: Oh $!#t.

"But I don't think it will affect anyone unless they're using OS X Server facing the Internet."

Well that's going to scare all two of them.

11
2
Silver badge

Re: Oh $!#t.

"But I don't think it will affect anyone unless they're using OS X Server facing the Internet."

Until it skips through the firewall on a vulnerable device.

2
0

Re: Oh $!#t.

What service do you have listening for TCP calls that will run a bash script with an environment crafted by the caller?

Why would anyone do such a weird thing?

6
1
Silver badge
Paris Hilton

Re: Oh $!#t.

What service do you have listening for TCP calls that will run a bash script with an environment crafted by the caller?

Why would anyone do such a weird thing?

Everybody who uses old-school CGI or anybody who hacked some stuff back in 2000 on the quick?

3
1
Anonymous Coward

Re: Oh $!#t.

In the old days, it was quite common for web servers to implement "dynamic" web pages by receiving a request over TCP, parsing the request parameters and set one environment variable for each (in the form of BLAH=FOO), and then launch some program. The program wrote its response on standard output, and that's what the web server sent back to the client. Later on it was codified as a standard as CGI-something (or similar)

The nature of the vulnerability is that if that if the program your web server is launching is bash, you have a huge problem because you can craft a request that will execute bash commands when bash is parsing its environment variables.

Of course, that's only one of the pieces of the puzzle. If the web server is properly configured the commands will not be able to alter the environment outside the context of the user that is running the web server process. But it is enough to sniff local files accessible to the web server, for example. Additional security layers may or may not mitigate the impact, but it the problem is potentially serious enough to be concerned.

Running bash scripts to process requests on a web server is 1980-era software design that is in dire need of an upgrade anyway, not only for security reasons but also because web software has evolved a lot since then. You have much better ways of doing it, either with less memory, CPU or with more functionality.

But there could still be machines out there doing this, perhaps sold as appliances that never upgrade themselves, that are vulnerable. I can only speak for myself, but certainly I haven't seen such a beast in ages.

12
0

Re: Oh $!#t.

Running bash scripts to process requests on a web server is 1980-era software design
Given that the ability didn't start until the early 90's it will be 1990-era software design.

Some of us can still remember when CGI handling was first added to the NCSA httpd code (and also when the entire source code first passed 1000 lines!).

9
0

Re: Oh $!#t.

I picked a bad day to quit sniffing glue.

6
1
Silver badge
Coat

Re: Oh $!#t.

Running bash scripts to process requests on a web server is 1980-era software design that is in dire need of an upgrade anyway

Doc Brown, you need more jigawatts!

I know that for some Gulf War I was before they were born, but still!

2
0

Re: Oh $!#t.

When you realize it's been twenty seven years and the guy next to you started two years ago and is VERY opinionated. Yeah, sniff the glue.

3
1
Silver badge
Trollface

Re: Oh $!#t.

I picked a bad day to quit trolling.

6
1

Re: Oh $!#t.

Using MacPorts (or Hoebrew) doesn't protect you against this in any way. First, bash isn't normally replaced with MacPorts, you'd have to explicitly include it in MacPorts. Moreover, since you or some user must explicitly enable MacPorts for use by some specific user - and hopefully never root or system users - everything else is still using the distro bash, e.g. cron, apache, anything other than users relying on MacPorts. So you're still left with a vulnerable bash even if you have MacPorts.

0
0

Re: Oh $!#t.

I picked a bad day to quit amphetemines

0
0

Re: Oh $!#t.

This won't be a huge future problem for dynamic content on web servers, since they will be patched readily. Most have probably already been patched. The problem is that CGI is used in the web interface of many current devices, such as routers, switches, security cameras, etc. It will be months before all of these are patched. Still, those sort of devices are not usually directly accessible from the internet. I don't look for this to be a huge problem going forward. I worry about the fact that this bug has been in place for decades. Has someone been exploiting this for decades without detection?

0
0

Re: Oh $!#t.

Everybody who uses old-school CGI or anybody who hacked some stuff back in 2000 on the quick?

CGI is the obvious vector, but others include programs that invoke system(3) with insufficiently-vetted attacker-supplied data, if bash is the shell for the account that program runs under. Advisories have mentioned some dhcpd configurations, for example (though I haven't looked at the sources to confirm the vulnerability).

It's also possible to set environment variables with typical telnetd and sshd implementations. Again, I haven't personally tried to exploit Shellshocked through one of those, but I wouldn't rule it out without investigation.

Security protection for environment variables has typically been done by blacklisting (e.g. prohibiting setting PATH and LD_LIBRARY_PATH in sensitive environments) or whitelisting (programs will only set particular variables). It's rare to have programs that do support setting environment variables actually put much effort into vetting the supplied values.

1
0
Anonymous Coward

When do the films come out?

"Shell Shocked", "Heartbleed" ??!

What's next?

"Firewall of Death"

"Microshaft"

"aPColypse now"

"TellallNet"

"Bay of Pings"

I mean since the big IT players have had films about them/being made about them, I suppose it is only natural that these kind of things are next.

22
0
Silver badge

Re: When do the films come out?

"Smoking Hashroom"

"Randthrax Attacks"

"Illegal State of Siria and the Login"

2
0
Gold badge
Coat

Re: When do the films come out?

When the attack is specially crafted to put porn on church websites: Bashing the Bishop

Then they'll try to hack the Coronation Street child stars in: Bash Street Kids

After which an attack will be crafted for London and Essex called: Bish Bash Bosh

At some point there must also be an attack on Bashar Assad...

[I'd best get my coat hadn't I]

9
0
Happy

Re: When do the films come out?

Ooooh. I like "Bay of Pings".

Please somebody, find this vulnerability, as soon as possible.

6
0
Anonymous Coward

Re: When do the films come out?

I suppose it could be the title of an eBay denial of service attack?

2
0
Coat

Re: When do the films come out?

Sounds like the follow-up to "Ping Flood"... do we need to negotiate royalties? Maybe work "Ping of Death" into the franchise too...

0
0
Silver badge

Important, but easily fixed

You do not need to get you vendor to tell you if you are affected. Just type:

x='() { :; } ; echo shellshockable' bash -c 'echo test'

If you updated your software last night (this morning for Rasbian) you will get:

bash: error importing function definition for `x'

My router says:

/bin/sh: bash: not found

Embedded systems often use one of the trimmed down shells available with Busybox. Ash and lash are not vulnerable.

This is important, as CGI passes parameters to through the environment, CGI scripts can be written in bash and it is easy to install vast amounts of software on a Linux system, some of which might still use '90s tech because it did not break every time a vendor required their users to buy an upgrade. If you need to test some embedded system without any obvious access to the shell, try a google search for your device's name with the word 'telnet'. If you actually find one that uses bash, and the vendor does not have new firmware ready by tonight, look for a replacement that can run openwrt.

5
0

Re: Important, but easily fixed

> My router says:

> /bin/sh: bash: not found

Just to be sure, try replacing 'bash' with 'sh':

x='() { :; } ; echo shellshockable' sh -c 'echo test'

(You'll probably find that your router is still safe.)

2
0

Even the fix is flawed... CVE-2014-7169

6
0
Silver badge
Trollface

Damned bash who does it work?

0
0
Anonymous Coward

Thanks for the heads up on the flawed fix TrevorH. RedHat have an advisory here.

Looks like a bit of a fustercluck.

4
0
Silver badge
FAIL

"The use of shells for CGI was discouraged since the mid 90s."

Who the hell sets up servers allowing bash to be available.

There are chroot options, restricted shell options and other sandboxing if you NEED a shell at all.

4
0
Silver badge

Re: "The use of shells for CGI was discouraged since the mid 90s."

Yes, yes, yes.

In other news, homeopathy is still a hot topic.

9
0
Silver badge

Not as serious as openssl issue

Hearbleed affected lots of software, many of which may have shipped with modified versions of the openssl library or statically with it.

This is bash. One patch and the entire system is fixed. On top of that I suspect the number of webservers with externally facing and exploitable cgi scripts that ran bash and where an environment variable could be injected in some way is rather low. It's probably a greater threat from internal users who might be able to exploit an ssh session or a restricted shell in some way.

But again it's one patch and I suspect most dists already have the patch ready to go.

8
1
Anonymous Coward

Re: Not as serious as openssl issue

Heartbleed could allow you to disclose system information which then allows you a direct attack vector.

This IS a direct attack vector and not just via unpatched webservers. All very well saying a patch will sort it, but there have already been reports of tools like massscan being used to exploit machines.

I would bet that more machines are compromised because of this and the highly public nature surrounding it than because of heartbleed.

2
0
Silver badge

Lots of sites have man-pages

The first google search I tried, three of the first four sites use a CGI bash script to return search results for man pages. Those sites either have already, or urgently need to replace bash.

1
0
Silver badge

Re: Not as serious as openssl issue

It's not simply "one patch" if the system is embedded and everything boots from on-board flash chips. Those can be very difficult to patch and especially if the manufacturer has deliberately made it that way.

Desktop systems and the like probably can be easily patched, it's the billions of routers and IoT-type devices which are the big risk.

1
0

Re: Not as serious as openssl issue

If it's embedded then it most probably won't have bash

2
0
Silver badge
Mushroom

Some people does not get it.

The CGI vector is one of possible vectors, anything that creates or invokes a sub-shell is at risk if that sub-shell is bash.

With such a hole in bash parsing I'm sure that someone with more imagination and more free time than me will find creative ways to exploit plenty of systems, not just those that run CGI's on a web server.

The patch is straight-forward people, go and patch!

2
0
Silver badge

Too pessimistic

"Scan your network for things like Telnet, FTP, and old versions of Apache (masscan is extremely useful for this). Anything that responds is probably an old device needing a bash patch.

This looks like alarmism. As others have noted, embedded Linux systems usually use Busybox. Even if the shell feature from Busybox is not used, some light-weight alternative to bash as the system's /bin/sh is likely.

In addition, many network devices run some variant of BSD, which has never had bash as the default shell.

6
0

Ok, it's early and I haven't finished my coffee yet. Isn't this an injection vulnerability due to not escaping the remote input before using it to set the environment variable?

What is crafting the command which is setting the env with a function using the remotely supplied value?

0
0
Silver badge

It is nastier than that

Using the CGI attack vector, the web server will un-url-escape a string I supply and put it into an environment variable. The CGI script is expecting an unescaped string, so the standard does not provide a way to prevent my choice of string going into an environment variable.

Bash provides a mechanism to export bash functions to a bash sub-process. Bash assumes any environment starting with '() {' is a function. Defining a bash function is part of the bash language, and bash uses the bash interpreter to convert the environment variable into a function definition. The bad news is that the interpreter did not stop at the end of the function definition. Extra text in the environment variable after a function definition gets interpreted just like a bash script.

If a web server has a vulnerable version of bash, and a CGI script either written in bash or using a bash sub-process that receives the CGI environment then remote users can execute their own bash scripts with the authority of the web server.

The obvious places to prevent this are any of these:

*) make bash stop interpreting function definitions at the end of the function definition.

*) use something like fastcgi which passes parameters through file descriptors instead of environment variables.

*) Do not write write CGI scripts in bash AND ensure that the environment is sanitized before starting a bash sub-process.

5
0
Silver badge

Some Cream for that Coffee.

Ok, it's early and I haven't finished my coffee yet. Isn't this an injection vulnerability due to not escaping the remote input before using it to set the environment variable?

What is crafting the command which is setting the env with a function using the remotely supplied value?.....Chris--S

An irregular and unconventional intelligence somewhat greater than the norm and for/from future operations rather than from/for past systems in present race overlode conditions/critical situations seems most probable and likely however inconvenient that might be to current executive admins. Chris--S.

I wonder if Kevin Mitnick is selling it? ....... `http://www.wired.com/2014/09/kevin-mitnick-selling-zero-day-exploits/

3
0

This post has been deleted by its author

Silver badge
Unhappy

It seems the patch is not quite there yet...

Not a definitive patch yet.

https://bugzilla.redhat.com/show_bug.cgi?id=1141597

0
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017