Reply to post:

Bad boy builds beastly Bash bug botnet, boxen battered

Lee D

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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022