Not a bash bug • Hacker News Board

Re: Not a bash bug

#111

Post by Confusion » Sat, Sep 27, 2014, 3:55 PM UTC

_yosefk wrote: post #55

saurik wrote: post #30

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…

"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,…

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.

Re: Not a bash bug

#112

Post by julie1 » Sat, Sep 27, 2014, 3:56 PM UTC

So an ENV is a dict string => string with this feature we have a dict that point to functions. Basically it is an object. It could even has been used for passing structured data with their own functional compiler. Or objects with stateless (lambda) functions/methods usable for parallel computing.

Oh fuck, this feature is a wonderfull feature in a controled environment for passing objects/code over a simple octet stream. With safe computer paradigm.

We could have done RPC easily with xinetd + and shell scripts. With PAM we could have even be able to use kerberos to control the security...

I could have done lots of things... I still can ...

Bash I still hate you for not documenting this, and more YOU Advanced Bash Scripting guide for being so awesome and missing that. ABS you failed me. http://www.tldp.org/LDP/abs/html/functions.html

Re: Not a bash bug

#113

Post by panzi » Sat, Sep 27, 2014, 3:56 PM UTC

I don't agree. bash is meant to be a sh replacement, compatible with sh. So any correct use of sh has to give the exact same result under bash. bash should only extend sh in a way where the bash script would be an error under sh.

bash might not be intended to be that way, but it is assumed by developers to be that way, which means it has to be that way (or it can never be used as system shell).

Re: Not a bash bug

#114

Post by putzdown » Sat, Sep 27, 2014, 3:58 PM UTC

False premise: "Unintentional failure is not a failure." Lack of intention for a failure certainly weakens the ethical culpability of the action, but it doesn't weaken the technical or pragmatic severity of the failure. What's the point in saying the bash failure isn't a bug. It's an unwanted behavior. What else is a bug?

Re: Not a bash bug

#115

Post by icebraining » Sat, Sep 27, 2014, 4:02 PM UTC

lmm wrote: post #104

icebraining wrote: post #87

Earlier quoted context omitted.

How, if the protocol in question - the environment variables - has no concept of functions? The matter is that Apache and the protocols (HTTP and environment vars) are just being used as a tunnel between the attacker and bash. They can't pass functions via another channel because they don't know what functions are . All they know is they're passing blobs of data - which any protocol would do, binary or not. Bash happ…

The problem is that Bash is using the same channel for two quite different things - values and functions. It's doing that because the channel is a string; if there were a proper protocol for passing environment to subprocesses, that protocol would make a distinction between the two.

if there were a proper protocol for passing environment to subprocesses, that protocol would make a distinction between the two.

TCP is a binary protocol, how does it distinguish between executable and plain text formats? Answer: it doesn't, because TCP doesn't know or care about that, that's left to the layers above to handle.

Likewise, environment variables don't know or care about "functions", that's a concept that doesn't enter into the protocol, since it's not a shell specific protocol. All it transmits are keys and values, which are generic blobs of data. That bash uses the protocol to transmit code mixed up with data is no more the protocol's fault than the fact that TCP was used to transmit those same functions on HTTP requests.

Re: Not a bash bug

#116

Post by wahsd » Sat, Sep 27, 2014, 4:04 PM UTC

"Security in internet software and protocols were often just not considered at all in that time..." I find that a rather perplexing issue with many, especially software based products and research. How do you, in early, usually time, effort, support, and resource constrained stages of a project or research discover and identify all dependencies and requirements to the best of your knowledge so that there is not a type of runaway train effect where momentum is gained and speed is accumulated but it is frequently overlooked that there are all kinds of things like security, anonymity, etc. that are not being considered even though they will invariably become monumentally important.

Take the internet today in general as a huge example of that issue; it was never developed with anonymity or privacy or security in mind and here ware are, horrified of even just the tip of the iceberg that was revealed through Manning and Snowden. If the early researchers and engineers had built the early technologies with fundamental, most basic human considerations in mind we might not be looking down the barrel of a dystopian dawn.

So my question is whether anyone is aware of a method, procedures, techniques, etc. to plan for such a paradox?

Re: Not a bash bug

#117

Post by timtadh » Sat, Sep 27, 2014, 4:05 PM UTC

I personally feel bad for Chet about this whole thing. For those of you (probably most of you) who do not know Chet has been maintaining Bash for free in his spare time for the last 25 years. He began working on it because he was not satisified with the shells available at that time:

    In 1989 or so, I was doing network services and server support for
    [Case Western Reserve] University (CWRU), and was not satisfied with
    the shells I had available for that work. [1]

