"I would argue that the bash security concern is not a bug. It is clearly a feature. (...)" The default excuse of all programmers. :)
Not a bash bug
171–180 of 189 posts
Re: Not a bash bug
#172Earlier quoted context omitted.
subprocess.call is also vulnerable to this, though. It calls out to bash.
I believe you would need to explicitly pass shell=True for that though.
Nope, it's not necessary. Test it with a vulnerable CGI app and call:
subprocess.call(["date"])
Or if bash is not your default shell:
subprocess.call(["bash", "-c", "date"])
Re: Not a bash bug
#173Earlier quoted context omitted.
The point is that, when bash was written, there were few mechanisms for executing code as another user. There were servers/daemons, but they did not execute user code. Of course some people would pipe to shell in their .forward file and eventually get pwnt, but it was a freshman mistake, and the damage was isolated. Once you reach the point of executing a shell with an euid other than your own, it's not the shell's j…
I'm not quite so sure about that. One of the early examples I've seen of Unix use (I think Ken Thompson was actually in the video, from early 80's) showed using the various tools to process file data that got downloaded from somewhere else (where that data was supposedly created by another user). So if you had a script that did: cat downloaded_file.txt |\ while read inputline do #some processing #call another shell p…
Only if you not only set a variable to the contents of data from that file, but then also exported that variable to the environment: don't do that (why would you anyway? ;P).
Re: Not a bash bug
#174I 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 scrip…
And what sanitization should Apache be doing to all of the environment variables? A blacklist against "() {"? That syntax is specific to bash, bash's support for it is undocumented, and it can be in any environment variable. It's more than a bit arrogant of bash to have an undocumented claim on all environment variables.
Re: Not a bash bug
#175Earlier quoted context omitted.
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 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 in question is actually from the early 90s when it might well have become a security bug... though I still think it's beside the point.
Re: Not a bash bug
#176Earlier quoted context omitted.
Apache knows what data Apache passes it its own sub processes, which is the issue here. Nobody is expecting Apache to sanitise other apps, just itself.
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.
I think it depends on the situation, at least that is what I've gleaned from my reading of it
if you run a .php file and you have mod_php or the webserver has understanding of the concept of PHP and calls the binary directly, all nice and good
if you have a something.randomext or something without an extension at all, then... whelp
luckily there is a program that is dedicated to working out how to run random executable files, the shell (and it uses the shell-bang, or shbang for short), so in that situation, the call will be done though the shell
Re: Not a bash bug
#177Earlier quoted context omitted.
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-pr…
One thing I've learnt over the years: anything which relies on "people should..." as a basis is doomed.
Re: Not a bash bug
#178Earlier 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.
> "Don't use shell for data transmission." Shell != Environmental variables.
That's correct. Environment variables are implanted by the shell. Don't use environment variables for data transmission.
Re: Not a bash bug
#179Earlier quoted context omitted.
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…
Yes, the CGI spec is obviously broken. Clearing a environment ala Postfix or using a socket would have been the obvious fix in the 90s.
Re: Not a bash bug
#180Earlier quoted context omitted.
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…
1) Since the mid-90s Apache and similar http servers have offered fastcgi as a way of communicating with processes with sockets. So you can understand why hearing you single out apache to "use a more secure IPC like sockets" detracts from the main argument which I'd otherwise agree with. 2) I'd wager that the people who came up with CGI initially had expected that the process apache spawns would be anything but a she…
Re 4, I'm actually saying nearly everyone on Unix considered environment variables to be a problem before. Not sure why you got the opposite impression.
Generally agreed though, I'd love to see the shell actually store data from instructions too, but it would break a lot of things.