Slashdot Mirror
Bash To Require Further Patching, As More Shellshock Holes Found
Bismillah writes Google security researcher Michael 'lcamtuf' Zalewski says he's discovered a new remote code execution vulnerability in the Bash parser (CVE-2014-6278) that is essentially equivalent to the original Shellshock bug, and trival to exploit. "The first one likely permits remote code execution, but the attack would require a degree of expertise to carry out," Zalewski said. "The second one is essentially equivalent to the original flaw, trivially allowing remote code execution even on systems that deployed the fix for the initial bug," he added.
Bash does not have network connectivity. The only thing possible is that there may be remote code execution vulnerabilities when bash is used in connection with a network service like a web-server or ssh. Maybe try to have a minimum of accuracy in these stories?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Seems to me that there are multiple indications that the parser is quirky, ad-hoc and error-prone. Parser construction is an old discipline. Was the bash parser created by people without the proper training, and has later maintenance ignored code because it was too weird?
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I'm not sure bash was ever intended to be involved in web facing applications. That's not what it's for! Once you go down that road, even indirectly, there's a lot that can go wrong.
Maybe next someone will run arbitrary user input from the web through g++, execute it in ring 0, and call it a security hole?
First of all, it's Bourne shellcode and bash has extensions to it. Second of all, whether the programming language is bad or not is totally not relevant. It's the parser in the shell itself that has some fundamental flaws because it executes code inside environment variables that are totally unchecked. You could have a brilliant programming language and still make the exact same mistake.
While you may say that is "by design" it is not common for Bourne shell to do so and most of shell scripts are written to be Bourne shell compatible. By choosing to allow this to happen, Bash programmers made a giant hole in shell security.
I was promised a flying car. Where is my flying car?
Rejoice my brethren; finally linux is becoming popular, the year of the desktop is upon us!
A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
A quick wrap-up of some Slashdot headlines about Windows and open source vulnerabilities. This might not be enough data to say anything certain, but an interesting trend is surely developing.
2004: New Windows Vulnerability in Help System
2004: Four New Unpatched Windows Vulnerabilities
2007: Windows Vulnerability in Animated Cursor Handling
2010: Windows DLL Vulnerability Exploit in the Wild
2012: Windows Remote Desktop Exploit in the Wild
2014: 23 Year Old X11 Server Security Vulnerability Discovered
2014: OpenSSL Bug Allows Attackers to Read Memory in 64k Chunks
2014: Remote Exploit Vulnerability in Bash
The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.
You are correct that this is not a remote exploit by itself. Only with CGI does it become remote. It is a code injection vulnerability that when used with CGI becomes a remotely exploitable vulnerability.
This is not a "blanded" attack that combines with a CGI vulnerability. There is no vulnerability in CGI; it works as specified (you could say that there is a design vulnerability in CGI - and I would agree about that).
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I think you'll find bone-headed obvious holes from time to time from almost all software vendors, with MS being no exception.
This is my signature. There are many like it, but this one is mine.
Is there an updated cut-and-paste toy command line to establish quickly whether you're still vulnerable to these variants, or are the details still embargoed?
Except that Windows probably has just as many holes only you dont know about them because they aren't public or because Microsoft has decided not to invest the engineering resources to fix them or because Microsoft has fixed them in a patch but the actual security flaw is still unknown publicly.
At least with Linux, if a security hole is found (and made public or released to experts in the security community or to the relavent developers or whatever), the number of people who are able to investigate and fix the hole (and make official or unofficial fixes available) is (in most cases) significantly larger than the number of people who would e able to deal with issues in Microsoft code. And the Linux guys can have patches out much faster (and they can get into distros fairly fast too)
I'm a little unclear how I, as a user, can get exploited by this. (I know that it's bash (which pretty much makes MSWindows users immune), but what about the rest of us?)
Do I need to just browse a website on my computer?
Do I need to install Apache/PHP or some other server and open an appropriate port on my system?
Do I need to have port 22 open?
Do I need to have a root user?
Help! I'm a slashdot refugee.
Those of us who've been using Unix, BSD/Solaris, and Linux for the past few decades never had delusional thoughts of vaunted security of these systems in the first place.
Any system will have security issues, as most software is flawed - and systems tend to comprise of dozens if not hundreds of software components.
This is ignoring hardware errors (most people security conscious have been dealing with hardware erratas for decades too), because more often than not those hardware issues are far easier to exploit than software ones (from a time-to-discover exploit perspective).
Anyone stupid enough to re-evaluate using linux because they've only JUST realised they have to consider security, are going to be just as incompetent at running a system no matter what kernel/OS they migrate to. Good luck to 'em.
Still waiting for examples of how to exploit this (remotely or otherwise), without using an existing hole to do so.
The most repeated example is letting the web server call a shell script. Yeah, we did that 15 years ago, and WE KNEW it was a stupid thing to do. There are so many ways of script injection, and nobody gets their quotes perfectly right. I thought security had become better in 15 years, but if that example is the best they have, apparently nothing has changed.
Seriously, if that example matters to anyone but a few morons, I'd have to agree with the astroturfers. Microsoft did improve their security between Windows 95 and 7. It's still not perfect, but at least they aren't running bloody shell scripts from CGI.
The rest of the examples are passing unchecked user input to the shell, either from PHP or even the DHCP client. That's security 101 fail.
Sudo has cleared environment variables for at least a decade. Because passing unchecked user input across the user/root barrier is a security hole. The ability to run setuid shell scripts were removed from major *nix kernels around the same time, for the same reasons. So, if both sudo and kernel developers realized a decade ago that passing unchecked environment variables across the user/root barrier was a security problem, how could anyone think that doing the same thing between the unauthenticated user and a shell script through the web server would be any better.
You need to trust unauthenticated people even less that sudo users. At least with sudo users you know exactly who to hit with a clue-by-four.
Of course it is.
Even "sed" (the text filtering utility) is a programming language.
If you have mechanisms for comparison, branching and buffering, you are dealing with a programming language.
Pretty good is actually pretty bad.
You thought you could run a totally free hobbyist OS and have it be as secure as one done by paid professionals?
Be glad its there for you to use at all. People donate their time and energy to it. Don't look a gift horse in the mouth.
Some would argue that Mac OS X isn't a totally free hobbyist OS and yet, with all of their paid professionals, they have yet to patch the bug. On the other hand, Linux being a free hobbyist OS means that researchers have the ability to scan the code and discover these types of holes. Something that is impossible for closed systems.
The Microsoft that delays releasing patches for zero-day vulnerabilities so the NSA can exploit them first? The one that took 7 years to fix a known vulnerability? The one that took 7 months to fix a remote IE exploit after it was reported, just because it wasn't public enough?
And with linux, as long as you install from your distribution (that already have most if not all that you will ever need to install), you have security fixes for all of what you have installed, not just the kernel or a minimal core of apps.
Fucking Linux. NEVER AGAIN. At least with mswin, my stations will auto-update. (Not to mention they never would have had such a bone-headed obvious hole to start with.) Christ, even my headless server stations that I never thought I'd have to fuck with again are vulnerable. Goddmammit. This could even compromise accounts I have on remote servers if they are not keeping up-to-the-minute updates. I guess you get what you pay for. Caveat Emptor. I just never thought it would come back to bite me so hard. I suppose you never do.
What makes you think Windows doesn't have problems like this? The difference is that being open source third parties can review the code and find problems. There is no way to keep them secret and from the public. Also, fixes were pushed out within hours of notification.
Look at it this way. BASH has had this problem evidently for years and there haven't been any exploits. It was discovered by researchers analyzing the code. In an MSoft world, where nobody has access to the code but MSoft, the public finds out about security holes after they have been exploited. So I agree, Caveat Emptor.
Exactly. My goodness, Windows is legendary not only for having severe holes, but for Microsoft taking a long time to fix them.
Kythe
From Eric Blake's bug-bash post
If you see anything like the following:
you're still vulnerable. There may be other issues the above does not cover.
The complexity of the language syntax drives the complexity of the language parser.
Nobody ever got fired for using Microsoft..
Seems like a management oversight. I would be shocked to find that I have to pay for upgrades every couple of years.
never had problems like this with CCP.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
No. The bugs we see in Bash have analogs which have been found in most software implementations, remember all of the Bugs found in Java, Python and so on, this is not a Bash only thing. Bash implements a programming language of its own (its own extensions to Bourne), and implements functionality that is unique and different from other languages. When you want the Bash programming language, Python isnt going to do that for you. What needs to be done is to fix the problem in the implementation and its much quicker to fix the current code base rather than to rewrite. the problem here is the implementation, not the language. The language itself is not the prroblem, is fine for what it does, its some problems in the implementation.
Shill much? I had three machines. One running Ubuntu, one Centos and the last one FreeBSD. The FreeBSD box was scripted to update ports regularly. The Ubuntu machine also runs updates from cron. The Centos wasn't set to update automatically but updated without issue. I went ahead and made it update on a weekly schedule while I was at it. In short free does not mean maintenance free. Microsoft has had its share of bugs some of which remain unpatched to this day.
Apparently, it is not "Ubuntu" but rather "Anonymous Coward" that actually means "I can't configure Debian".
Ezekiel 23:20
You'd better call it the GNU/Shellshock security vulnerability!
Its not hobbiest, not sure where your coming from, you seem like the same guy trolling a conversation that makes no sense. All OS's have problems and will require patches on a regular basis. Let me know if any Non free or free OS that does not require security patches.
Except that Heartbleed had nothing to do with Linux. Many things out there use OpenSSL.
Ezekiel 23:20
Hey Anonymous coward. How many of PF Chang's, Target's, Jimmy John's, and Home Depot's POS machines were running Linux?
The reason Windows doesn't have problems like this
HOLY
FUCKING
SHIT
There are two types of people in the world: Those who crave closure
I agree that python doesn't cut it. But node.js is a better bash than bash. We replaced all our shell scripts, perl scripts, etc with node.js a couple months ago. Since it's javascript, all our front-end developers are comfortable writing system admin utilities. And since it uses non-blocking, it's faster than bash or C. There are npm modules to do most things you need to do already.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Even "sed" (the text filtering utility) is a programming language.
Indeed it is. It is a fantastic Turing tarpit. It was never ever ever designed to be turing complete and the feature set is geared towards doing nothing but batch search and replace.
Naturally this means that people like to program interesting things in it for fun. Some of the most impressive are implementations of dc and sokoban.
SJW n. One who posts facts.
A dhcp client passes values (like its new hostname) from the dhcp server to an environment variable before executing a shell script to setup the hostname, resolv.conf, etc.
When you are connecting to a public wifi hotspot you may get comprised because of this bug.
Why does bash have to worry about security? It's just a shell, a thin interface supposed to execute whatever commands it receives. Surely the bug lies with Apache et al. for not properly censoring the data they receive from outside and send to bash for execution.
I understand that the exploit works by appending malicious commands after a function definition contained in an environment variable. The environment variables aren't meant to contain anything more than the function, so executing the extra code is a bug. In that sense the bug belongs to bash. But the shells were never designed to be secure against this kind of attack, and as we're now discovering there are all kinds of related vulnerabilities. Server software such as Apache is made to be secure: it has to worry about sending arbitrary commands to bash, so why not worry about setting arbitrary environment variables too?
All they need is a more convenient API to control processes.
Have you seen scsh?
Ezekiel 23:20
The design of the language (which is fine by the way, its different, but its fine), has absolutely nothing to do with these bugs.
Except that Windows probably has just as many holes only you dont know about them because they aren't public or because Microsoft has decided not to invest the engineering resources to fix them or because Microsoft has fixed them in a patch but the actual security flaw is still unknown publicly.
Innocent until proven guilty. All I see is that the Microsoft vulnerabilities are no more in the headlines.
You could as well say that Heartbleed and Shellshock are just scraping the surface, and are an indicator that open source might have more dragons lurking.
I guess you're part of the systemd team.
Of course it's pretty much irrelevant. The bug doesn't matter in practice unless you're doing other, severely braindead things.
A successful API design takes a mixture of software design and pedagogy.
I wonder how many Duff's devices are in it. ;-)
Ezekiel 23:20
If you have the bucks then pay the professional, I haven't heard of any of them to do a terrible job for the huge paycheck. And the insurance will not cover even if a 'professional' did a lousy job.
What the guys in the thread are stressing and you are not getting is the regulation of said job(s). And in my opinion both FOSS and closed source lack, in practice, a lot of testing scenarios. Being a conscious fellow I can add my own hacks... er... tests to see what I am installing, to more or less satisfying results and I always open a bug report when things aren't ok. And the tests, in my experience, are more easy to do and have shorter resolution loop (including feedback and push forth) in open source as it is in closed source. Also, the guys back at the source are really helpful even if you didn't pay for a support contract and the criteria for selecting your bug to be resolved are in most cases technical and fair.
uhm...
# don't work .. :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
..
.. :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"
..
env X='() {
# don't work
env X='() { (a)=>\' bash -c "echo date"; cat echo
# don't work
bash -c 'true EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF' echo "CVE-2014-7186 vulnerable, redir_stack"
# don't work
(for x in {1..200} ; do echo "for x$x in ; do
# don't work
foo='() { echo "CVE-2014-6277 vulnerable"; }' bash -c foo ref
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1912
There have been a dozen remote code exploits in Python over the years. So it begs the question, why is everyone picking on Bash when most languages have these problems?
The following O.Ses have disabled environment functions entirely, and should be safe: NetBSD, FreeBSD. This is known to break the test suites of some free software, which will be fixed eventually.
The following O.Ses. doesn't use bash for /bin/sh, system() and popen() by default and are a lot safer than the other Linux distros against exploitation of Shellshock: Debian, Ubuntu. Unless the local admin was foolhardy enough to change the /bin/sh symlink to /bin/bash because of third-party crap. Then, he is just as screwed as any user of the other Linux distros.
The following distros are known to have added the "unofficial" namespace fix in the second round of security updates, which reportedly *does* mitigate the undisclosed vulnerability: Debian, Ubuntu, Fedora, RHEL.
Since the upstream namespace fix ALSO mitigages the undisclosed vulnerability, I'd expect all distros to have picked one of the two patches by now. Note that "mitigates" means "makes it very difficult/impossible to trigger remotely", i.e. closes at least the CGI / popen / system/dhclient doors, which are the worse ones that allow for easy mass-p0wn1ng.
To know whether you have one of the two namespace fixes, which should mitigate the undisclosed vulnerability (according to Icamtuf, who discovered the two yet-to-be-disclosed security bugs):
foo='() { echo not patched; }' bash -c foo
If the command shows "not patched", you don't have the patch and you are still vulnerable to a (currently non-public) RCE, even if you applied the original one (or the subsequent upstream patch that addressed the issue found by Tavis).
Oh, and if it shows "command not found", you're good.
find|grep spawns two processes. find -exec grep is probably what you meant. I think something like "grep xxx $(find yyy)" should produce the same result without huge amounts of forking. Unless command line length has a practically reachable limit. I'm not sure about that.
Geek around in PowerShell for a couple of weeks and you never want to go back to the ancient UNIX shells. :)
Damn straight! Mactards are still using a vulernable bash. Unlike us lunix geniuses that have patched bash 3 times in the past week and are still using a vulnerable bash!
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
What makes you think Windows doesn't have problems like this?
They did. But it is a long time since that last vulnerability on this scale. Following the embarrassing Nimda and Code Red (and many vulnerabilities in IIS), Microsoft started it's "security push". The central part of that is the Secure Development Lifecycle (SDL) which as a collection of processes, methodologies, tooling, mandatory education, guidance and mandatory threat modelling, reviews and auditing.
The difference is that being open source third parties can review the code and find problems. There is no way to keep them secret and from the public.
That all fine and dandy. Only, these bugs (the original Shellshock and these later) have existed for 22+ years! During all that time, nobody (we hope) "reviewed the code and found problems". So, if there were any third parties looking at the source, they failed miserably (or sold exploit information on the black market).
Look, there have been bugs found in old MS code as well. A few years back there was a vulnerability in the old DOS emulation code.
It is time to let the myth of the many eyes die. The community is not going to help you by reviewing code unless you *pay* them to do so. It is the most boring discipline of developing code, and nobody does it out of interest.
A company like Microsoft can *pay* people to review and audit code. A big part of SDL is exactly those supporting roles and checks/gates. The open source community must wake up and set up foundations OpenSSL style and start asking those who reap the biggest benefits for some funding.
Also, fixes were pushed out within hours of notification.
Do you really want to go there, given the incomplete patches and host of related problems which could have been found had the maintainers taken more time?
Part of SDL in Microsoft is exactly a process where, when a vulnerability has been reported, they must take time to analyze if there are related or similar vulnerabilities, what impact a patch could have. On top of that they have a gigantic test farm where they test for compatibility with a huge number of popular software applications.
Essentially, what Microsoft does *internally* and prior to releasing information on the bug, is now what for bash takes place *externally* (external security researchers) and *after* the vulnerability info was released.
Look at it this way. BASH has had this problem evidently for years and there haven't been any exploits. It was discovered by researchers analyzing the code. In an MSoft world, where nobody has access to the code but MSoft, the public finds out about security holes after they have been exploited.
No no no no. This bash problem was discovered by someone trying to see if you could pass a lambda (an anonymous function) from a bash shell instance to a subshell. He then noticed some weirdness and investigated.
After the bug has become known, security "researchers" homed in on the bash interpreter. Still from *the outside* (i.e. NOT looking at the source code), more vulnerabilities were found (see Tavis Ormandy's tweets).
The easiest way to find these bugs remains to just play around with bash and try to throw it off with weird syntax. And that is how these bugs are being found.
There is absolutely no evidence that having open source code makes the product more or less secure. To be honest, only the most obvious bugs are ever found by inspecting the code - which tend to be the same class of bugs that would be found with just some cursory testing.
No, the quality of the code is impacted by the quality assurance processes that surround the development process, such as testing, threat modelling, security audits, tooling, guidance etc.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Exactly. The only way anyone could think "Windows doesn't have holes like this" is if one literally pays no attention at all.
Or if one is here to spread misinformation as an AC.
Kythe
Oh it parses it just fine. It was just a dumb idea to parse it in the first place.
If somebody chokes and die eating dog shit picked up off the ground, the proper question to ask isn't "why didn't he chew before swallowing?", it's "why the fuck was he eating dog shit?"
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Depends on the headlines you read.
http://web.nvd.nist.gov/view/v...
If you get your server administration advice from CNN's front page, perhaps your employer is not getting his/her money's worth.
Kythe
To be fair, perl had these problems in the early 90's and "taint mode " was introduced to protect against them and unforseen future variations on them. I seem to recall a release of PHP in the past couple years has adopted some of the same techniques. Bash folks won't be able to achieve a great result over a weekend. That we're here two decades later tells you most of what you need to know about the appropriateness of selecting bash for this kind of work.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
or Debian and Ubuntu where /bin/sh is Dash and not Bash!
You'll be shocked even more when you understand that you don't. Companies pay yearly license to microsoft largely regardless of upgrade status.
Python? You serious? Bye bye one liners with for loops or anything else. I really doubt anyone wants to have pretty code enforced on them for something as simple as iterating through a few numbers one time, ever.
RedHat is far more economical than Windows, when you need a big population of nodes, because you can use fi. free Scientific Linux on your many compute nodes and just keep one or two for validation of bugs and formal support. Best of all, it is all legal as long as you don't misrepresent the facts!
Nope.
A lot of it is written in Bourne shell scripts, which may be interpreted by bash, ksh, dash or some other "sh" implementation.
Some of it (too much) is actually written in bash, but probably shouldn't be. (Hello authors of "zless"),
Watch this Heartland Institute video
Is this a generation thing ?
I thought these were features 20 years ago, and these features required sanitizing your input.
This is like little Bobby tables but with bash.
Sanitize your inputs for anything not expected, only process acceptors input.
I think the GP is referring to the business precept that it isn't the amount of shit rolling downhill that matters, but rather where it stops.
That's why you see companies doing seemingly silly things like purchasing manufacturers' support contracts for obscene amounts of money when the same support could be provided in-house for less than a tenth the cost. The reason is that if all hell breaks loose, if you have a support contract(*) you can shift the blame onto the manufacturer, but if you're doing it in-house and it breaks, you only have yourself to blame.
So if you have a Microsoft machine, and it has a severe remote vulnerability, you can say "Hey, it's not our fault! We're using software provided for this purpose by one of the biggest software companies in the world. If they didn't know it was broken, what chance did we have?" Whereas if you're using a system which was put together in-house, especially if such a system was billed as a "cost-cutting option" in opposition to a CYA Microsoft option, the blame stops at the in-house people who put it together. Offloading the blame to a nebulous group of people on the Internet to whom you paid absolutely no money tends not to work.
*) I know Microsoft typically doesn't have a support contract with similar monetary disaster penalties, but the same general pass-the-blame approach applies, even if no money changes hands because of it.
It's time for big companies that use open source code (Amazon, Google, Apple, even Microsoft) to start *paying* their employees to do security checks on these open source projects. I know they already support OSS, but maybe it's time to get serious about it?
It appears to have been implemented in some ksh versions in 1988. My Bolsky/Korn ksh book says "This feature is not available on all versions of the 11/16/88 version of ksh."
GNU AWK uses the same syntax.
Oh, good, for an OS with many tens of millions of lines of code, you can review code for one slightly related development framework.
And that somehow means the rest of the OS is reviewed well..
AT LEAST THERE'S THAT.
while(1) attack(People.Sandy);
The following O.Ses. doesn't use bash for /bin/sh, system() and popen() by default and are a lot safer than the other Linux distros against exploitation of Shellshock: Debian, Ubuntu.
Unless your CGI script happens to run zgrep or any of the other things that force bash use for no obvious reason.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762915, apparently just fixed.
Watch this Heartland Institute video
Well, let's see here... Heartbleed was a bug in OpenSSL, use in a lot of software that has nothing at all to do with Linux, and Shellshock is a bug in the Bash shell, which predates Linux by 2 years and is used on a lot of systems that have nothing at all to do with Linux. Neither bug was a Linux bug, though both affected Linux systems; both also had the ability to affect Windows systems running any number of applications that rely on OpenSSL (if you open your eyes, you might be amazed how many and how common) or Bash (fewer, but still not completely unheard of; there are a number of POSIX layers for Windows, and all of them use Bash by default as far as I'm aware).
The last time I posted these facts, I was modded flamebait, and I'm sure it'll happen again. Plenty of karma to burn, though, so, whatever.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Lol.
You pay for Software Assurance and yet their release cycles seem to push past the edge of the 3 year SA agreements in so many cases, requiring ongoing renewal of SA in order to not lose it.
They took notes from Cisco's playbook on how to long term fuck their clients.
This is my sig. There are many like it, but this one is mine.
An unprovable assertion.
Gamingmuseum.com: Give your 3D accelerator a rest.
Shellshock has nothing to do with Linux, either. Bash predates Linux by 2 years.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
And it still took 20 years. That argument is bunk, just like the argument that it's automatically more secure because it's open. It *can be* more secure, but people actually have to audit it.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
A few things:
1. Linux can auto-update.
2. My employer's IT department does not blindly accept auto-updates. All PCs - both mswin and Linux - are configured to update from the company's servers, not any server outside the company. IT vets all updates before making them available on the company update servers.
3. The mswin experts (MS certified) in my employer's IT department have found and reported several "bone-headed obvious holes" in mswin.
4. Just because you are paying fees to receive commercial support does not mean you can setup-and-forget.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
The Shellshock bug is from 1992.
Blaster (and Mydoom, Sasser, Loveletter, all the classics) is from the era when vulnerabilities actually were a very serious problem with Microsoft software, including Windows, Outlook, Internet Explorer, Internet Information Server. Back then, Linux still did provide significant benefits over that junkpile. But times have changed.
maybe, "How many hackers does it take to change a light bulb ?"
ACK! Do any of the windows advocates have any memory of 'Win Nuke' ? 'Code Red' ? Consider that out-of-the-box Microsoft _STILL_ exposes all of those ports on a PUBLIC IPv6 ADDRESS if you choose to enable IPv6. that's right, a firewall will NOT protect you, unless you can configure firewall rules for IPv6 packets on your router. Fortunately, I can (with a non-windows OS), and it's a built-in feature of the OS to a) be an IPv6 gateway, and b) firewall-filter it. So I had to check to see what ports were listening on XP, Vista, 7, and 8.x, and program firewall rules for them, before letting them use IPv6. And hopefully I got it right. Because _MICROSOFT_ _GOT_ _IT_ _WRONG_ and I don't see any patches disabling those listening ports, either. Remember, 'WinNuke' would allow someone to bluescreen your windows box by simply being on the internet. Just send a malformed packet to UDP port 139 [I think that was right] and _BOOM_. It didn't matter if you allowed SMB sharing. The port was STILL open. That was a HUGE hole. And the thing is, the port is _STILL_ open but NOW on public IPv6 addresses! YES, any web server _COULD_ figure out your public IPv6 address and _THEN_ exploit your windows machine. Potentially.
You thought you could run a totally free hobbyist OS and have it be as secure as one done by paid professionals?
Red Hat Linux
pwnt
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
The ability to drop the GUI and slim the system down to run on a machine with very limited resources, while still having a full system (e.g. not CE) is a significant benefit over Windows. Even on systems without limited resources, it's a benefit to be able to slim down the OS as much as possible and provide those resources to your application.
For those of us who install security updates automatically, this was patched within hours of being discovered, and each further patch has been applied within hours, as well. On a Windows system set to install updates automatically, bugs *still* go unpatched for months after being reported.
I'm saying this not as a Linux proponent, but as someone who uses all 3 major systems on a daily basis, for whom Linux isn't even a primary system.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
It does. I reach it often. Worrying about forking is often a premature optimization that only the OCD inflicted worry about on most modern systems. The same with those who worry about cat|
many eyes make all bugs shallow.
Doesn't specify a time frame. And 25 years is still sooner than never if the Microsoft dev team don't catch it themselves.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
On the open source projects I've worked on where Google is a big contributor, they are very keen to push features and randomly refactor large parts of code, but I've never seen them do anything like a security audit. They did, however, do a big audit of libavcodec (which they use) and fix around 300 security holes...
I am TheRaven on Soylent News
Since it's javascript, all our front-end developers are comfortable writing system admin utilities.
Ummm...are you saying that's a good thing? I strongly suspect that if I passed that comment by the few systems guys I know, they would start twitching.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Oh it parses it just fine. It was just a dumb idea to parse it in the first place.
Re-read the latest CVEs. There are bugs in the parsers that can be exploited, so even if you're never invoking the functions they're already run through the parser and the parser is breaking things for you.
I am TheRaven on Soylent News
Arguably, the bug in Linux was in that it chose to use a program as large and complicated as bash as its idea of /bin/sh.
Though bash is, of course, available on all other OSes, no one else makes it the interpreter behind most of the system's own scripts as well as the system(3) function.
In Soviet Washington the swamp drains you.
Technically, it would be a bug in any script starting with
#!/bin/bash
having absolutely nothing to do with Linux.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Nobody actually said that Linux is more secure. What has been said that security flaws are more likely to be reported and patched before they are exploited. The reason Windows doesn't have problems like this is because they really do. However, Microsoft is very good about non-disclosure agreements and the like. But, security by obscurity isn't really security. It's just marketing and wishful thinking.
As for being burned by this, it hasn't happened. The flaw has been there for 22 years and yet not one exploit has been noted. Nobody has been burned by this because of the difficulty in actually exploiting it (without have physical access to the machine). Should this bug be there? No, of course not. But it is the open source nature of linux that led to this even being reported.
Lol.
You pay for Software Assurance and yet their release cycles seem to push past the edge of the 3 year SA agreements in so many cases, requiring ongoing renewal of SA in order to not lose it.
They took notes from Cisco's playbook on how to long term fuck their clients.
They started the that policy in when Windows XP (and Server 2003) were released, and lost a third of the customers when they didn't deliver a new release within the 3 year Window. Yes, some of those got new policies later after that, but that policy change also drove many to evaluating Linux as an alternative (well documented at the time in the news) and some to switch when they found out they didn't really need Windows or Microsoft.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
I think the GP is referring to the business precept that it isn't the amount of shit rolling downhill that matters, but rather where it stops.
That's why you see companies doing seemingly silly things like purchasing manufacturers' support contracts for obscene amounts of money when the same support could be provided in-house for less than a tenth the cost. The reason is that if all hell breaks loose, if you have a support contract(*) you can shift the blame onto the manufacturer, but if you're doing it in-house and it breaks, you only have yourself to blame.
So if you have a Microsoft machine, and it has a severe remote vulnerability, you can say "Hey, it's not our fault! We're using software provided for this purpose by one of the biggest software companies in the world. If they didn't know it was broken, what chance did we have?" Whereas if you're using a system which was put together in-house, especially if such a system was billed as a "cost-cutting option" in opposition to a CYA Microsoft option, the blame stops at the in-house people who put it together. Offloading the blame to a nebulous group of people on the Internet to whom you paid absolutely no money tends not to work.
*) I know Microsoft typically doesn't have a support contract with similar monetary disaster penalties, but the same general pass-the-blame approach applies, even if no money changes hands because of it.
Which is where Canonical, Red Hat, and SuSE step in - to provide those CYA agreements.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Unless your CGI script happens to run zgrep or any of the other things that force bash use for no obvious reason.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762915, apparently just fixed.
Very unlikely. Most CGI engines have built-in support for gzip compression, since it could be used for compression/decompression of the content.
Also, most "CGI" nowadays is only "CGI" by the name. Zend/PHP, RoR, mod_perl - are all either FastCGI or Apache plugins, and do not use the environment to pass information around.
All hope abandon ye who enter here.
The Shellshock bug is from 1992.
Please quote the bug report and date filed.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
What makes you think Windows doesn't have problems like this?
They did. But it is a long time since that last vulnerability on this scale. Following the embarrassing Nimda and Code Red (and many vulnerabilities in IIS), Microsoft started it's "security push". The central part of that is the Secure Development Lifecycle (SDL) which as a collection of processes, methodologies, tooling, mandatory education, guidance and mandatory threat modelling, reviews and auditing.
OSS has SDL too, primarily due to very extensive use by many projects of code testing (f.e autotest), Coverity testing (provided for free to OSS projects), use of Valgrind, and more. OSS projects generally have far more testing involved with them than closed projects, in part b/c people report bugs and those bugs become tests in the project's test suite.
And with companies like Red Hat, Coverity, etc providing more influential secure coding testing and fixing patches (Red Hat, Debian, etc) it probably gets done more often.
But let's not also forget in OSS patches tend to stay in the code; where MIcrosoft has a long history of applying a fix in one patch, undoing it in the next, and having to repatch over and over again (see the WMF bugs, repatched from Win NT4 through Windows 7, if even Windows 8, e.g after SDL was implemented).
The difference is that being open source third parties can review the code and find problems. There is no way to keep them secret and from the public.
That all fine and dandy. Only, these bugs (the original Shellshock and these later) have existed for 22+ years! During all that time, nobody (we hope) "reviewed the code and found problems". So, if there were any third parties looking at the source, they failed miserably (or sold exploit information on the black market).
Look, there have been bugs found in old MS code as well. A few years back there was a vulnerability in the old DOS emulation code.
It is time to let the myth of the many eyes die. The community is not going to help you by reviewing code unless you *pay* them to do so. It is the most boring discipline of developing code, and nobody does it out of interest.
A company like Microsoft can *pay* people to review and audit code. A big part of SDL is exactly those supporting roles and checks/gates. The open source community must wake up and set up foundations OpenSSL style and start asking those who reap the biggest benefits for some funding.
Companies like Coverity provide it for free to OSS projects, and companies like Red Hat and Canonical pay for it as well. The OSS community has the practices and reviews in place on many projects; there's a few, like OpenSSL, that have slipped through due to the structure of the teams surrounding them. For OpenSSL many probably assumed that since OpenSSL was FIPS certified that things were being done in the OSS branch too; Heartbleed revealed that assumption to be false and now we have LibreSSL as a result where the norms for OSS projects are being applied.
Also, fixes were pushed out within hours of notification.
Do you really want to go there, given the incomplete patches and host of related problems which could have been found had the maintainers taken more time?
Part of SDL in Microsoft is exactly a process where, when a vulnerability has been reported, they must take time to analyze if there are related or similar vulnerabilities, what impact a patch could have. On top of that they have a gigantic test farm where they test for compatibility with a huge number of popular software applications.
Essentially, what Microsoft does *internally* and prior to releasing information on the bug, is now what for bash takes place *externally* (external security researchers) and *after* the vulnerability info was released.
Look at it this way - projects release the fixes very
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Oh, it has plenty to do with Linux, because if you happen to use that OS, even putting the #!/bin/sh at the top still makes you vulnerable. Observe:
I said that already, you chose to ignore it for some reason...
And then, of course, comes the system(3) call, which invokes /bin/sh too...
In Soviet Washington the swamp drains you.
I know I'll get flamed for saying this, but it seems to me that the Shellshock bug represents a weakness in the Unix philosophy. On Windows, if a similar issue happened with cmd.exe or PowerShell, it would have only a limited effect, because the Windows shell is basically just an administration tool, and no one in their right mind would use it to pass untrusted input of any sort. In contrast, "the Unix way" encourages piping of shell commands to other shell commands, and the use of shelling out as a substitute for proper APIs. To me as a Windows power user, the idea that a basic feature like DHCP is using a shell script behind the scenes seems crazy. The better way to write re-usable code is to do the C/C++ API first, then build both the command line and GUI tools on top of that API. "The Unix way" is a clumsy hack in comparison – and it leaves the shell as a security-critical single point of failure.
Another way to think of it is that Linux is now dealing with an issue that Windows has been struggling with for over a decade: how to fix inherently insecure design decisions without breaking compatibility with a million different legacy applications in the process. Maybe they'll need to implement the equivalent of "UAC" whenever a program tries to shell out?
Obvious troll is obvious.
Unfortunately, Linux has a lot to do with Bash.
The Daddy casts sleep on the Baby. The Baby resists!
Some would argue that Mac OS X isn't a totally free hobbyist OS and yet, with all of their paid professionals, they have yet to patch the bug. On the other hand, Linux being a free hobbyist OS means that researchers have the ability to scan the code and discover these types of holes. Something that is impossible for closed systems.
they're probably taking their time to patch it right instead of running down all these rabbitholes. note how the original patches just went out and here's a second problem.
Well, yeah, if your distro symlinks /bin/sh to /bin/bash, which not all do. In fact, you can install sh, zsh, dash, or any other shell, alongside bash, even on systems that symlink to /bin/bash by default, completely negating your entire point. Looks like you did that on a fedora-based system? I'm going to guess RedHat or CentOS? Observe (from one of my production systems):
/bin/sh /bin/sh -> dash
/bin/sh (that is to say, those requesting /usr/bin/php, /usr/bin/perl, or some other interpreter were left alone) were altered to use /bin/sh with no apparent ill consequences.
ls -l
lrwxrwxrwx 1 root root 4 Mar 29 2012
My production (and development, for that matter) systems are not vulnerable in that manner, because I didn't configure them like a jackass; in fact, any init scripts on those systems requesting a shell other than
My point is that this is not a Linux bug, it is a bash bug. Bash is used on HPUX, amongst many other UNIX variants, up to and including OSX, as well as many, if not most (or all) Windows POSIX layers. Your cable or DSL modem probably has bash running on it somewhere, FFS.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
So do OSX, HPUX, and just about every other UNIX variant out there, as well as BSD and any number of embedded systems, and any Windows install running a POSIX layer. It's a POSIX issue, by way of bash being common amongst POSIX systems, not a Linux issue. Focusing on Linux as a means to be able to say "hey, look, Linux fucked up" serves only to mask the existence of the vulnerability in the vast majority of systems *not* running Linux but also running Bash. For the sake of security, as a whole, please, don't do that.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
You'll still be vulnerable to any script that specifies #!/bin/bash - not uncommon
it's in my head
On a Fedora / Red Hat / CentOS / ScientificLinux box, do:
yum install rpmdevtools
cd
file * | awk '($2 = "POSIX")' | cut -d: -f1 | xargs checkbashisms
Yeah, "too much" is an understatement.
If you have a NAS accessible through the Internet, it will probably soon be part of a botnet. See Using curl to test Qnap NAS for Shellshock.
And note that, as a bonus for crackers, the NAS even runs it's web server as root.
file * | awk '($2 = "POSIX")' | cut -d: -f1 | xargs checkbashisms
Lesson to self: Test before posting. That should be == instead of =, of course:
file * | awk '($2 == "POSIX")' | cut -d: -f1 | xargs checkbashisms
Sorry about that.
I'd prefer that they fix the bug that's known about immediately then look for additional ones. That delay to find other similar bugs is how lots and lots of servers get exploited. You close each hole as quickly as you can. The day the Bash exploit came out there were exploits actively scanning within a few hours. Had they delayed to look for similar bugs for a day or week everyone's servers would be compromised.
Yes you should search for similar bugs and do some extensive testing, but delaying fixes for remotely exploitable bugs is beyond stupid. Particularly where the exploit is trivial, requires no permissions and is already in the wild being exploited. Microsoft has a history of delaying those fixes, sometimes for as long as 7 months. That's not a good policy.
For this new vulnerabilty, there are no toy-command-checks yet I believe. But in the meantime, try the "Fun Shellshock test with curl" on the NAS boxes in your neighborhood (or anywhere else this Google search points you to).
And note that as a bonus the web server on that NAS already runs as root, so there is no need for a "privilege escalation" vulnerability. Nothing to escalate, you start from the top already.
That presupposes that the DHCP server is malicious (in which case YOU ARE ALREADY HOSED because they've already got you by the DNS) and that the client is set up to automatically execute anything DHCP provides in option 114 (who does that?).
There are no "average end users" who are vulnerable to this who aren't equally vulnerable to attacks that don't require bash at all, and work on any DHCP client regardless of operating system - you can use DHCP to supply fake DNS servers to windows and mac clients, and once you own their DNS they are hosed.
Do you have a copy of the bash source code in which this bug was first introduced? There is no versioning going that far back for bash, so you can't possibly know *when* it was introduced. It's quite possible that it's from 1989, when bash was first created, 2 years before Linux came to be.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
And the moment they use a found exploit, some dedicated sysadmin detects the intrusion and figures out how it was done, a bug report is filed, and it gets patched within hours. Like this bug, found by a researcher, reported, and patches were available before exploits; whether or not systems were actually patched is a factor if the sysadmin responsible for each individual system, but the fact still remains that we didn't have to wait until Patch Tuesday for a fix.
Was the first patch complete? No. Nor was the second. The third may well not be, either, but Patch Tuesday still hasn't come around and we're better-patched than those who have to wait for that. Well, aside from OSX users (myself included), who actually paid for their OS (in the form of a hardware purchase), so yeah, I guess "you get what you pay for" holds true here, right? See what I'm getting at, here? Linux users have a steady stream of patches already available to install, for free, while OSX users are left behind by Father Apple. Well, at least *some* of us can compile our own patched replacements, so I'm still not sitting here waiting for Patch Tuesday to fix this.
That being said, I haven't had to reboot my Windows machine for updates, lately. That might be, in part, because it does so automatically, whether I'm there to save my work or not, and regardless of whether I'm in the middle of a multi-day render that I'll have to restart, losing 4 days of progress. Thanks, Microsoft.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
command : # strings /usr/lib/cgi-bin/php5 | grep bash /usr/local/bin/bash /usr/local/bash /usr/bin/bash /bin/bash /usr/lib/cgie-bin doing in place since forever.
gives:
Africa/Lubumbashi
#!
#!
#!
#!
what is php5 doing with those ? And no, my cgi-bin directory is not facing the world, I've had a hand-crafted
Yep.
What is the market share of your Linux-distribution?
It absolutely is a bash bug, yes. It is also a bug in any Linux, that makes it /bin/sh.
In Soviet Washington the swamp drains you.
I can't imagine the stupidity of these security folks or programmers. bash is not remotely, remotely exploitable. Hint, there a program that listened to a network connection, then, it decided to try and pawn off security and trustworthiness to another program. That trust was misplaces and that program is wrong.
If you accept bash commands on a network connection and feed them to bash, then you are an idiot, full stop. Now, if you validate the arguments, the format and the content of the command, for example, you allow two formats true, false. Then, reasonably you can call bash to run those two commends. What you can't do is accept any arbitrary string and pass it to bash.
Problem is that in unix the way is for tools to call other tools, and the shell is so pervasive it could be anywhere. How do you actually _know_ if you are calling bash ?
* If you run /bin/sh are you calling bash ? Should you always check first ? Can you even check ?
* same for calling system() etc.
* If you run any other executable should you always check whether it is a script first ? Can you even check always ?
And this applies all the way down the pipeline, parts of which may be user/admin configurable.
Accept what you prove is trustworthy. Be willing to fix it, and claim responsibility when you are wrong.
No meta characters in environment variables, trivial, not meta characters in arguments, trivial. The argument should be a number, 0 to 255, check it _first_, then pass it.
Where in the pipeline ? What if you don't _know_ what the data is supposed to be at this point (only some other tool might do, down the pipeline, how then do you prove it is ok ? What does "no meta characters" mean in the context of an HTTP Cookie, or an email subject line ? - it is meaningless, arbitrary text is valid data in either case.
I thought we learned this with all the sql commands from the network bugs. We seemed to do the right thing for them, why do they have it so wrong this time around?
What we learnt was to properly sanitize and/or quote text that was executed as SQL commands. At the point that we knew it was going into a SQL command. Your web server doesn't know what you are going to use each form field for, "Robert'); DROP TABLE Students" is perfectly valid as a subject for a forum post, but as a user name in a SQL command it needs quoting first. The web server can't quote it, the cgi script or whatever down the line needs to quote it - if and when it gets used in SQL. Now, the web server also does not know and should not need to know what language a cgi script is in, but if it is bash, then bash will execute data as code before the script has chance to verify it.
This generalises to the whole pipeline - any caller may not know what the data it is passing down the pipeline in the environment (or otherwise) actually _means_, or what is valid/non-valid/malicious. Such determination can only be made by the callee that understands the data - but bash may execute it before it gets there.
Let's assume you are right and we can compare with SQL Injection. With SQL Injection we learned we had to properly quote data before feeding it into SQL, and fix all the places we do that. So, with bash injection, now that we know about it, to do the same we would need to sanitize / quote all environment variables whenever we call bash. Except we don't know when that is (see above), so you really mean that every program that execs any other program or feeds into any other program in a pipeline where that program might possibly be a shell script, needs to quote environment variables. That is just about every unix program ever written (and, er, where/when are you going to unquote that data ?).
Or we fix bash, the program that is actually blindly executing data as code.
What is the market share of your Linux-distribution?
It's Ubuntu, so whatever their market share is. 12.04 if you want to get specific.
It absolutely is a bash bug, yes. It is also a bug in any Linux, that makes it /bin/sh.
It is also an OSX bug, an HPUX bug, a vxWorks bug, and, well, really, a bug in any OS that has bash installed, which makes it a Windows bug in a not-insignificant number of cases, as well. Also, consider that the thousands of Cygwin and MinGW users out there are also likely running servers on top of that POSIX layer on their windows system, they're almost certainly vulnerable.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Not much. RedHat/CentOS dominate — and they are vulnerable...
Not quite. Merely having it installed is not enough. Placing it into the all-important role of /bin/sh — that is what makes it particularly dangerous — and a bug of whatever OS does such a thing.
You may have all your CGI-scripts written in Perl or Lisp, but if you use system() anywhere to spawn off a different program, then you are exposed to this problem on those systems.
Whether or not Ubuntu and CentOS are different OSes or just different distributions, is a matter of semantics...
In Soviet Washington the swamp drains you.
At least with Linux, if a security hole is found (and made public or released to experts in the security community or to the relavent developers or whatever), the number of people who are able to investigate and fix the hole (and make official or unofficial fixes available) is (in most cases) significantly larger than the number of people who would e able to deal with issues in Microsoft code. And the Linux guys can have patches out much faster (and they can get into distros fairly fast too)
There is a flip side to that, which is that too many cooks with no common management may royally spoil the broth, which is what has happened.
When found, this was embargoed and should have been fixed under embargo, properly. Instead, someone pushed out half-baked patches that were proved to be still vulnerable within hours (if not minutes), and by then everything was public. So now we have everyone and his dog patching in panic mode, three, four or more(?) sets of patches now, with each one still proving vulnerable, because collectively we blew our chance to fix it (and test it) properly the first time.
The eventual fix will have to be to stop playing who-finds-the-parser-bugs-first and accept that the whole feature is a security hole and needs to be removed or radically changed - something that could and should have been predicted at the start. There are various patches flying around now that do just that, probably in different incompatible ways. Those changes will, inevitably, break some stuff - and of course we could have looked and tried to figure out the extent of that, and mitigated the effect and been ready with the announcement, if it were still under embargo, but we blew that chance.
I am all for saying that the open source development model is better - but this really is not the best example to use to illustrate it, in fact it's already heading into embarrassing farce territory.
Whether or not Ubuntu and CentOS are different OSes or just different distributions, is a matter of semantics...
Then call it a CentOS or Ubuntu bug. There is nothing intrinsic to Linux, itself, that make is any more or less vulnerable to this *bash* bug.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
second update: apple pushed a patch today. so much for your +5 haterade.
second update: apple pushed a patch today. so much for your +5 haterade.
I don't hate apple, I was just pointing out to the AC that OS X was not a free hobby OS and it was impacted, too.
There are a LOT of organizations re-evaluating the idea of using linux on the server now...
There are lots of orgs thinking about switching to Linux? Well, yeah, thanks for that, Captain Obvious. Tell us something else we already know.
Il n'y a pas de Planet B.
I have re-linked /bin/sh to another light-weight minimalistic shell and I use another sell as cli. Despite this, it is nearly impossible to completely remove Bash from a GNU/Linux system (Arch in my case) because several critical components depend on Bash (either simply by calling #!/bin/bash instead of sh or by depending on bash-specific functionality). Getting rid of those dependencies would give the user freedom to choose any sh-compatible shell. One reason this bash bug and the openssl bug before it are so devastating is that those two implementations are so ubiquitous. If each component in a system is easily replaceable with an alternative implementation, the impact would be far smaller.
I fear a future systemd vulnerability....
The latest version of scsh is 0.6.7, released May 16, 2006.
bash is actively developed. scsh is a dead project.
Next time you recommend something, I strongly suggest you look at the date of the last release and the date of the last commit first.
I don't think many eyes cared to look at the grotesque internals of bash. I've glanced at it before, and it aint pretty.
And, pray tell, how is that relevant for the demonstration of a fact that it already has been done twenty years ago (as a subject of serious research, in fact)? Where do you see me "recommending something"? I strongly suggest that you read things before replying.
(BTW, the latest commit is four days old.)
Ezekiel 23:20
Batch search & replace just screams "Beta reduction of lambda calculus statements" to those who love Turing tarpits. Or perhaps Church tarpits in this case.
Not a sentence!
All of your Linux servers could be auto-updating too. Our company had over 2000 Linux servers located all over the country updated in less than 24 hours of the bug being announced after we vetted the updates on our test servers.
Nevermore.
DeathElks-MacBook-Pro:~ deathelk$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
Yeah right, MS fuckwit. You're getting fucked right now and you don't even realise it.