I had the priviledge of hearing Chet speak about his experiences maintaining Bash.[2] From my perspective he has done a really great job over the years making software that many people love to use and abuse.

So while this is a really bad network security situation for the internet at large I think it is dubious to hold Chet or even Bash at particular fault. Rather, we are all at fault. We have been writing software that just shells out to Bash or sh or z-shell for years because it is convient. We could have easily have written our subprocess code in better ways but it was easy to use shells and we used them, even when we didn't really understand them.

[1] http://www.computerworld.com.au/article/222764/a-z_programmi...

[2] The venue was Link State a student run conference here at CWRU

Re: Not a bash bug

#118

Post by panzi » Sat, Sep 27, 2014, 4:08 PM UTC

asveikau wrote: post #102

cnvogel wrote: post #63

Earlier quoted context omitted.

There are two things to differentiate, in my oppinion. In most cases, the shell is just used to find programs in the PATH when a C programmer uses system(). And for that case, which is probably 99% of the time when /bin/sh is being invoked, it would make perfect sense to implement this with something that exhibits less attack surface. Taking the "dhcp-exploit" as an example (set a DHCP option on your server to "(){..…

> when a C programmer uses system() I said it in another thread but this is almost always a mistake. The execve family is much less ambiguous about what gets passed to the program. Using it avoids this type of bug by not putting the shell where it doesn't need to be.

And it's not limited to C. E.g. I would be in favor to remove os.system from Python (in favor of subprocess.call). The `-syntax (backtick-syntax) in Ruby is particularly evil. It's so convenient because it is so concise, but I guarantee you that it is the source of a lot of vulnerabilities. It should be removed ASAP. I think that's kind of a theme in Ruby: is it convenient? Then put it in. But I would have expected more from Python.

Re: Not a bash bug

#119

Post by clarry » Sat, Sep 27, 2014, 4:08 PM UTC

Confusion wrote: post #108

philh wrote: post #80

Earlier quoted context omitted.

> You should never call out to anything by passing untrusted user input directly. So if I call a CGI script with parameters foo=bar, what data should apache pass to the handler, if not something along the lines of the string "foo=bar"? When I pass the header "User-Agent: baz" and the handler asks for the user-agent, what should it be told if not "baz"? Environment variables are data, not code. When apache executes a…

The point of the OP is that if a program has chosen bash to be handler of untrusted user data, then the program has made the wrong choice, because bash is clearly (hindsight!, I'm not claiming I wouldn't have made the same choice) not designed or that purpose. A handler for untrusted user data should be a program specifically designed for that purpose, which should receive the data directly. Similarly, if a Ruby or P…

So ruby and perl are specifically designed to be a handler of untrusted data?

How do I know what other programs are designed for such a task? What's a "generic program"? At this day and age, it is expected that pretty much all software ought to be designed with security in mind (not that it always is). Because any piece of "generic software" (or just software) is otherwise going to be exploited. Especially on platform where double-clicking a file is the expected way to open it.

More importantly, the point we are making is that we're not expecting bash to "handle" anything. It gets some data. It's not supposed to do anything with it on its own. Period.

Re: Not a bash bug

#120

Post by pessimizer » Sat, Sep 27, 2014, 4:13 PM UTC

avar wrote: post #46

masklinn wrote: post #35

> Assumedly programs like apache filter out environment variables properly. But unfortunately, in the validation of input data, they fails to validate correctly input data because they don't expect that data starting with "() {" will be interpreted by their bash child processes. If there's a bug, it's not in bash, but in apache and the other internet facing programs that call bash without properly validating and cont…

Your comparison doesn't make any sense. It's an obvious requirement for a JSON parser that it be able to parse input from arbitrary sources, including malicious ones. It's not so obvious that a shell should have to deal with malicious environment variables, due to the reasons outlined in the original post.

'It's obvious' isn't an argument. It certainly didn't seem obvious about YAML for some people [ http://www.kalzumeus.com/2013/01/31/what-the-rails-security-... ] to exactly the same effect.

edit:

"A brief description: Ruby on Rails makes extensive use of a serialization format called YAML, most commonly (you might think) for reading e.g. configuration files on the server. The core insight behind the recent spat of Rails issues is that YAML deserialization is extraordinarily dangerous. YAML has a documented and 'obvious' feature to deserialize into arbitrary objects. Security researchers became aware in late December that just initializing well-crafted objects from well-chosen classes can cause arbitrary code to be executed, without requiring any particular cooperation from the victim application."

So what was 'obvious' then is the opposite of what is 'obvious' now.