Comment by saurik | Hacker News Reader

Comment by saurik | Hacker News Reader

The original author of bash (a friend of mine, which is why I have this context) has been being interviewed by various newspapers today regarding shellshock, and finds the idea that he might have anticipated the number of ways people integrated bash into various systems (such as with Apache allowing remote control over environment variables when running software in security domains designed to protect against unknown malicious users) quite humorous. Apparently, it has been an uphill battle to explain that this was all coded so long ago that even by the time he had already passed the project on to a new developer (after having maintained it for quite a while himself) the World Wide Web still wasn't a thing, and only maybe gopher (maybe) had been deployed: that this was even before the Morris worm happened...

> In an interview Thursday, Mr. Fox, the Bash inventor, joked that his first reaction to the Shellshock discovery was, “Aha, my plan worked.”

http://mobile.nytimes.com/2014/09/26/technology/security-exp...

"Quite humorous"?

* In Unix, shell scripts and shell subprocesses are everywhere, and are supposed to be everywhere.

* Environment variables are passed across subprocesses by default, you need to explicitly filter the environment to prevent that.

Therefore, if you write a shell, the reasonable assumption is that it's going to be integrated into pretty much all "systems"/programs running on a Unix box with this shell, and environment variables will travel from everywhere to everywhere.

Of course the feature isn't a "bash security bug"; it's just one of those endless poorly documented, weird special cases which together make up what we know as "Unix".

And the answer to anyone shooting themselves in the foot, whether it's one person or a billion, is "you should have read the documentation" - and now, apparently, "you should have read the source".

It's a good thing this kind of "design philosophy" is absent outside the field of computer programming. Generally the vendor should be the extremely diligent party, and the user is assumed to be reasonably naive - even if the user is a professional (think power tools, etc.) It is only programmers, for some reason, who think that it's perfectly fine to add whatever features they want to their code without much worrying about consequences, and leaving the worrying to the users.

Since the sub-process runs as the same user as the original process, it wasn't really considered a security problem. The problem is calling a sub-shell without sanitizing the environment first. It's really a bad idea to connect unsanitized user input to a turing-complete system of any kind.

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.

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.

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.

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).

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 :(.

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.

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.

It is impossible to sanitize your data if you don't know how the inband signalling works.

It wasn't foreseen that programs would fill (new) environment variables with (unsanitized) user data as a way to pass that data to subprocesses. I would argue that would indeed have been hard to foresee: there are better ways to pass data and better ways to set the requested subprocess configuration.

Did none of the Bash maintainers since then ever notice this feature?

I'm sure rsh sounded fine when it was written, but....

It is interesting that this feature is guarded by a parameter named priviledged_mode, then no_functions, then privmode, and also another parameter named read_but_dont_execute. So I would say that bash maintainers were aware in general of this feature. But it looks like they never realized that there was a problem there. (Probably they just counted on the guard to disable this feature in sensitive situations (the so called, "priviledged mode")).

Reply on news.ycombinator.com