4 ms·

> Sorry if I'm picking on you too much Don’t worry. > By this logic, it's Apache's job to prevent SQL injections. Curiously, I’d call this an example for my

> Sorry if I'm picking on you too much Don’t worry. > By this logic, it's Apache's job to prevent SQL injections. Curiously, I’d call this an example for my position, not yours: It is not the job of the SQL server to prevent SQL injections, quite the contrary, it is the job of the calling application to ensure that the things it tells the SQL server to do are actually safe. Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. … Actually, you’re probably right – if I’m guessing correctly that all the "CGI" standard does is to say "These user-supplied values go into these environment variables", then it is not the job of Apache to sanitise them. It merely means that Bash is an unsuitable choice for an environment with untrusted environment variables, i.e. as a CGI script or even for use as /bin/sh if you cannot trust environment variables. It gets a bit messier with dhclient, because that explicitly calls a Bash script and hence definitely should know about the issues Bash might have with environment variables.

nknighthb 12y ago
There's no need to guess. The relevant RFC sections are easily located. http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-9 http://tools.ietf.org/html/rfc3875#section-9 HTTP header values have some limited formatting requirements[0], but are otherwise arbitrary. There is no general way for the server to know which values are safe and which are not. That would require the server to know how the script would respond to any particular input. If that were the case, the script would be superfluous, and the server could simply respond to the client with the result it already knows the script would return! [0] https://tools.ietf.org/html/rfc2616#section-4.2 https://tools.ietf.org/html/rfc2616#section-4.2
adekok 12y ago
> It is not the job of the SQL server to prevent SQL injections True. But perfectly valid SQL shouldn't cause the SQL server to be exploitable. And the application has no idea which SQL statements are exploitable. > Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. True. But the unsaid assumption is "safe from the point of Apache". Not "safe from the point of some unknown exploit". So it's reasonable for an application to sanitize what it passes to the shell, by dealing with known and documented issues. e.g. Don't pass "$FOO" in a string to system() and expect it to be treated as the literal "$FOO" string. It's unreasonable to expect that the application know everything about the attack surface of everything it uses. Maybe there's a bug in an SQL library which causes the application to crash when a SELECT statement contains the text "crashme". This text is valid SQL, and it is entirely unreasonable to expect that the application "sanitize" such text. In the same way, environment variables are strings. It's a bit surprising to discover that bash will execute code contained in random environment variables.
scintill76 12y ago
I see your point with the first bit. System A passes safely to System B, B passes safely to C, etc. The problem, as you note, is that in order to correctly implement the CGI standard, Apache must pass the problematic data. Even if it took care to see "I'm about to pass this to bash, which might do something stupid with it, so I'll fix that", it can't know that a non-bash CGI executable is going to pass it to bash somewhere down the line. I agree with your other conclusions. People will definitely be re-evaluating shells, CGI, and environment variables for at least a few months or so while this is fresh.

nknighthb 12y ago

There's no need to guess. The relevant RFC sections are easily located. http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-9 http://tools.ietf.org/html/rfc3875#section-9 HTTP header values have some limited formatting requirements[0], but are otherwise arbitrary. There is no general way for the server to know which values are safe and which are not. That would require the server to know how the script would respond to any particular input. If that were the case, the script would be superfluous, and the server could simply respond to the client with the result it already knows the script would return! [0] https://tools.ietf.org/html/rfc2616#section-4.2 https://tools.ietf.org/html/rfc2616#section-4.2

adekok 12y ago

> It is not the job of the SQL server to prevent SQL injections True. But perfectly valid SQL shouldn't cause the SQL server to be exploitable. And the application has no idea which SQL statements are exploitable. > Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. True. But the unsaid assumption is "safe from the point of Apache". Not "safe from the point of some unknown exploit". So it's reasonable for an application to sanitize what it passes to the shell, by dealing with known and documented issues. e.g. Don't pass "$FOO" in a string to system() and expect it to be treated as the literal "$FOO" string. It's unreasonable to expect that the application know everything about the attack surface of everything it uses. Maybe there's a bug in an SQL library which causes the application to crash when a SELECT statement contains the text "crashme". This text is valid SQL, and it is entirely unreasonable to expect that the application "sanitize" such text. In the same way, environment variables are strings. It's a bit surprising to discover that bash will execute code contained in random environment variables.

scintill76 12y ago

I see your point with the first bit. System A passes safely to System B, B passes safely to C, etc. The problem, as you note, is that in order to correctly implement the CGI standard, Apache must pass the problematic data. Even if it took care to see "I'm about to pass this to bash, which might do something stupid with it, so I'll fix that", it can't know that a non-bash CGI executable is going to pass it to bash somewhere down the line. I agree with your other conclusions. People will definitely be re-evaluating shells, CGI, and environment variables for at least a few months or so while this is fresh.