By now you may have heard about a new bug found in the Bash shell. And unless you’re a programmer or security expert, you’re probably wondering if you should really worry. The short answer is: Don’t panic, but you should definitely learn more about it, because you may be in contact with vulnerable devices.
This bug, baptized “Shellshock” by Security Researchers, affects the Unix command shell “Bash,” which happens to be one of the most common applications in those systems. That includes any machine running Mac OS X or Linux.
A very simple and straightforward explanation of this major new security issue. The OSNews servers were updated yesterday.
Important to note that this isn’t totally fixed yet, there’s a new NCAS for Bash – https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
Yup, there was a new bash update (at least on Debian and Arch) this morning (09/26). Thom: you should update the OSNews servers once again
Yeah, both RedHat and Debian have updates today.
I’ve got to say– It’s at times like this when I really appreciate mcollective. One command, and 143 servers were patched 2 minutes later.
Try that on Windows.
So can we now all admit that “many eyes” is a myth? After all there isn’t a single piece of code in Linux that has had more “eyes” on it than bash yet here we are.
For “many eyes” to have worked those eyes had 1.- had to have the skill level to spot low level problems and bad code (for why this is a problem see the obfuscated C contest), 2.- Have the years of exp and again SKILL to be able to follow the code all the way up the tree and figure out (as well as code audit) all the code it interacts with (since bugs in one can easily make an other a threat) and finally 3.- Have the time and the desire to not only audit all this code but do so every few months when a new version comes out, because what was safe in version foo may not be thanks to changes upstream in foo+1.
I’m sorry but many eyes is a myth, its as much of a myth as saying “just fork it!” is total bullshit, because the eyes qualified to do that work aren’t wasting time debugging FOSS, they are making 6 figures and nobody is gonna fork it when they can simply go to Windows or OSX and vote with their wallets.
At the end of the day having source gives you ONE advantage and one advantage ONLY, and that is IF the devs abandon a piece of software and IF you can build up enough volunteers who care THEN you can keep the abandonware going, see KDE Classic…that’s it, that is all having source gives you. And while I can see some finding that appealing when you jump from that to “many eyes” and “just fork it!” you have left reality and entered fantasy land, because IRL that just isn’t gonna happen for anything bigger than say a text editor or compiler.
Not sure why you’re using my heads up as a springboard for your dislike of open source software.
The only thing I want to say in reply is that patches arrive and are pushed to repos very quickly after bugs are found. The benefits of this when all applications are in a single/small number of repos should be obvious.
Oh I just looove how anybody that doesn’t slurp the koolaid is “hating on opensource” no matter how fricking delusional that koolaid is!
Now I want you to explain to all here how EXACTLY pointing out a statement, with ZERO basis in fact or evidence to back it up BTW, like “many eyes” is obviously a myth is suddenly a “dislike for open source”. Does this mean I have to believe every.single. thing. that has EVER been stated by someone that is a self proclaimed open source advocate?
For the record I follow the late great Carl Sagan in the “Extraordinary claims require extraordinary evidence” camp yet certain groups seem to think they can make extraordinary claims like “many eyes” and “just fork it” and we are supposed to accept these without ANY evidence at all? I’m sorry but I call out bullshit when Apple does it, I call out bullshit when MSFT does it and I’m damned well gonna call bullshit when Linux does the same crap!
And this is exactly what you were hoping for… your reply had no relevance to the OP but you used it to gain visibility.
That, along with your mocking, provocative style of writing says that you’re not interested in discourse but only arguement.
Mmm one fallacy spotted and then replaced with another. It is obvious that many eyes will not inevitably lead to problems being solved. Let me use Science as an analogy (and I believe and appropriate analogy, as the peer review system and open source systems are quite analogous). Could we reasonably argue that science is a failed project because it took several hundred years to spot the problems in Newtonian mechanics, even though there were many eyes working, not only in science, but even in physics. Many of the issues you bring up in paragraph 2 are exactly comparable to the situation in science – Do you have the skill, ability, interest etc to be able to critique Newonian mechanics etc.
I would argue that science is not a failed project (a view not universally shared I admit) and the same is true for Open source in computing. Mistakes are made in both peer reviewed science and open source, there is a system for resolving them, for those with the time, ability and interest. This is not an instant fix, mistakes occur and may take time to resolve.
I not sure what the 3rd and 4th paragraph rant was about, certainly if you wish to use Windows or OSX feel free, but lets not pretend that Opensource is not significantly important. In many areas of computing it is dominant and many projects are bigger than simple text editors. Forking projects pointlessly, is pointless – forking projects mistakenly, is mistaken, however, projects may come to a point where they change direction and forking is inevitable, in the same way that any research project may diverge from another.
I think it would also be a fallacy to believe that because open source and close source projects have bugs they are equivalent, it is possible for one to be more prone to bugs and less able to respond to them, than the other. There is good reason to believe that the “many eyes†opensource approach is the better approach and that is not a fallacy.
I though UNIX was above all security issues.
Windows and Java users are getting their popcorns as bash exploits keep popping up as mushrooms.
No system is secure, if it gets hackers attention.
Edited 2014-09-26 07:03 UTC
Above all security issues ? Whatever gave you that idea ?
All software has bugs.
What I like about the way Open Source works, the patch was made available ASAP, and the information was made public. There are currently a couple of 0-days for certain JREs and another bunch for Windows exploits going high on the black market. They will never be “found” or released as public information. But if you’re lucky you might get an update… maybe… someday perhaps.
For some people 5 years might be fast, I guess.
http://threatpost.com/five-year-old-security-vulnerability-patched-…
And how many Windows or Mac OS X bugs have taken longer to fix?
http://www.computerworld.com/article/2523045/malware-vulnerabilitie…
For some people, 17 years might be fast, I guess.
This is not to mention how many bugs in Windows you will never know exist that has been around for much longer.
Obscurity is adequate security for some people, I guess.
MS found out about that bug 7 months before that article, not 17 years. I bet every OS has bugs that are that old, not discovered, sitting there waiting to be exploited.
Nice try though.
Apparently this bash bug has been there since 1989.
You’re not under the impression every Linux bug and security flaw is known or public are you? Also, by what logic have you arrived at the idea there’s a bunch of Windows exploits for sale in some black market somewhere, but those exploits will never be found or revealed publicly..but someday there might be an update for them?
It’s funny when people try to convince you Linux is secure by claiming Windows isn’t.
Bash was released in 89, the bug seams to appear in 94, version 1.14.0.
That might be true, but this is not about how long it was there, but what the reaction was after discovery. Once discovered, it was swiftly disclosed and patches made available.
Bash exploits keep popping up as mushrooms? What do Windows and Java exploits popping up as? Popcorns?
So Linux users are allowed to point and laugh at Windows when a new exploit is revealed, but Windows users are allowed to do the same when it’s a Linux exploit? I guess I shouldn’t be surprised… A lot of Linux users are too easily butthurt when their `precious` is tainted. And that’s coming from a Linux user.
Edited 2014-09-26 15:23 UTC
I’ll assume you mean “not allowed” for that second one.
How does my comment magically disallow people laughing at Linux? What is with arseholes like you who keep saying comments on the internet somehow prevents people from having their own opinion or their own laugh? Hint: IT DOESN’T.
He makes a joke. I make a counter-joke**. Apparently counter-jokes aren’t allowed*. Talk about butthurt.
* ie, if we accept your premise that a counter-response to a comment on the internet magically constitutes a no-talkback rule. Other people, like me, who aren’t so sensitive will just post a counter-counter-response if we want, because we understand that it is within our powers to do so. Here’s a hint: the fact that he was able to make a comment in the first place and not get banned for it implicitly means he is allowed, and that is not changed by the fact that someone posted a reply.
** And apparently we also aren’t allowed* to point out, through a joke, a relevant fact that bash shell exploits empirically do not pop up as often*** as Windows and Java exploits. Through some magical maths, the fact of having a security bug means from now to forever, both software are equally unsafe and it doesn’t matter the number, frequency and severity over time.
*** Don’t blame me for the unfair comparison of bash to Windows and Java, since as we all know, bash is not the same class of software as Windows or Java or a platform in general. I only follow the lead of the person I reply to.
Yes, I meant to type “not allowed”. This place is quick to strip you of the ability to edit/fix your typos though so not much I can do about it now.
Your 4 paragraph rant/reply is all well and good but unfortunately it’s not based on anything I said or implied. It remains funny to me that certain people and certain groups lose their shit the second they get a taste of their own medicine. It’s a simple observation which you helped reinforce.
It was based on the fact that you claimed my response magically constituted a no-talkback rule. You even admit you meant to write “not allowed”.
I did not bother responding to the rest of your comment because it all hinged on your oversensitivity to people having a counter response.
As for “lose their shit”… well I guess it’s just easier to paint other people with that so you don’t have to deal with the fact that you completely misread the intent.
He made a joke. I made a counter-joke. You overreacted and talk about “lose their shit” over jokes.
I made no such claim in any way, shape, or form. Are you hoping you can blatantly lie and nobody will notice?
What does a simple typo have to do with anything? You must feel pretty defensive to try reaching that far, attempting to make something out of completely nothing.
You’re exactly the type of person I’m describing in my last couple posts. Thanks for not trying to hide it. Please, by all means, continue to over-react. It only continues to reinforce my observation.
I generally enjoy talking with both of you on here, so when I say this I mean it in a friendly way. But it still needs to be said:
Both of you please grow up and get over it! Bugs happen, no matter the platform, and any sense of “joking” about it gets lost in the serious deconstruction you are each doing on the other’s comments. Honestly, the point of the discussion was left behind several comments ago, when it devolved into one-upping each other over a misplaced word or letter.
Yes, this is getting very funny.
http://arstechnica.com/security/2014/09/still-more-vulnerabilities-…
Edited 2014-09-27 06:18 UTC
OSX users are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services which is a very unusual thing to do. Apple says a fix for advanced UNIX users is coming soon.
Heh
It’s not really Unix though, no matter how much those “security firms” want you to think so.
It’s just bash and a lot of Unices don’t use bash as the default shell.
There’s “Linux mainstream” with many systems including bash as a default shell (both as scripting shell / “subshell” and as interactive shell). There are also Android versions including bash. On the other hand, Mac OS X, different Android versions, the BSDs and Solaris aren’t affected. Summarizing all of them under the “umbrella of UNIX” and saying they’re vulnerable would definitely be wrong. Not all UNIX derivates and lookalike even include bash by default. And not every /bin/sh is bash.
Still it is an interesting security aspect to address and to discuss. Unlike proprietary operating systems, the patches have been made available quickly, and the information about the vulnerability, as well as vulnerability tests and exploit demonstrations, have been published in public. This is something not common regarding the continuous stream of security problems related to Java, “Flash”, or “Windows”…
Why do you put Flash and Windows inside “”?
Yeah, that’s a pretty general way of thinking by the general public but what in reality Open Source projects are a) much, much more transparent about security issues both good and bad and b) exploits are typically fixed in a relatively short time frame. Corporations like Microsoft and Oracle often take weeks if not years to fix serious problems and while not trying to diminish how serious this Shellshock exploit actually is when I first started seeing notices spreading online about this the other day there were already patches available for most distros.
So good that Bash keeps getting exploited.
http://arstechnica.com/security/2014/09/still-more-vulnerabilities-…
So Bash is crap, what else is new?
Bash should really only be used for an interactive shell, everything else should use ash or pdksh or something that isn’t retarded.
I don’t know where to start. define UNIX.
Bash is a standard application that ships with many unix/linux flavors. All software has bugs but with a project as popular as bash, they have to fix those bugs the minute they are discovered.
It’s not like Apple or the Linux kernel team or redhat or whoever are the sole possible contributors to the software they ship. It is not their fault this bug is there.
Why is it that appliances like modems, routers, games boxes, media centres etc are rarely updated after release?
Given the software they use, and the frequent fixes, is expect them to get rolling updates?
Is the answer that ‘fire and forget’ us cheaper?
Browser: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 5 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.117 Mobile Safari/537.36
Cheaper, but they also run simpler systems, with fewer things that can break. For instance, your router probably runs busybox instead of bash.
indeed, and busybox uses ash instead of bash as its default shell. For exemple, iirc, pfsense, dd-wrt, openwrt and such don’t use bash as their default shell.
Whilst this is a serious bug no doubt, the only way it could be accessed externally from a router is if someone had an unencrypted telnet port running with no authentication required, or something along those lines. In that instance, they have bigger problems than a little bash bug in my opinion – a port exposed on the WAN interface with which someone can access bash directly. Not good, but otherwise I can’t see the fuss here.
Edited 2014-09-26 08:03 UTC
Another option is if they have the router administration Web UI open on the WAN port, and the webserver allows CGI shell scripts.
But then again, leaving a web admin interface open on the WAN is already a bad idea, security wise.
Good point, but like you say, a nightmare anyway security wise.
The CGI scripts have to be written in bash or another language that spawns a bash shell.
They can’t exploit this without a bash script already being present in the cgi-bin directory.
If they have already gained access to put a script in cgi-bin you have bigger problems.
They are making this into a bigger deal than it really is.
snorkel2,
It’s not so simple. This was very poorly explained by the article, but it is a much bigger deal than some people realize.
Consider these two tests
The dash shell runs as expected.
However do to the bug in bash shell, it actually executes the contents of the ‘x’ environment variable. Note that it’s often the case for remote users to have write access to the contents of environment variables by design (ie HTTP_USER_AGENT).
Before we write this off as an isolated problem to those who intentionally exposed bash shell via a CGI-like mechanism, we should be aware that libc can internally call upon the bash shell.
In gnu libc, system() -> __libc_system() -> do_system(). This executes /bin/sh, which on some distros points to bash. Therefor anything calling the stdlib “system()” call is potentially exposing this vulnerability!!
Does PHP use it? Apache? nginx? Mysql? imagemagik? postfix? exim? etc… Mind you I’m not asserting that any of these are necessarily vulnerable, only that they could be by inadvertently calling “system()” while using environment variables crafted by the attacker. Obviously the bug isn’t in any of these programs, however the problem is they can potentially expose it by spawning innocent helper processes using the “system()” call.
That’s exactly what he said.
If you don’t have a CGI script that’s written in bash or have some PHP / Python / Ruby / whatever script that is spawning a bash shell then it’s a not a problem. An external attacker isn’t going to magically be able to spawn a bash shell.
The big ones are people who are using a cPanel / Plex like setup that don’t know what’s under the hood, but there is something there that is spawning a bash shell in a known location. Custom scripts, although still vulnerable, will take a bit more time for the hackers to find.
note: not saying cPanel / Plex are vulnerable, just using them as examples.
“If you don’t have a CGI script that’s written in bash or have some PHP / Python / Ruby / whatever script that is spawning a bash shell then it’s a not a problem. An external attacker isn’t going to magically be able to spawn a bash shell. ”
exactly and you can’t magically set environment vars on a server if you don’t have some sort of access via a logon or some other exploit.
rhavenn,
That’s honestly not the way I read snorkel2’s post, particularly this part “They can’t exploit this without a bash script already being present in the cgi-bin directory.” But regardless of that, I still think it was worth mentioning because the attack vector via “system()” may not be immediately obvious to everyone.
It is that simple.
If you have a apache server and no CGI’s that are written in bash, who does that anymore anyway? and you don’t spawn a shell your pretty safe.
For example I have bash on my web server and I have several CGI’s in python and I know for a fact they don’t call popen or use a shell. I think I would be pretty safe even without a updated bash.
Also how would they set these environment vars? wouldn’t they need access to the system to set them in the first place? Seems to me they would need to find a exploit to set the vars and if they where able to do that why would they need to use the bash bug?
Edited 2014-09-26 20:02 UTC
snorkel2,
I think your misunderstanding this attack vector. You don’t have to *explicitly* invoke bash to be vulnerable, some systems *implicitly* invoke it through libc’s “system()” call. You can look at glibc’s source code yourself, I took a look myself this morning, my earlier post gives some pointers at which functions to look at.
We can not automatically assume we are safe simply because we haven’t used any bash scripts. Do any of your daemons and libraries avoid the “system()” call? Maybe, maybe not. That’s my point; you and I cannot make blanket assertions that a vulnerability does not exist until we’ve ruled out this attack vector in all our code.
As an example, the HTTP_USER_AGENT I mentioned earlier is intentionally passed in via Apache. Other daemons such as sendmail may pass other sender-controlled environment variables to helper processes such as spamassassin (for example), if that process uses “system()”, then the vulnerability could exist there. Again, I’m not asserting these are vulnerable, only that we explicitly have to check them out to find out.
The problem is that Bash parses all environment variables, instead of just passing them on, and the bugs are in Bash’ parser.
PHP yes, Apache, nginx and mysql I’d wager not. Imagemagick, postfix and exim (really dude? Exim?? :-P) probably does but for postfix and exim it might not be a problem unless they export tainted data as environment variables.
It could also be exploited if you have a web app or similar that runs something with a bash shell. Of course, you should never run anything with a shell and instead use things like exec but that’s never stopped people from doing it.
You should never underestimate the stupidity of a Linux user much the same as with a Windows user, or any other kind of user who is reckless and/or messes with stuff just because.
I have been cursing a lot at Debian for using dash instead of bash as the default shell, but it has help get rid of a lot of bashisms, and now saves all Debian systems from this bug..
Okay, Debian. I was wrong and you were right. I am sorry for cursing at you.
Edited 2014-09-26 09:40 UTC
While Debian does use dash as the default shell, it should be noted that Debian’s implementation of dhclient-script explicitly uses /bin/bash ( https://security.stackexchange.com/a/68159 ), and therefore while unpatched Debian systems are unlikely to be susceptible to the CGI attack vector (the CGI could still explicitly call /bin/bash, but that’s much less likely than a call to /bin/sh), they are still susceptible to an attack from a rogue DHCP server, so they should not be on open wifi.
No, not really. If you have bash installed, you should update it. Granted, if your system default is dash, you’re better protected, but not necessarily immune.
Easier to update, really.
it doesn’t, i just had to update all my debian servers.
The command in the article linked worked on two servers that hadn’t been updated yet and were fixed after updates.
Edited 2014-09-30 00:39 UTC
OSNews servers are updated?? With the 1998 design I thought no one even knew where they were.
😉
Edited 2014-09-26 10:07 UTC
Set your browser user-agent to something like this:
(){:;}; ping -c 5 <your ip>
If you receive a ping reply from the site you are browsing, it means it’s vulnerable.
Edited 2014-09-26 10:43 UTC
That’s not how it works, that’s not how any of it works.
Sure, if the web server for some reason would have CGI scripts written in bash it would work but if you use bash for your CGI scripts you’re already doing things very wrong and you’re probably already screwed regardless of shellshock. It could also work if you have a web app that runs cli programs in a shell but if you’re not using exec, execve and friends you’re already doing it wrong.
This whole thing is really blown out of proportion.
Soulbender,
It’s not limited to bash though. Here’s a contrived example in PHP, where constitution.txt is the document at http://www.archives.gov/exhibits/charters/constitution_transcript.h…
This trivial program correctly prints the following output:
However on a vulnerable system, when the environment variable gets tainted with injected commands like this “() { :;}; echo vulnerable”, this same PHP script! outputs the following:
I guess it’s a matter of opinion. The program above could obviously be written differently, however from a security standpoint I have a hard time faulting the code above for this vulnerability. The code just happens to be using language functionality that is backed by library calls that happens to be triggering the vulnerability.
I hope my example proves that it can be a serious bug even for those of us who don’t write bash scripts!
Scanning one of my client’s production servers for this pattern, I’ve discovered that the roundcube webmail application invokes this code path; in that case the saving grace was that I’m coincidentally running debian, which uses dash instead of bash. There may be more instances but I stopped looking because the conclusion is always the same: update bash.
Edited 2014-09-27 04:21 UTC
Oh god, anyone who does this kind of thing really deserves to get hacked. And yes, that depends on bash being the default shell since backticks runs the program in a shell. If the default shell was pdksh or ash there would not be an issue unless PHP is hardcoded/built to always use bash.
Again, you should almost NEVER run anything in a shell, especially from a web service. Use fork+exec (or whatever is the equivalent in your language) and you don’t have this problem. For PHP i believe you should be using pcntl extension.
Of course, you also have to make sure that the program you run isn’t s shell script….
That’s because PHP sucks balls and doesn’t have a safe way to run commands unless you use an extension.
Soulbender,
Surely you have to admit this is a blatant exaggeration. Frankly piping data like this has been a perfectly accepted way to build *nux software for eons, even if it is less conventional for some types of software.
As you may know I’m no particular fan of PHP either, however this is not unique to PHP, I merely used it as an example due to it’s popularity. If you’re going to blame something, it should be glibc, which spawned the shell.
Without examining the entire software stack, it’s impossible to say with certainly that they’re not affected. When I send an email on a web form using a “mail()” function, is the sendmail child process vulnerable? Without first looking at the code, can anyone assert with confidence that it’s not vulnerable?
Anyways, regardless of who’s at fault, all I’m trying to point out is that commenters are wrong to think this bug can only affects them if they’re running bash scripts. You will give me that right?
Edited 2014-09-27 14:07 UTC
Yes but you should never pipe stuff in a web application, especially not if you expand variables. There’s just way too much that can go wrong and way too many ways to exploit that.
Not at all, glibc is just doing what it is told, spawning a shell. PHP should by default provide safe ways to execute commands without using a shell. It doesn’t and I’m sure it’s the only popular programming language that doesn’t do so.
I can say for certain that none of my Python-based web apps are affected.
We should really stop using PHP examples since PHP does everything wrong, all the time
.
But to address your question, I don’t know if PHP spawns a shell for sendmail. There’s no reason it should but knowing PHP it probably does.
Oh yes, I certainly hope no-one here thinks you’re only affected if you run Bash scripts.
Edited 2014-09-28 04:00 UTC
That’s a nice article though, much better than the engadged one.
Soulbender,
Haha, yea engaget’s article was disappointing
Running a SSH or HTTP server, don’t worry about it, most distro’s are already patched just use ya update to update bash and possibly libreadline.
it does not matter, when your default shell is, it bash is there its exploitable….
It makes all the difference, really. If Bash is not the default shell any program and web app that runs something in a shell will not be affected. Granted, there might be those that explicitly use Bash but those are probably very few in comparison.
This is a major disaster, because it effects females and therefore females are being discriminated against!
Feministas Unite!
– Brendan
HeartBleed and Shellshock. My company kicked it’s last Linux server last month – due to an EA deal with Microsoft. I see the IT management gloating about how bad opensource is. Once a major FOSS shop now almost completely taken over by MS and other proprietary software vendors.
Good luck maintaining and patching the shit out of that environment every month, with updates and patches breaking random things.
Life for me is the reverse of what you are saying. I make a good living weaning companies off of the microsoft koolaid.
Yes, this year has been pretty crap for FOSS projects.
The problem I see is that there is a social need for software that is freely available, reliable, and whose developers are not beholden to governments or moneyed interests – “software for the public good,” as Debian calls it. A software equivalent of public radio, if you will.
That said, a fair number of “free” projects fail the second and third criteria.
IMO, of course…
You’re not supposed to pass unsanitized data from untrusted sources to the shell, ever. Not as environment variables, not as anything. Wherever Shellshock crops up, it can only be because someone has been doing exactly that; be it via the system() library call, or whatever.
The real problem isn’t bash. The real problem is that lots of software is passing untrusted stuff to the shell. In the long run, I don’t think using a more restrictive shell would help a lot; this is just bad practice. Depressingly ubiquitous bad practice.
Mind, I would point a finger at glibc (and probably at UNIX in general) for making “bad practice” far too easy, but at the end of the day, it’s still application developers screwing up.
Bash is the problem because bash is parsing all environment variables regardless if it’s needed or not.
Other shells only parse the variables that has special meaning to the shell, like PS1, and just passes on the other variables.
It would help because the other shells aren’t broken by design.
Still seems to me you don’t want to get the shell involved if you don’t have to. Shells execute stuff, it’s what they’re made for.
Anyway I’ll bite: how is bash “broken by design?” Shellshock is an implementation issue, isn’t it?
Bash parses EVERY environment variable, by design, regardless if that makes sense or not. While ShellShock in itself is a bug in said parser the real problem is that the design is broken and Bash shouldn’t blindly parse all variables. No other shell does this strange thing.
Gullible,
Sanitizing input is all well and good, but I have to strongly disagree with your conclusion on a pragmatic basis. Environment variables are intentionally generic, they are allowed to contain the characters that bash considers to be code. Arguably you might prohibit environment variables from containing shell code, mysql code, perl code, python code, etc on the bases that any of these languages might theoretically have this dangerous bug whereby all environment variables are accidentally executed as code.
But however well meaning your intention, it breaks the correct behavior! If the user passes in “rm -fr /” or “delete from user” as his user agent, then it’s not apache’s job to try and parse/block it. It *SHOULD* pass in the actual value even if it resembles shell code. In this case the RECEIVING program needs to sanitize it.
I’m reminded of PHP’s maligned “magic quotes” debacle. The language’s designers took it upon themselves to automatically convert all input strings into SQL-escaped strings “just in case” to foil sql injection attempts. Unfortunately this broke the behavior of correct code that did not have such vulnerabilities. While this feature could be turned off (and has since been depreciated), this lead to conflicts between code bases, and resulted in many packages implementing both modes.
So I assert that the parent (ie Apache) should just pass the correct raw values, and it’s our responsibility to handle those with care. If a child process does
that’s it’s own damn fault. Don’t point the finger at apache, it’s not the parent’s responsibility to protect the child from it’s own bugs. Anything else would lead to additional complexity, and a false sense of security.
Thank you, that was quite enlightening.
(I would mod your post up, but I’m not allowed to… bah.)
Gullible Jones,
Haha, thanks.
I’ve wondered if there could be a better way to find bugs like this. We’re often reminded that “Given enough eyeballs, all bugs are shallow”. And though ostensibly true, it assumes enough of us are looking for bugs in the right places. We still can miss things because while bugs are more or less evenly distributed, our focus is not. My suspicion is that perhaps there are tens of thousands of devs looking at some pieces of code, and very few, save one or two, looking at others (such as the underfunded openssl team).
I wonder if maybe, as an experiment, we could take all the code in a kernel and/or distribution, automatically break it up into function fragments, and assign those fragments redundantly among available developers for code review.
This system could assure that all code gets it’s share of eyeballs to review it, even code that’s old&boring and previously assumed to have no bugs. The redundancy could be used to score the developers who are either unwilling/unable to detect bugs in their fragment. If they’ve been assigned a fragment and failed to find bugs that others uncover in the fragment, then the system can automatically adjust the developer’s weight. This way casual observers are welcome to try their hand without overly skewing the analysis of any fragment.
It could be published as a weekly challenge where hundreds of thousands of developers could code review random fragments of code. Reviewers could look at context outside their fragment, but their responsibility would be for code within the fragment. There are questions as to what would constitute a meaningful code review fragment, but from a high level I wonder what you guys think of this idea?
This sounds kind of awesome to me, but I can’t really comment as I’m not a programmer by profession – I mostly write shell scripts, my knowledge of C/C++ is rather cursory.
I do wonder how sensible code fragments could be arrived at though? For projects with heavily spaghettified code bases, that might be very hard, I would think.
Gullible Jones,
I agree that this specially would be a challenge, probably the biggest one. Some kind of automatic dependency resolution might help here so that reviewers can get a better understanding of the fragment’s immediate context. It would show everything that calls into the fragment, and everything that the fragment calls out to. I wonder if this kind of dependency resolution could be 100% reliable?
Technically a stray pointer could land anywhere in the middle of a code fragment and would be impossible for a static dependency analyzer to catch, however I’m not sure this is a problem because whichever fragment caused the stray pointer has a bug. When that fragment gets reviewed, the stray pointer bug will ultimately get fixed, or so the thinking goes…
If I was a grad student, I feel this would be worthy of doing for a thesis – not that I can afford to go back to school now. Pretty soon I’ll have to worry about how to fund my kid’s education.
Don’t reverse-engineering tools like radare do something similar for compiled binaries? Not sure if that would be applicable though.
Alas, I’m not in a position to take such a thing on either…
Gullible Jones,
That’s very interesting, I’d never heard of it before. I’m immediately drawn to things like this, but like a compulsive gambler I’d better resist the temptation to play around with it lest I risk loosing many hours of my life trying my hand at reverse engineering random things.
I was thinking more along the lines of source code analysis, but I don’t know enough to say whether these kinds of binary debuggers would be useful for this or not. Debuggers tend to require lots of manual input to get them into the code we wish to debug, I’m not sure how this could be automated. It’d be preferable to keep manual human intervention out of the code splitting phase.
Edited 2014-09-29 03:54 UTC
I’d like to add here that “sanitizing” the input isn’t the solution either. The correct solution depends on what you’re doing.
If you’re running commands the correct solution is to run the command without a shell and using an argument list. For SQL the correct solution is parameterized queries.
Don’t use string formatting for either. Ever.
“Sanitize your input” is a battle cry that exist largely because web developers had (and maybe even still have) this great habit of using string formatting for both commands and SQL queries.
run the command without a shell
And *THIS* is what I was originally getting at. I still don’t understand why things like web servers would be running commands through a shell!
Shit happens, it would be naïve in the extreme to think that your favoured OS is perpetually immune from bugs, that might provide vectors for hackers, malware etc, be your OS Windows, Linux, Apple, Android, Haiku or BSD. However, although disappointing that a bug is found in a such a basic component and that it wasn’t patched years ago. It seems that that the dangers are being rather overhyped and I’m reassured that I have received 2 update patches in the short amount of time that the bug has been public knowledge.
This isn’t a train wreck other than in the minds of those who would like it to be so.
A security issue, in Open Source.. really!
http://drm-assistant.com/ for DRM removal
http://drm-assistant.com/drmtips/remove-drm-from-itunes-for-free.ht…