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 …

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.

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?

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.

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.

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.

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.

Re: Oh $!#t.

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?

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.

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

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.

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.

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.

Re: Not as serious as openssl issue

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.

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.

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.

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.

Re: "since most of them can't be patched"

"Can you compile the update of Bash for a BT Home Hub, or do you have to wait for BT to push out a full firmware update?"

Are we SURE this devices uses bash? As the article and several comments note, embedded devices are strapped for space and are more likely to use a compact implementation like that in busybox, which isn't affected. Other network-facing devices are just as likely to be running BSD than Linux, and BSD prefers the C shell csh (usually TENEX C Shell or tcsh) over the Bourne shell sh(and the bug in this case is specific to the Bourne-Again Shell bash).

cPanel's defaultwebpage.cgi not vulnerable

Our internal testing showed that /cgi-sys/defaultwebpage.cgi was not vulnerable by this exploit. It is not written in bash and does not make any calls to bash.

If you have evidence to the contrary, or are aware of any other CGI scripts distributed by cPanel that are vulnerable we would greatly appreciate it if you'd open a ticket with us with this information:

cPanel defaultwebpage.cgi vulnerability

Our internal testing showed that /cgi-sys/defaultwebpage.cgi was not vulnerable by this exploit. It is not written in bash and does not make any calls to bash.

If you have evidence to the contrary, or are aware of any other CGI scripts distributed by cPanel that are vulnerable we would greatly appreciate it if you'd open a ticket with us with this information:

Graham's blog says many "internet of things" devices will be vulnerable and will remain so because they can't be patched. They may be vulnerable, but not to this bug. As 'tards have pointed out, IP cameras etc. aren't equipped with Bash, why would they be ? Embedded stuff, even more substantial items like NAS boxes routers, come with Busybox only.

Also. Errr. Isn't Graham breaking the law in rather an extravagant way by blithely scanning thousands or organizations ? Notwithstanding his good intentions.

Yes, I pretty much would bet my life on webcams et al not using bash, for sound economic/engineering reasons. Bash is a big, big program and needs a full computing environment to run. The binary alone is over 1 MB, almost twice the size of Busybox. Even a quiescent bash instance takes several MB of memory to run, plus many libraries, plus all the other programs the user will call. Manufacturers use Busybox because it replaces all that. I have never seen an embedded device that had standalone Bash. Big NAS boxes conceivably, but I have never seen it.

The bigger danger is web servers. I saw Graham's shellshock scan at 8:20 this morning in my logs, and patched the server an hour ago. And devices like Raspberry Pi's where the user has it internet facing for

Bigger items

On the other hand, internet facing NAS devices might

systems would be out of business.

To run it, the IP webcam would have to be running a full linux kernel/environment and have

shell shocked admins?

I think I've got my head wrapped around the worst of this one:

a) in the case of ssh calling bash, this is not an issue until after authentication has completed, ie, you cannot (at the moment at least from what I've read and tested) *spawn* a shell without completing the authentication process. -> no open sewer there that would have opened a pit to hell.

With ssh the issue is the "ForcedCommand" functionality - authentication completes, and with some creativity a user COULD pass in a function definition that would spawn them a shell.

I've about 40 of these accounts out there and I don't know about anyone else, but I wipe the environment at the top of the script intentionally ... and then parse the hell out of the command coming in to make sure it qualifies.

b) HOWEVER - in cases where services are exposed to the network, where those services *can* accept input from outside, and where those services then *can* call or invoke a shell with that input (unchecked) -

You haz a great big cheezburger.

So - at least in my *managed* apache environments we don't allow cgi, and php is heavily limited, we don't have any *screaming* issues -- I've found a couple of things that made me go *ick* but nothing terrifying.

I don't do the DHCP, but its on BSD and should not have an issue

things like weblogic and jboss at this point make things in my gut go ickky. I seem to recall an input in Java 1.5.(something) that could be used to fork a shell out of a jvm.....

We have a few "packaged" apache solutions. *sigh* no comment. 3rd party vendors getting calls to investigate those.

Last check of the patched RH systems indicates that the issue is not 100% resolved yet - and my fedora systems arent fixed yet either. Its gonna be a hella long weekend for some admins.

Re: shell shocked admins?

I may be being stupid here

But I was always told that if you absolutely had to allow a webserver access to a bash script or built in function then you should really completely sanitise what you send it. That is, only allow that which should be allowed. So if people are getting bitten on the backside by this then it must be sloppy practice on their part?

Re: I may be being stupid here

Not so much but then again yes.

The problem is not that you know you have to sanitize input so much as having to know WHAT to sanitize it against. Or to make it more clear, to avoid passing inputx, you first have to know inputx was bad news. And unless you can convince me that you are aggressively (re)parsing and conforming your input, which i doubt anyone is, guess what, you're doing the basic checks just like everyone else, and this will go though.

Can't resist the temptation to bash the zealots (pardon the pun). So, again, there goes the many eyes theory down the drain... The reverse on the contrary is quite true. Once you get many "bad eyes" looking at you, the nasty water starts popping out of the sewer lid.

Re: What about Windows

Smartphone vulnerability?

