Today’s news all over the place has to do with the nasty bash vulnerability that has been disclosed and now makes everybody go insane. But around this, there’s more buzz than actual fire. The problem I think is that there are a number of claims around this vulnerability that are true all by themselves, but become hysteria when mashed together. Tip of the hat to SANS that tried to calm down the situation as well.
Yes, the bug is nasty, and yes the bug can lead to remote code execution; but not all the servers in the world are vulnerable. First of all, not all the UNIX systems out there use bash at all: the BSDs don’t have bash installed by default, for instance, and both Debian and Ubuntu have been defaulting to dash for their default shell in years. This is important because the mere presence of bash does not make a system vulnerable. To be exploitable, on the server side, you need at least one of two things: a bash-based CGI script, or /bin/sh being bash. In the former case it becomes obvious: you pass down the CGI variables with the exploit and you have direct remote code execution. In the latter, things are a tad less obvious, and rely on the way system() is implemented in C and other languages: it invokes /bin/sh -c {thestring}.
Using system() is already a red flag for me in lots of server-side software: input sanitization is essential in that situation, as otherwise passing user-provided strings in a system() call makes it trivial to implement remote code execution, think of a software using system("convert %s %s-thumb.png") with an user provided string, and let the user provide ; rm -rf / ; as their input… can you see the problem? But with this particular bash bug, you don’t need user-supplied strings to be passed to system(), the mere call will cause the environment to be copied over and thus the code executed. But this relies on /bin/sh to be bash, which is not the case for BSDs, Debian, Ubuntu and a bunch of other situations. But this also requires for the user to be able to change the environment variable.
This does not mean that there is absolutely no risk for Debian or Ubuntu users (or even FreeBSD, but that’s a different problem): if you control an environment variable, and somehow the web application invokes (even indirectly) a bash script (through system() or otherwise), then you’re also vulnerable. This can be the case if the invoked script has #!/bin/bash explicitly in it. Funnily enough, this is how most clients are vulnerable to this problem: the ISC DHCP client dhclient uses a helper script called dhclient-script to set some special options it receives from the server; at least in the Debian/Ubuntu packages of it, the script uses #!/bin/bash explicitly, making those systems vulnerable even if their default shell is not bash.
But who seriously uses CGI nowadays in production? Turns out that a bunch of people using WordPress do, to run PHP — and I”m sure there are scripts using system(). If this is a nail on the coffin of something, my opinion is that it should be on the coffin of the self-hosting mantra that people still insist on.
On the other hand, the focus of the tech field right now is CGI running in small devices, like routers, TVs, and so on so forth. It is indeed the case that in the majority of those devices implement their web interfaces through CGI, because it’s simple and proven, and does not require complex web servers such as Apache. This is what scared plenty of tech people, but it’s a scare that has not been researched properly either. While it’s true that most of my small devices use CGI, I don’t think any of them uses bash. In the embedded world, the majority of the people out there wouldn’t go near bash with a 10’ pole: it’s slow, it’s big, and it’s clunky. If you’re building an embedded image, you probably have already busybox around, and you may as well use it as your shell. It also allows you to use the in-process version of most commands without requiring a full fork.
It’s easy to see how you go from A to Z here: “bash makes CGI vulnerable”, “nearly all embedded devices use CGI” become “bash makes nearly all embedded devices vulnerable”. But that’s not true, as SANS points out, it’s a minimal part of the devices that is actually vulnerable to this attack. Which does not mean the attack is irrelevant. It’s important, and it should tell us many things.
I’ll be writing again regarding “project health” and talking a bit more about bash as a project. In the mean time, make sure you update, don’t believe the first news of “all fixed” (as Tavis pointed out that the first fix was not thought-out properly) and make sure you don’t self-host the stuff you want to keep out of the cloud in a server you upgrade once an year.