Bad boy builds beastly Bash bug botnet, boxen battered Mere hours after its discovery, the Shell Shock Bash vulnerability was exploited by an attacker to build a botnet. The bot was discovered by researcher known as Yinette, who reported it on her Github account and said it appeared to be remotely controlled by miscreants. Rapid 7 researcher Jen Ellis noted in a blog the …
What scares me most is the continued use of bash in remotely-callable scripts. I honestly thought we'd stopped doing things that way years before Perl went out of fashion and we moved to some real CGI and web security because we realised we had malicious people around.
I get having bash wrappers to, say, start services, collate and rotate logs, etc. but bash called remotely to do things like set environment variables (especially for CGI scripts, even if that was the "standard") seems dangerous from the very mention, before you even think there could be a vulnerability in bash. It's just an unsuitable tool - an entire shell, being executed by a remote user, whatever the actual context, to set some text into an environment variable.
Let me try an experiment - Windows Server, IIS, have your apps wrapped in a DOS batch file. Nobody else just as worried as I would be? ((The Windows equivalent of this bug would be, as far as I can tell, IIS being asked to retrieve a page with a request header and in doing so executing CMD with an arbitrary unchecked string taken straight from the request header to set, say, the PATH variable, or lots of other CGI-required variables, but not distinguishing between some plain environment variable content and ANY valid command. It seems... far too obvious and dangerous to have lingered in web circles for 25 years if ANYONE had been watching out for security problems)).
Bash scripts are useful but we should have stopped using them on anything remotely accessible decades ago. The only times I've ever seen it done deliberately was in a "single-floppy router" Linux distribution where literally every byte was precious and they were squeezing 2.4 kernels and full routing functionality into a 1.44Mb bootable disk (used Freesco for 8 years, I think, running my local network off dial-up and then ADSL). Even there, the use was internal, to provide things like statistics and internal configuration over a shell CGI script that obviously only had one dependency and little security (assuming no malicious local users, basically). Hell, I have had networks where the logon etc. scripts performed all kinds of miracles but - the point was - you needed to be a local user, already logged for, and they merely automated processes you were already allowed to do.
To have bash be able to be executed in the context of a remote user's HTTP request to bring in - of all things - environment variables (the bug is really that function definitions are to be in those environment variables allowed too, but even running of bash to set a string into the environment is worrying me), and have the power to run any internal bash command or - critically - any available command that the web-user can access, seems incredibly stupid to have been lain open for any length of time.
What with this and Heartbleed, someone - and I'm specifically looking at the "security" distros here - needs to go back to first principles and find stupid things that we're doing. Even if we've done them for 20 years without problem. We need to say... that's stupid. Why are we still doing that? If there's a problem in software/function X, we are fully compromised. And start to revoke trust in large corporations and organisations that have looked into these things and never spotted that running a full bash on EVERY CGI environment variable handed to you by a remote user is just an incredibly stupid thing to do, vulnerability or not.
And, of course, there's probably nothing that things like SELinux can do because - well, the user obviously INTENDED bash to act on this information because it wouldn't work otherwise.
Even perl has a resemblance of the applicable security features you need for CGI. In fact, it is probably better on that front than PHP.
Bash has none. It does not belong in a CGI end of story. Any idiot sticking bash in a CGI is frankly asking for it and they are most likely exploitable via 20 other different ways besides Shell Shock.
Bash cgis tend to fall into the category of informational only. They don't take any inputs at all and just provide info. Those are now open to abuse since a simple wget with the right parameters can cause them to do all sorts of hackery things.
Oddly enough other shells that can share functions with subshells have similar problems. Some even allow overwriting things like cp, ls or cat and you can guess that most "write only" cgis written in a shell will use at least one of them.
Is that Internet "decades"? Or "dog years"? In other words, not since we last coded such a thing in the hoary ancient past of 5 years ago. C'mon, CGI is only 21 years clock time old. Let's cut the bombast, okay?
No one *now-a-days* would code like they did years ago. Great, going forward. Problem is, who funds the effort to fix things coded 5 or 10 years ago?
What is the total technical debt accumulated across this industry, anyway? How many person-millenia would that come to?
“If you don't have time to do it right, when will you have the time to do it over?” - John Wooden (?)
@Lee D
Bash isn't useful for startup wrappers etc. That's what the bourne shell is for.
Bash should only be used as an interactive shell. Period.
Everything else is a lazy Linuxism
If you replace every mention in your post of 'bash' with '[generic] shell' you are bang on point.. Maybe that's what you meant? (Especially as you mention its use in a size critical boot floppy)
I think that CGI is going to be the "new Java", or the "new Flash" in that people will now be probing CGI for new and wonderful vulnerabilities in old systems and finding them. The whole idea behind classic CGI was pretty hackish to begin with, and there are no doubt a lot of nooks and crannies to find vulnerabilities in.
I'm not convinced that this specific exploit is going to be the apocalypse that some media are making it out to be. However, trying to patch each CGI related problem as you find it would be an endless game. Using a shell like this is like giving a power drill to a 6 year old to play with and hoping he that he's careful with it.
What would be nice for those people who are still running old CGI applications and who don't want to have to re-write them would be some sort of sanitization layer between the web server and the CGI script that takes the place of the shell while providing only the minimal functionality needed by the CGI script. If that layer is very restricted in what it can do, that would limit the number of things an attacker can try to exploit. Perhaps there is already something out there that does this, because it would seem to be a pretty logical thing to have.
CGI is nothing like flash/java etc.
Chalk and cheese.
As the 'G' suggests, it's a gateway API, and a rather simple one at that.
Any half-competent web site is already setup to be 'sanitized' as you suggest as a matter of course.. It should run under it's own id, with executable scripts owned by a different user (and therefore not writable), should be chrooted/jailed if practical, and generally be sandboxed from any functionality that it would never need.
P.S. I didn't downvote you
People running Apache: if you think you may be at risk, watch Planet Apache for a solution built into the server!
I'd take issue with the assertion that CGI+bash is likely to be the most usual vector. Applications (CGI or otherwise) that invoke bash through system() or equivalent may very well be more widespread.
Some of those could be running under a standard server. For example, SSI "<!--#exec cmd ...", or a filter running under apache's mod_ext_filter. The latter is recommended as a security measure in at least one well-reputed security book, albeit not actually running bash!
Also worth noting, Linux is particularly vulnerable. Most scripts use #!/bin/sh, which is normally old Bourne shell. Linux doesn't have Bourne shell, but uses an emulator for #!/bin/sh, and that emulator is usually bash.
FYI, something seems to be spaffing ransomware-bearing emails at us today, much more than usual. Pretending to be BACS remittances and HMRC tax notifications and linking to files hosted on obviously compromised domains (a celtic music website and an Aussie quarrying site).
Batten down your mail filters and educate your bean counters, boyos, it's going to be a rough few days.
People are conflating this with problems this does not create. The circumstances are limited. The outside world has to provide something unchecked/unvalidated content that's being stuffed into environment variables that are passed to bash to set.
This just isn't happening in very many places. When worms are created they'll find a specific instance, like some standard CGI script that is used on a lot of sites, and attack just that one thing. The SSH "issue" is a red herring since I've never seen anyone using ForceCommand except for internal-sftp which since you're running in a chroot environment has no bash available. The DHCP issue is a different one, people would be setting up rogue DHCP servers hoping to catch those using a BSD DHCP client (Macs and iPhones) if those are even vulnerable to an attack using DHCP - I don't think anyone has said they are vulnerable, only that it is possible since they use BSD DHCP client. It could only happen if you tried to connect to a DHCP server run by someone who is trying to attack BSD DHCP clients.
Beyond this, while I'm sure there are plenty of home grown things that would be vulnerable to this, home grown stuff doing THIS with a bash shell will have a ton of vulnerabilities so adding this one doesn't matter. You can't craft an automated attack against this, you have to know what is going on at the other end.
Basically, if you aren't using CGI at all, or at least are sure you aren't using it to pass untrusted data via environment variables, you don't really need to worry about outside attack at this time. Maybe more examples will be forthcoming. Not saying you shouldn't patch, but the sky isn't falling. If you have a Mac or iPhone, until it is certain that the BSD DHCP client can't be tricked into passing environment to the shell or you have patches that fix this, don't connect to random wifi hotspots.
As I understand things, it could be more insidious than that. For example, you have a PHP script you want to run. No problem since that's run directly through a dedicated module, right? However, say the PHP script at some stage wants to zip up a batch of files to send to the user or something like that. For the system to run the archiver, it will use the default shell (probably bash) as the launcher. Unless the PHP script has sanitised the HTTP_ environment variables, bash will run the exploit before proceeding to run the external command the script wanted.
I'm prepared to be proved wrong as I haven't tested this on an unpatched system but it sounds plausible.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
