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

141–150 of 189 posts

Re: Not a bash bug

#141

Post by skybrian »

aidenn0 wrote: post #123

It took a lot of discussions with pjb on irc for me to decide he is not actually a troll. His is very literal. The part where assigning a particular variable to any environment variable causes arbitrary code execution is a bug. The part where you can define functions by setting environment variables is a feature. It would be far better if the variable names needed a prefix (e.g. BASH_FN_foo='() {...}')., but even wit…

If an environmental variable is like a file, this bug is like automatically executing code stored anywhere in the filesystem if the file happens to certain a magic number. Using a prefix (if documented) is like looking in a certain directory. It should have been obvious that scanning ALL environment variables is a bad idea, if not for security than for correctness, because interpreting data belonging to another program is likely to cause unpredictable behavior.

Re: Not a bash bug

#142

Post by nitrogen »

anon1385 wrote: post #17
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…

You say dhclient should take into account all possible contexts before passing data to bash, but it's not easy to know what data shells will parse as code and what they won't[1]. If we have to sanitise data before passing it to shells then the only sane conclusion is to never pass untrusted data to shell scripts. I certainly don't trust myself to know the full range of features in all shells that might suddenly turn…

Unfortunately the specs for system() and popen() require the use of shells. It was known that you had to escape arguments and control the names of environment variables, but it's entirely bizarre to expect people to know before shellshock that the values of otherwise completely safe and sanitized variables might still be interpreted by bash as code.

We shouldn't have to give up popen() just because bash was designed insecurely; we should fix or replace bash.

Re: Not a bash bug

#143

Post by meowface »

panzi wrote: post #118
asveikau wrote: post #102

Earlier quoted context omitted.

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

subprocess.call is also vulnerable to this, though. It calls out to bash.

Re: Not a bash bug

#144

Post by whoisthemachine »

I agree with this. Whenever something is interacting directly with a shell (or any other program that can execute passed in code dynamically for that matter), it should sanitize the input as to be certain nothing gets executed later, unless it wants something to be executed later.

Whether that be Apache (if it's passing data or commands directly to shell that contain data from the external environment) or a CGI script it is calling, whatever happens to be interacting directly with the shell should be sanitizing its inputs.

Re: Not a bash bug

#145

Post by informatimago »

mcguire wrote: post #100
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…

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

Re: Not a bash bug

#146

Post by informatimago »

anon1385 wrote: post #96
nailer wrote: post #69

Earlier quoted context omitted.

Yes. Don't use shell for data transmission. Use a socket. Apache had that choice, knew bash was insecure (as everyone did in the 90s, that's why across can't be setuid), and didn't exercise the right option.

>Yes. Don't use shell for data transmission. That isn't sufficient. Your argument means you can't use shell for anything . If you can't trust it not to execute the contents of a variable, then it should never be used other than on isolated systems where the data it processes comes from completely controlled sources. Using the shell becomes the equivalent of using the gets() function in C. That means a complete redesi…

Granted, this export -f feature of bash needs a different, safe, implementation.

But otherwise, in the context of the internet of today, yes, we'd need a completely different operating system (perhaps something based on capabilities). Unix indeed doesn't seem to be good enough for a safe internet.

If we could say that there are N bugs, and with openssh and this bash bug, we only need to correct N-2 bugs and we'll be fine, then perhaps we could keep unix (and similar systems).

But it just looks like it's more a systemic problem (indeed not specifically an apache bug, or a X or Y bug, but bugs emerging from the interaction between two or more components in the unix ecosystem), therefore if we don't change the fundamentals, we cannot exclude that we will keep introducing and discovering this kind of bugs again and again.

Re: Not a bash bug

#147

Post by andy_ppp »

masklinn wrote: post #125
andy_ppp wrote: post #43

Earlier quoted context omitted.

The analogy is very weak, SQL injection should be prevented in your application. Does Apache need to set global environment variables, it seems pretty extreme that it just takes all the user input and makes it available to the underlying shell, there will be a whole class of bad stuff that comes from this!

> Does Apache need to set global environment variables Apache? No. mod_cgi? Yeah, because that's its fucking job because that's how CGI works http://tools.ietf.org/html/rfc3875

Er... Well it's one way of it working, from the spec:

  'meta-variable'
  A named parameter which carries information from the server to the
  script.  It is not necessarily a variable in the operating
  system's environment, although that is the most common
  implementation.
I suppose the authors of bash know that most of the implementations of CGI do this so they should be preventing bugs like this. Thanks for your clarification. I still maintain that this sounds like a very insecure mechanism for passing information from Apache to your application.

Re: Not a bash bug

#148

Post by nailer »

csirac2 wrote: post #76
nailer wrote: post #65

Earlier quoted context omitted.

Unix domain sockets existed in the 90s and would have done the job adequately without evaling anything in transit. Apache transmitting data created by random people to CGI processes using environment variables is most definitely Apaches fault. It was a dumb idea in the 90s and it's a dumb idea now.

There's a lot of Apache hate here but I have to wonder if you've actually used it. Anyone stuck running cgi stuff with apache invariably goes to fastcgi or mod_fcgid for performance reasons, which already uses a unix domain socket. That shellshock exploits will still be possible in this configuration is once again, not Apache's problem.

Pointing out that people from the internet shouldn't be able to set shell variables isn't 'hate' - it's basic security and knowledge that alternative, more secure transport systems exist.

Saying that Apache (and other apps) passing data from random people on the internet to a known insecure environment like a shell, that was known to be insecure in the 90s, is 'not Apache's problem' doesn't actually absolve Apache of responsibility for its own programming.

Re: Not a bash bug

#149

Post by nailer »

vidarh wrote: post #128
nailer wrote: post #71

Earlier quoted context omitted.

Nowhere. Apache should have used a socket rather than the shell (which effectively evaluates data as instructions). People knew shell was insecure in the 90s, and there were malicious users back then too. I think environment variables were used either due to naivity or an ultimately mistaken concept of simplicity. Sunning up the entire thread: Apache should have used a socket, and should have known they needed to.

Apache doesn't have the option of using a socket for implementing the CGI spec. The spec specifies environment variables. Apache could refuse to provide a mod_cgi, in which case it would never have gained the position it did, and some other server with support for CGI would have.

> The spec specifies environment variables.

If that's true, then the spec has been obviously, fundamentally broken for it's entire existence.

Re: Not a bash bug

#150

Post by nailer »

clarry wrote: post #90
nailer wrote: post #71

Earlier quoted context omitted.

Nowhere. Apache should have used a socket rather than the shell (which effectively evaluates data as instructions). People knew shell was insecure in the 90s, and there were malicious users back then too. I think environment variables were used either due to naivity or an ultimately mistaken concept of simplicity. Sunning up the entire thread: Apache should have used a socket, and should have known they needed to.

> Apache should have used a socket rather than the shell (which effectively evaluates data as instructions). But the shell shouldn't evaluate data as instructions. This is the bug! Apache could have used a socket and I could write a buggy endpoint which evaluates data read from that socket as instructions. Tada, same problem, same bug.

All Unix shells don't really separate data from instructions. Your PS1, for example, can contain commands in backticks and subshells, it's expected to be able to do so.

Shells are insecure. You could replace them with something compatible but insecure, but they wouldn't be a POSIX shell anymore. Hence the well known SetUID blocking on shell scripts, hence not letting random people on the internet set shell variables.

Post reply on HN