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 …
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
