3 ms·

Ahem. Every web server passes "unsanitized user input" to "Turing complete systems". You have a right to expect certain things from subsystems regardless of the

by _yosefk 12y ago

Ahem. Every web server passes "unsanitized user input" to "Turing complete systems". You have a right to expect certain things from subsystems regardless of their "Turning completeness". * A file system should store your bytes, though nothing prevents a file system written in C from executing, say, logged HTTP requests as commands. * A CGI script should sanitize form data, though nothing prevents a PHP script from blithely shoving unsanitized data into SQL queries. * And a shell should pass environment variables to subprocesses, though nothing prevents it from interpreting variable values (or names, or a combination of names, values and the time of day) as commands. As I said - I don't think it's a security bug in bash, just another one of endless misfeatures. It's about as crazy to interpret environment variable values as code because they have a special-cased form as it would be to interpret, say, file names as code, or certain byte sequences passed to the write() system call as code, etc.

quesera 12y ago
The point is that, when bash was written, there were few mechanisms for executing code as another user. There were servers/daemons, but they did not execute user code. Of course some people would pipe to shell in their .forward file and eventually get pwnt, but it was a freshman mistake, and the damage was isolated. Once you reach the point of executing a shell with an euid other than your own, it's not the shell's job to sanity check your actions. The web has changed the execution model thoroughly. And people now do lazy things based on their loose understanding of flexible execution models. This is neither a bug in bash, nor a bug in Apache, etc. It's an integration bug between two complex systems that were designed with zero-to-poor knowledge of each other.
- derekp7 12y ago
  I'm not quite so sure about that. One of the early examples I've seen of Unix use (I think Ken Thompson was actually in the video, from early 80's) showed using the various tools to process file data that got downloaded from somewhere else (where that data was supposedly created by another user). So if you had a script that did: cat downloaded_file.txt |\ while read inputline do #some processing #call another shell program done In this case, bash would still be vulnerable even without the Internet involved -- just processing a data file you got from Bob in Accounting.
  - saurik 12y ago
    Only if you not only set a variable to the contents of data from that file, but then also exported that variable to the environment: don't do that (why would you anyway? ;P).
saurik 12y ago
As I said: it is an uphill battle to make people understand that when this was all built, the idea of a webserver was still just a twinkle in someone's eye :/. To make the statement even more general: the idea that someone would even build a process other than "login" that would accept untrusted data from an unknown random user halfway around the world in the first place, much less pass it to a shell, was not something that really made sense: to run the shell with a custom environment, in the 80s, required control of the parent process, running at the same privilege level (as the same user) as the new shell (unless you ran "su" and went through "login", at which point your environment is reset) meaning if you wanted to run a command you could just do so without trickery. Regardless, thank you for demonstrating this conversational problem in a much more visceral way than I could have alone :(.
- _yosefk 12y ago
  A conversational problem indeed... I explicitly said, twice, that it's not a security bug. It's just a feature that makes as much sense as write() interpreting special byte sequences as commands. If such a write() call were exploited through Apache's logging of http requests, would you also defend it on the grounds of Unix predating the web? As to the article you linked to, I recall that it mentions that the feature in question is actually from the early 90s when it might well have become a security bug... though I still think it's beside the point.
  - saurik 12y ago
    You make this sound hypothetical, so let's make it concrete: if the person who designed terminal escape sequences told me that he finds the idea that he might have anticipated that someone would log arbitrary garbage sent by random users halfway around the world with no way to trace them or account them for their actions "quite humorous", I would still find it inappropriate to go on a ranty screed somehow trying to lay fault with their arguably-poor design decision after exclaiming their "quite humorous" back at them as a question or to use exasperated rhetorical decives like "ahem" while quite explicitly stating that they should have in fact anticipated this because clearly a shell will eventually be in the position of doing these things that again were not at the time being foreseen.

by _yosefk 12y ago

quesera 12y ago

The point is that, when bash was written, there were few mechanisms for executing code as another user. There were servers/daemons, but they did not execute user code. Of course some people would pipe to shell in their .forward file and eventually get pwnt, but it was a freshman mistake, and the damage was isolated. Once you reach the point of executing a shell with an euid other than your own, it's not the shell's job to sanity check your actions. The web has changed the execution model thoroughly. And people now do lazy things based on their loose understanding of flexible execution models. This is neither a bug in bash, nor a bug in Apache, etc. It's an integration bug between two complex systems that were designed with zero-to-poor knowledge of each other.

derekp7 12y ago
I'm not quite so sure about that. One of the early examples I've seen of Unix use (I think Ken Thompson was actually in the video, from early 80's) showed using the various tools to process file data that got downloaded from somewhere else (where that data was supposedly created by another user). So if you had a script that did: cat downloaded_file.txt |\ while read inputline do #some processing #call another shell program done In this case, bash would still be vulnerable even without the Internet involved -- just processing a data file you got from Bob in Accounting.
- saurik 12y ago
  Only if you not only set a variable to the contents of data from that file, but then also exported that variable to the environment: don't do that (why would you anyway? ;P).

saurik 12y ago

As I said: it is an uphill battle to make people understand that when this was all built, the idea of a webserver was still just a twinkle in someone's eye :/. To make the statement even more general: the idea that someone would even build a process other than "login" that would accept untrusted data from an unknown random user halfway around the world in the first place, much less pass it to a shell, was not something that really made sense: to run the shell with a custom environment, in the 80s, required control of the parent process, running at the same privilege level (as the same user) as the new shell (unless you ran "su" and went through "login", at which point your environment is reset) meaning if you wanted to run a command you could just do so without trickery. Regardless, thank you for demonstrating this conversational problem in a much more visceral way than I could have alone :(.

_yosefk 12y ago
A conversational problem indeed... I explicitly said, twice, that it's not a security bug. It's just a feature that makes as much sense as write() interpreting special byte sequences as commands. If such a write() call were exploited through Apache's logging of http requests, would you also defend it on the grounds of Unix predating the web? As to the article you linked to, I recall that it mentions that the feature in question is actually from the early 90s when it might well have become a security bug... though I still think it's beside the point.
- saurik 12y ago
  You make this sound hypothetical, so let's make it concrete: if the person who designed terminal escape sequences told me that he finds the idea that he might have anticipated that someone would log arbitrary garbage sent by random users halfway around the world with no way to trace them or account them for their actions "quite humorous", I would still find it inappropriate to go on a ranty screed somehow trying to lay fault with their arguably-poor design decision after exclaiming their "quite humorous" back at them as a question or to use exasperated rhetorical decives like "ahem" while quite explicitly stating that they should have in fact anticipated this because clearly a shell will eventually be in the position of doing these things that again were not at the time being foreseen.