Not a bash bug • Hacker News Board

Re: Not a bash bug

#181

Post by meelooo » Sun, Sep 28, 2014, 3:22 PM UTC

pessimizer wrote: post #110

meelooo wrote: post #31

Earlier quoted context omitted.

You are describing the problem exactly: it all too tempting to pass text around from user input to command line arguments without any way to validate the text data and assume it's ok because it's easy. It's exactly the same arguments that goes in between static and dynamic typing in programming languages: static typing ensures some sort of semantics is respected. If you pass text around, because it's easy and fast, m…

I can craft malicious binary data just as easily to execute a function if you execute binaries that begin with a few magic bytes when you're reading input into a buffer. You seem to be relying on some assumption that you have about human psychology for your security gain. Somehow people would never do that with a binary protocol, and text protocols make them more comfortable and trusting . At least they can read text…

no, I rely on the fact that any version of an "eval" function should just no exist and that any text based protocol encourages the existence of such functions that can execute whatever is thrown at them, just because it sounds so easy and a quick shortcut in API design.

Re: Not a bash bug

#182

Post by saurik » Sun, Sep 28, 2014, 11:54 PM UTC

_yosefk wrote: post #175

saurik wrote: post #155

Earlier quoted context omitted.

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

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…

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.

Re: Not a bash bug

#183

Post by cnvogel » Mon, Sep 29, 2014, 6:03 AM UTC

asveikau wrote: post #109

tokenizerrr wrote: post #105

Earlier quoted context omitted.

Did you read the next sentence? > 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.

I did. I did not find it explicit enough. There was no specific recommendation, for example. Moreover seeing the phrase "when a C programmer uses system()" is pretty jarring. There aren't enough warnings you can add to that to convey how much this gets misused and what a bad idea it usually is. To me, use of system() is very indicative that you need to find another C programmer. There are few other answers to complet…

Well... that's a pretty drastic reasoning, leaving aside all weighting of facts. Does it also apply to a Haskell programmer running System.Process? ;-)

The fact is: system() and all it's relatives (popen comes immediately to mind, there are doubtlessly 100 others) have been used, will be used, by 'incompetent' programmers[+] and as long as no other method is as widely established (and: even taught in introductory textbooks), we better provide a workaround that closes most of the holes.

[+] or just programmers weighting the merits of having a parser supporting variable and home-directory expansion, curtesy of /bin/sh -c right built in, which is completely adequate for many tasks. And yes, I know the limitations of it, and would not use it myself most of the time.

Re: Not a bash bug

#184

Post by erikpukinskis » Mon, Sep 29, 2014, 4:21 PM UTC

I don't understand this situation at all. Are people using bash as a secure jail and expecting it not to be able to arbitrarily execute code and access the user's complete environment?

I think the maintainer is right. Bash was never marketed as a secure sandbox and anyone who uses it as such is taking that risk on themselves.

Re: Not a bash bug

#185

Post by dllthomas » Mon, Sep 29, 2014, 9:01 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.

In principle, a distinguishing protocol could be embedded within the undistinguished one. If the actual environment variables were preceded with a sequence indicating the type of the contents in all cases, this would not be an issue.

Re: Not a bash bug

#186

Post by dllthomas » Mon, Sep 29, 2014, 9:09 PM UTC

My understanding was that using this "feature" would sometimes lead to a crash of the executable. That seems to me to be clearly just a bug.

Even absent that, contrary to the article, I think I'd still call this a bug in bash - but the crash (presuming I'm recalling correctly) makes this position absurd instead of just (IMO) incorrect.

Re: Not a bash bug

#187

Post by panzi » Tue, Sep 30, 2014, 1:04 AM UTC

meowface wrote: post #143

panzi wrote: post #118

Earlier quoted context omitted.

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.

Vulnerable to what? The the environment variable problem? I was talking about program argument parsing. os.system("ls %s" % foo) != subrocess.call(["ls",foo])

Re: Not a bash bug

#188

Post by panzi » Tue, Sep 30, 2014, 4:35 AM UTC

spc476 wrote: post #169

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.

Yes, it isn't that hard to use exec*() to execute a single program, but it gets rather messy if you want to execute a series of piped commands. Also another function to worry about is popen().

Look what I made you: https://github.com/panzi/pipes

Re: Not a bash bug

#189

Post by meowface » Wed, Oct 01, 2014, 3:41 AM UTC

panzi wrote: post #187

meowface wrote: post #143

Earlier quoted context omitted.

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

Vulnerable to what? The the environment variable problem? I was talking about program argument parsing. os.system("ls %s" % foo) != subrocess.call(["ls",foo])

Ah, I misunderstood then. I agree with you on that point. I assumed you were talking about "Shellshock".