Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not a bash bug

paste.lisp.org

Post reply on HN
Print view View original

131–140 of 189 posts

Re: Not a bash bug

#131

Post by vidarh »

nailer wrote: post #39
scintill76 wrote: post #25

Earlier quoted context omitted.

AFAIK Apache itself isn't vulnerable, because it probably doesn't invoke a shell. CGI apps it invokes might, which is how the vulnerability is triggered.

My understanding is that Apache starts CGI apps in environments with variables for things like HTTP_USER_AGENT that are set by random people on the internet through Apache.

Yes, because that is what the CGI spec demands.

There is nothing inherently insecure in that: The environment is just a bunch of strings.

Whether or not it is insecure depends 100% on the CGI that gets executed. Which programs that is 100% down to the person configuring the website.

Apache does not even have a theoretical way to ensure those applications does not do anything stupid with the data no matter the method used to pass it.

You have the simple solution if you are concerned about environment variable passing of not trusting mod_cgi. Most people have not used it for years anyway, because of the performance impact.

Re: Not a bash bug

#132

Post by mzs »

userbinator wrote: post #103
rst wrote: post #83

Earlier quoted context omitted.

Plenty of other shells support backticks without the "export -f" magic. They must, as backticks are mandated POSIX behavior; few support "export -f" at all. (And at least one that did, the old Bell Labs post-v7 "Research Unix" shell, used only environment variables with embedded characters which couldn't easily be created by normal means, to avoid the risk of "magic processing" on things like TERM and HTTP_FOO.)

used only environment variables with embedded characters which couldn't easily be created by normal means SOMEVAR="`cat some_binary_file`"

No not like that, something more like this:

()SOMEVAR@%=...

You will get a parse error. There is little more than [a-zA-Z0-9_] you can use in identifiers (except bash adds a few more, grrrr). You can probably pull it of with /usr/bin/env though.

Re: Not a bash bug

#133

Post by vidarh »

claudius wrote: post #8
myhf wrote: post #5

> 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 controlling the data they pass to bash. It's absurd to think that a transport layer should be responsible for "validating" all possible contexts in which the data it transports could be used. How is apache supposed to know the difference between using a magic string and simply ment…

The point here is that Bash was not designed to receive untrusted user data in environment variables. On the other hand, Apache/dhclient was designed to receive untrusted data, but then handed that over to someone which did not expect untrusted data without validation. In other words, if Apache/dhclient wants to put things into environment variables, it absolutely should make sure to do this properly and indeed to ta…

Apache has no control over what application code it is that receives the evironment variables via mod_cgi, and most of the time it will not be bash, but indeed a special purpose application or script interpreter that is designed to receive untrusted user data in environment variables since that is what the CGI spec dictates.

That sometimes people opted to use bash as the script interpreter and/or that people sometimes shell out to bash from within other environment without sanitizing the environment they pass along, is not Apache's fault.

Re: Not a bash bug

#134

Post by kazinator »

This is completely wrong in numerous ways.

Firstly, the "security concern" is definitely a bug.

It is related to bugs in a feature; nobody is saying that that feature itself is a bug, though many are saying it's a "misfeature". So the idea that the feature itself is a bug isn't something that requires opposition.

The idea that it's the Apache people's fault somehow, because they didn't inspect the implementation of something that they rely on, is wrong.

> When reusing a component with missing specifications and lacking documentation, checking the source of the implementation should be standard procedure, but it has clearly not been done by Apache or DHCP developers.

Firstly, the CGI mechanism doesn't rely on Bash; it relies on the passage of environment variables.

Secondly, for the shell language, there is a specification: POSIX. Someone calling a shell implementation should be able to rely on the interface contract. Nowhere in POSIX is it documented that code from environment variables is to be executed by the shell.

Apache can run on systems that don't have Bash. A shell other than bash can be used for running a CGI shell script. You don't get the source code, necessarily; how can the Apache developers inspect the source code of a proprietary shell on a proprietary Unix?

Even if the Apache or DHCP developers were to (insanely) take responsibility for this flaw, the workarounds in their code would be Bash-specific hacks: basically they would have to parse anything that goes into an environment variable and validate that it doesn't have the syntax which exploits the Bash issue. That would clearly indicate that it's a Bash problem.

What also indicates that it's a Bash problem is the way it is being handled: fixes have been issued against Bash, not against other programs. The fire is where the smoke is, generally, and that's where you pour the water.

Lastly, please don't post diatribes to a code paste hosting service; it is not your soap box. Thanks!

Re: Not a bash bug

#135

Post by vidarh »

taylodl wrote: post #70
vidarh wrote: post #12

Earlier quoted context omitted.

Apache does not in general know whether or not data will be passed to bash. And they can't take into account all possible contexts, because that would involve reading the mind of all possible future users of the interfaces they provide, to make sure none of them decides to call out to programs that treats previously inert data as code.

How is this any different from SQL injection? Input from the world must be sanitized. All we're doing is increasing the scope of the word input - ALL input from the world must be sanitized.

Exactly, it isn't. And we don't make our web server software try to guess how to sanitize input in order to prevent SQL injection, because it can't: It does not have the context to, e.g. differentiate between SQL injection and someone talking about SQL injection on HN and giving an example.

Re: Not a bash bug

#136

Post by kcbanner »

scintill76 wrote: post #6
ahy1 wrote: post #2

> This feature is documented under the -f option of the export built-in command. The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature. This undocumented implementation detail is also a limitation on the use of regular environment variables, and should be…

Yeah, I hope I never have occasion to walk through an undocumented minefield, I mean collection of "features", designed by this person. I say this without animosity to bash devs. I think some blame can be shared. But putting it all on people you expect to understand under-documented behavior and "implementation details" in every possible version of every possible flavor of /bin/sh is madness.

I believe this just applies to bash, not sh?

Re: Not a bash bug

#137

Post by vidarh »

regularfry wrote: post #50
myhf wrote: post #5

> 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 controlling the data they pass to bash. It's absurd to think that a transport layer should be responsible for "validating" all possible contexts in which the data it transports could be used. How is apache supposed to know the difference between using a magic string and simply ment…

Basically what they're saying is that CGI should never have happened.

While that might have been great, the alternative is: People should not have used shells as CGI handlers, and people should (irrespective of CGI) sanitize any environments passed on when spawning other programs from their applications.

This latter is really something we should do irrespective of where the input is coming from. Even if the content comes from trusted sources, passing the environment unchanged to sub-processes means we risk all kinds of unintended consequences if an application developers decides to spawn a sub-process that exec's into some process that makes decisions on various variables.

It's a bit like letting our applications call functions with random junk in the argument list.

Re: Not a bash bug

#138

Post by areyousure »

Ogre wrote: post #130
clarry wrote: post #119

Earlier quoted context omitted.

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 platfor…

> So ruby and perl are specifically designed to be a handler of untrusted data? Perl actually is when used in taint mode. http://perldoc.perl.org/perlsec.html

Yes and no. You can still unintentionally call out to bash if you, say, protect your PATH:

  $ x='() { :;}; echo vulnerable'  perl -t -le'$ENV{PATH}="/bin";print `:;date`'
  vulnerable
  Sat Sep 27 10:51:12 PDT 2014

Re: Not a bash bug

#139

Post by vidarh »

masklinn wrote: post #124
sp332 wrote: post #61

Earlier quoted context omitted.

It's the job of the CGI program, which is the same code that would have responsibility for sanitizing environment variables before calling bash.

There's nothing for the CGI caller to sanitise, how could and why should it know how arbitrary programs are going to arbitrarily misinterpret what it forwards? The CGI script could be Python eval()'ing it or Ruby interpreting it as a local file to display or delete, and it's no business of the CGI caller that they do. All the CGI caller can and should do is forward correct data as defined by RFC 3875, the rest is not…

I think you're in violent agreement with the comment you responded to in this case (especially judging with what he's written elsewhere on this thread).

He's saying if Apache passes a request to mod_cgi, which spawns "someapp", it is not Apache, but "someapp" that should sanitize the environment before it calls bash.

(and of course if the developer/admin has chosen to write their script to be run by bash, that's their mistake)

Re: Not a bash bug

#140

Post by nitrogen »

scintill76 wrote: post #16
claudius wrote: post #8

Earlier quoted context omitted.

The point here is that Bash was not designed to receive untrusted user data in environment variables. On the other hand, Apache/dhclient was designed to receive untrusted data, but then handed that over to someone which did not expect untrusted data without validation. In other words, if Apache/dhclient wants to put things into environment variables, it absolutely should make sure to do this properly and indeed to ta…

So if I write a new shell called rash, that executes anything in an env var between, say, backticks, and install it as /bin/sh, it's Apache's job to neutralize backticks in untrusted data? I can agree with some of the things you say, but this seems to be the logical conclusion, and it's crazy. The most consistent moral I'm deriving here, is that shells are for executing arbitrary commands in a flexible environment, s…

Because of popen(), it's near impossible to know which binary programs might unwittingly invoke a shell.
Post reply on HN