bash is a bloated pig.
most embedded devices use busybox, not bash.
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.
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?
This post has been deleted by its author
"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
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.
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.
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.
Running bash scripts to process requests on a web server is 1980-era software designGiven 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!).
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?
"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.
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]
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.
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.
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.
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.
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!
"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.
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.
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/
This post has been deleted by its author
This post has been deleted by its author
"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).
I heard it from a chum who has the technical nouse, career history, and - frankly - geeky interests that make me look like a casual observer. He might be wrong but I'd be surprised!
Still, even if the BT Hubs aren't affected, I'm sure there are some embedded devices that are, and the point still stands that updating those will be a mighty pain in the arse.
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:
http://tickets.cpanel.net
Thanks!
Phil Stark
Technical Support Supervisor
cPanel, Inc.
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:
http://tickets.cpanel.net
Thanks!
Phil Stark
Technical Support Supervisor
cPanel, Inc.
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.
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.
Would you bet your life on either of those claims?
It might feel true, and I suspect most likely don't use bash, but it's not guaranteed to be true and we have no idea how true it may be.
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
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.
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 .
I understand that at this point it's too late?
I seem to recall an input in Java 1.5.(something) that could be used to fork a shell out of a jvm.....
No. You need to run
Process p = Runtime.getRuntime().exec("bash -c '" + injectCommandLikeABeachedWhale() + '");
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?
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.
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.
hmmm.
Cyanogen 11.2
/system/xbin/bash.
/wanders off to go fiddle some more --
(for the record, most versions of weblogic have some sort of sanity checking for data strings, but if you happen to *know* the checking done....... it can get ugly fast.)
<edit>
Damn. I can point out that bash on Cyanogen 11.(2) is vulnerable as far as the default test goes.
</edit>
I was being fairly specific -- I've rooted my phone and put Cyanogen on it - I checked the other 4 phones in the house last night.
a) default shell in all cases is /bin/sh - not bash.
b) bash is present on my Cyanogen unit *and* on the moto (on the moto, it *might* have been installed by an app the young fella installed)
*and* Cyanogen pushed an update last night that has the *first* patch to bash.
Rooted iphone has something *called* bash on it but it does not appear to be a binary.
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.
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:
1. Bash immediately executes commands found in arbitrary environment variables.
2. This bug/feature was not documented.
3. The CGI standard uses environment variables for transmitting client data to CGI scripts.
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.
For example, under what circumstances does Perl's system() function invoke a shell?When it is passed a string containing active shell characters.
Which is why you should always invoke it with an array, as that will always fork()+exec() and, of course, read documentation, which is where this is mentioned.
Apparently the idea is that you can export a function, like you can export a variable (meaning it gets inherited by subshells). The function body is then communicated through an environment variable.
Example:
$ function foo { echo hello, world; }
$ export -f foo
$ tclsh # since bash doesn't show the magic variables...
% set env(foo)
() { echo hello, world
}
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.
This post has been deleted by its author
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.
Next "shockingly sensational" news please...
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 :)
>>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.