Unix/Linux Bash: Critical security hole uncovered

[nedo]

Bash, aka the Bourne-Again Shell, has a newly discovered security hole. And, for many Unix or Linux Web servers, it's a major problem.

Like many others, I use Bash for my default desktop and server shell, which means I need to get it patched as soon as possible.

The flaw involves how Bash evaluates environment variables. With specifically crafted variables, a hacker could use this hole to execute shell commands. This, in turn, could render a server vulnerable to ever greater assaults.

By itself, this is one of those security holes where an attacker would already need to have a high level of system access to cause damage. Unfortunately, as Red Hat's security team put it, "Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue."

The root of the problem is that Bash is frequently used as the system shell. Thus, if an application calls a Bash shell command via web HTTP or a Common-Gateway Interface (CGI) in a way that allows a user to insert data, the web server could be hacked. As Andy Ellis, the Chief Security Officer of Akamai Technologies, wrote: "[/url=https://blogs.akamai.com/2014/09/environment-bashing.html]This vulnerability may affect many applications that evaluate user input, and call other applications via a shell."

That could be a lot of web applications — including many of yours.

The most dangerous circumstance is if your applications call scripts with super-user — aka root — permissions. If that's the case, your attacker could get away with murder on your server.

So what can you do? First you should sanitize the web applications' inputs. If you've already done this against such common attacks as cross-site scripting (XSS) or SQL injection, you'll already have some protection.

Next, I'd disable any CGI scripts that call on the shell. (I'd also like to know why you're still using a 21-year old way of allowing users to interact with your web services. You might want to use this opportunity to replace your CGI scripts once and for all.)

After that, I'd follow Akamai's recommendation and switch "away from using Bash to another shell." But keep in mind that the alternative shell will not use exactly the same syntax and it may not have all the same features. This means if you try this fix, some of your web applications are likely to start acting up.

Of course, the real fix will be to replace the broken Bash with a new, secure one. As of the morning of September 24, Bash's developers have patched all current versions of Bash, from 3.0 to 4.3. At this time, only Debian and Red Hat appear to have packaged patches ready to go.

OpenSSH is also vulnerable via the use of AcceptEnv variables, TERM, and SSH_ORIGINAL_COMMAND. However, since to access those you already need to be in an authenticated session, you're relatively safe. That said, you'd still be safer if you blocked non-administrative users from using OpenSSH until the underlying Bash problem is patched.

It's extra work, but if I were a system administrator, I wouldn't wait for my Unix or Linux distributor to deliver a ready-made patch into my hands. I'd compile the patched Bash code myself and put it in place.

This is not a bug to fool around with. It has the potential to wreak havoc with your systems. Worse still, a smart attacker could just leave malware mines behind to steal data after the fact.

As Ellis said, "Do you have any evidence of system compromises? No. And unfortunately, this isn't 'No, we have evidence that there were no compromises;' rather, 'we don't have evidence that spans the lifetime of this vulnerability.' We doubt many people do — and this leaves system owners in the uncomfortable position of not knowing what, if any, compromises might have happened."

So patch this bug now or you'll regret it.

Sursa stire: aici