- Sep 26, 2014
0- by A2 Marketing Team
For anyone who doesn’t know, Shellshock is the name of a particularly nasty vulnerability in Bash, the standard shell for most Linux distributions (and other Unix-like systems.) As of press time, new vulnerabilities due to this bug are still being discovered. Some distributions have only released patches that fix part of the problem, and a vast number of Internet connected computers are unpatched and vulnerable. There’s bound to be some negative outcomes from a security problem like this, but let’s see if we can scrape out some positive results.
The first lesson to take from this problem is that no software, no matter how ubiquitous, is guaranteed free from vulnerabilities. The Shellshock bug in Bash has been there for a long time. It looks like over a decade. This isn’t a result of an overwrought, unmaintainable mess receiving a poorly reviewed patch like the Heartbleed bug in OpenSSL. This is code that has been there for a long time, and everyone from Google to Facebook to Apple has been using Bash and not found it. Don’t take for granted that because some program is standard and popular that it is safe. Because it isn’t. That means, don’t assume you can just stick with the version you have forever and not worry about updates down the road.
It also means, don’t trust software unnecessarily. Don’t believe that any piece of software is a locked door, and you can be sloppy behind it assuming nobody will ever get past it. In the case of Shellshock, most people probably didn’t even realize they were trusting Bash with their CGI setups, but they were. If you’re using CGI to execute your web application, you’re trusting Bash (or some other shell) to be free of vulnerabilities that would allow remote execution. It’s not just CGI, though; any PHP script that uses shell_exec could be vulnerable. Or an application written in another language which uses a form of shell_exec. Remember when your paranoid, security-minded friend told you not to use shell_exec in your applications? This kind of thing is why.
That’s the third and final lesson I want to mention right now. When the security community says that a programming practice is bad (such as shel_exec or eval), believe them. You may think you know what you’re doing, and you’d never allow your harmless use of shell_exec to cause a problem. But you’re wrong, and it’s not only up to you. We can all make mistakes, and we can all be the victim of others’ mistakes. You can reduce the target on your own back by avoiding patterns that are prone to vulnerability.
