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

151–160 of 189 posts

Re: Not a bash bug

#151

Post by nailer »

quesera wrote: post #84
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, and should have known they needed to. Well, there's nothing inherently dangerous about setting environment values. Yes, some have special meanings in special contexts but so could data piped over a socket. So your argument boils down to: Apache should have seen the special treatment of data in this context, and used another context instead. That's fine, but it doesn't address the r…

> So your argument boils down to: Apache should have seen the special treatment of data in this context, and used another context instead.

Yes, the behaviour of all Unix shells and their poor separation of data from instructions is well known in the 90s.

> There's no spec to say that data received from the "other" channel will not be interpreted or used unexpectedly.

That is true. However something specifically designed as a communications channel, such as a socket or FIFO, is generally better suited than something designed as a shell.

Re: Not a bash bug

#152

Post by nailer »

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…

Shell executes the contents of variables by design, and users use it everyday - ever had a PS1 with backticks or a subshell? If you don't wish for it to do so (which is reasonable), fine, but you will break compatibility and throw away that entire ecosystem of tools (which may also be reasonable).

Re: Not a bash bug

#153

Post by informatimago »

wahsd wrote: post #116

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

If you look at early RFCs, you will see that if they mention security considerations at all, it's often just to mention that they haven't been addressed at all.

Specifically, the literal string "Security issues are not discussed in this memo.' is found 568 times in the 3000 first RFCs. (6 times in the RFCs from 3000 to 5887).

When searchers were inventing the internet, they just put aside security considerations. In a way, security was enforced at the boundary, by universities controlling their teachers and students who could use it.

When the internet becomes a public network, where anybody can send packets on it, of course security considerations become a priority, but the protocols weren't designed for security. Like IPv6, we'd need to design a new set of protocols for this public internet, taking into account security considerations as a priority.

But given the speed with which IPv6 is adopted, you can guess with what readiness a new set of secure protocols will be adopted (you'd also have to be able to trust them, that no NSA or other backdoor is hardwired in those new protocols).

In short, this is not a simple situation and there is no simple solution.

Re: Not a bash bug

#154

Post by informatimago »

lutusp wrote: post #92

> I would argue that the bash security concern is not a bug. It is clearly a feature. Admittedly, a misguided and misimplemented feature, but still a feature .... The problem is that it was designed 25 years ago. Apache didn't exist yet for five years! The linked article's premise requires that the bug/feature be present when Bash was first written, not be the result of more recent changes, a a time when the risks we…

Yes, this part of the code is basically unchanged in all versions from the oldest I could get (1.14.7).

What made me look for it, was a suspicion that it was some backdoor added more recently. But apparently no, it's a feature that always existed in bash (granted, an ill-advised and ill-implemented undocumented feature, but still).

Re: Not a bash bug

#155

Post by saurik »

_yosefk wrote: post #67
sp332 wrote: post #59

Earlier quoted context omitted.

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

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

Re: Not a bash bug

#156

Post by clarry »

nailer wrote: post #150
clarry wrote: post #90

Earlier quoted context omitted.

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

Well, it's well known that being able to freely set certain environment variables is a disaster. That any variable regardless of its name should have such an effect is, however, news.

You can talk all you want about unrelated gotchas in shells & security, and that's missing the point.

Re: Not a bash bug

#157

Post by Crito »

nailer wrote: post #69
anon1385 wrote: post #51

Earlier quoted context omitted.

If you can't put data into variables then that makes what you can do with shell scripts quite limited. Your advice is really: don't use shell scripts any where near untrusted data. Tracking which data is trusted and which isn't across different processes in different languages across different systems is not a trivial task. So really the advice is: don't use shell scripts. That's sound advice, but not something Apach…

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.

> "Don't use shell for data transmission."

Shell != Environmental variables.

Re: Not a bash bug

#158

Post by nknighthb »

andy_ppp wrote: post #147
masklinn wrote: post #125

Earlier quoted context omitted.

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

Keep reading. Use of environment variables is specified for Unix. (And, actually, for all other systems which the RFC provides a specification, differing only in minor detail.)

http://tools.ietf.org/html/rfc3875#section-7.2

   For UNIX compatible operating systems, the following are defined:

   Meta-Variables
      Meta-variables are passed to the script in identically named
      environment variables.  These are accessed by the C library
      routine getenv() or variable environ.
This is how CGI works. This is how CGI has always worked. NCSA HTTPd was built on and for Unix, and was the origin of what we now call CGI. This is the interface to which CGI-compliant scripts and webservers have always adhered.

> I suppose the authors of bash know that most of the implementations of CGI do this

1) I don't know why you would suppose the authors of Bash would know how CGI works. Nothing about writing a shell implies knowledge of the intricacies of web technologies.

Certainly many of the people on HN so eagerly looking to blame either Bash or Apache don't seem to know how it works. If they did, they might have realized what quesera so astutely observed earlier today[0]:

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

2) I don't know when this particular Bash feature originated, but Bash as a whole pre-dates CGI by about five years.

> I still maintain that this sounds like a very insecure mechanism

I don't know of anyone who has looked at CGI and thought the use of environment variables was a good idea in the face of the 21st century's security landscape.

This mess was more than two decades in the making. It is the collision of two entirely unrelated courses plotted by two entirely unrelated parties, neither of whom could have been expected to know what the other was doing, and neither of whom could have foreseen how yet more unrelated parties would (in some cases unknowingly!) combine their works into a time bomb.

[0] https://news.ycombinator.com/item?id=8376914

Re: Not a bash bug

#159

Post by scintill76 »

nitrogen wrote: post #140
scintill76 wrote: post #16

Earlier quoted context omitted.

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.

popen() is documented as using the shell, so I wouldn't use it if I follow my moral of the story above. Maybe you're referring to the "shebang" (#!/bin/sh), whereby any executable, that you may have invoked without a shell, can signal that a shell should interpret it?

I guess you have to strip down the environment to only the things you need to know. That's unfortunate, because the nice thing about the environment is that it's inherited, so the user can put in configuration that's needed 3 or 4 steps down the line from where it originated.

Re: Not a bash bug

#160

Post by scintill76 »

danielweber wrote: post #94
scintill76 wrote: post #16

Earlier quoted context omitted.

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…

install it as /bin/sh, At first glance, I think that's your problem. Fundamentally, though, you can't always point to "it's this one component that is broken." There is the classic example that was used to criticize Authenticode, which was Microsoft's way of dealing with mobile code back in the 1990's. It said "all the code is signed, so if something breaks, you know who to sue." Well, imagine two programs: 1. One of…

It does indeed seem wrong to put magical behavior into /bin/sh, but that's exactly what's going on in this bug. bash is often installed as /bin/sh and is doing extra, non-standard, sparsely-documented behavior. I don't know that it really violates POSIX et al, but it definitely goes on the list of factors at fault.

And yes, I agree it's difficult to assign blame.

Post reply on HN