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 …
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