There's been mention of a potential vector for iPhones using DHCP; I guess the BSD DHCP client supports a way of receiving environment variables from the server, so a rogue DHCP server could potentially be set up.

Does Android also use bash? I assume there are no external ports open, so I can't think of any way this could be exploited. It would be fairly nasty if it could, given that most Android devices wouldn't be updated.

Re: Smartphone vulnerability?

"Cyanogen 11.2

/system/xbin/bash."

This appears to be specific to custom ROMs. Mine's a lightly-touched TouchWiz job, and bash is missing from it. Which lends credence to my supposition that most Android installs lack bash and are thus safe for now.

Re: Smartphone vulnerability?

I may be wrong, but I think Android's default is the basic Bourne Shell sh. Bash has to be explicitly installed, and I think that takes a rooted phone. Since sh isn't robust enough to be vulnerable to the same problem as bash, most Android implementations should be safe. Besides, most Android rooters tend towards Busybox, which is also safe.

Re: Stupidest bug ever

Passing function definitions via environment variables is a useful feature for an interactive shell and this feature is not disabled by the recent patches. The security problems are not caused by that but by a combination of several other things:

4. Some people have used bash for CGI scripts and the like, either deliberately or accidentally.

Arguably there is a pervasive problem of programs invoking shells in various unclearly documented circumstances. For example, under what circumstances does Perl's system() function invoke a shell? Does "ssh user@host command" use a shell for interpreting the command, or doesn't it? If you're not an experienced hacker you probably can't answer those questions with great confidence in the correctness of your answers.

Re: Stupidest bug ever

Using environment variables to export functions is not a stupid idea. Doing it in such a way that every variable gets interpreted as a function if it looks like one *is* stupid. A program's environment variables can contain any text; it's none of the shell's business if that text happens to start with certain characters. They could perfectly well have used a single variable with a defined name that contained all the functions, or they could have used, say, BASH_VARIABLE_foo for the function foo.

Re: First Heartbleed...

OSX fix didn't take long

That's the nice thing about an OS that at least borrows from Open Source in a way that keeps it usable - it took all but 4 minutes to pull in the updated bash code, recompile it and replace the exposed binaries.

Too much ado about almost nothing...

It's pretty bad and embarrassing that the popular Shell is capable of this unintended stuff. However, if you're writing a script you would be able to do all the "scary" things the proper way already. As far as things CGI, every shell is not the safest language by its nature and should not be used for this risky business. It's a SHLELL of the system, not a webserver "shell". The article reiterates this known for ages postulate. Shell doesn't have the power nor the convenience of the more capable languages like perl, php, python etc.

Moreover, taking input from a stranger is dangerous already and asks for trouble. Proper tools and checks are to be in place to minimize the likelihood of this. Single quotes in Perl is one solution, not a panacea though, if an input is still blindly passed to operators, say, you can get ddos'ed by feeding it too big of a number or too long of a string, than you intended those to be, if the latter is not being properly checked.

So again, a shell should not have been used in cgi, other potential explorations, like embedded devices, are pretty questionable, as many commenters have said above. Busybox is what is used there for default shell. I got Tomato usb Netgear router here and installed bash on it, the version of which is vulnerable. However, one can talk to it via ssh and web interface within the local network only. The latter is protected by password, the former -- by ssh key. cgi doesn't use bash, the admin panel of the web interface does take the system commands there, which was intended to be so already.

Re: Too much ado about almost nothing...

Now you have two, but you get the benefit of an explanation. This is NOT a problem with the exposure method, be it CGI or whatever. It's a problem with Bash not properly parsing vars. Trying the "it's not supposed to be used for" defense is just about as good as Job's "you're holding it wrong" stunt... A spade is a spade and a vulnerability a vulnerability.

And your comment only proves that Open Source has long moved from a "philosophy" to a religion, shock full of dogmas and unwilling/unable to face (even substantiated) criticism. and like a "good" religion, you obviously must be "right" thus can do no wrong. And along comes the usual "it's not important/relevant/substantial" excuses zealots, especially the devs, are so fond of.

Grow up, a turd is a turd, and if you call it an OpenTurd it still won't smell like roses :)

Re: Too much ado about almost nothing...

>>This is NOT a problem with the exposure method, be it CGI or whatever. It's a problem with Bash not properly parsing vars.

We must be reading different articles. What you're talking about is the original article about the GNU Bash bug. This one about the inexorable, inevitable doomsday awaiting the humanity due to the affect on cgi. This is a vulnerability affecting all those abusing shell in places it didn't belong even without a single vulnerability as well as might cause some local problems and break local scripts.

>>..as good as Job's "you're holding it wrong" stunt...

It would be my job to correct you your apostrophe as well as observe that you either reading my comment from the right to the left or looking at the wrong article.

>>And your comment only proves that Open Source has long moved from a "philosophy" to a religion, shock full of dogmas and unwilling/unable to face...

Can't talk on behalf of the whole FOSS or OSS. Common sense is my religion, calling spade a spade, or overly-sensational journalism overly-sensational is one of my dogmas, when I am not too lazy.

>>Grow up, a turd is a turd, and if you call it an OpenTurd it still won't smell like roses :)

Not sure about your age, yet judging from "Grow up" there is a high chance I had grown up long before you were born.