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.
You need to have a network service listening that passes data to bash (or arbitrary shells, though that would be far rarer). For example, an Apache HTTP server using bash as a CGI to process requests.
In general this is a bad thing, with a few exclusions for items that require it by their very purpose - for example SSH.
Note however that in the SSH example, the 'passing-stuff-to-shell' is post-authentication - so if they can exploit it, they can already log in as you anyways and do what they want.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
There has been much FUD, but not really much technical details in the most common sites. First, this news is inflammatory behind retardation, as it does not make clear that the 2nd patch was officially out by last Thursday or Friday for Debian at least. But then, lets not get the truth on the way of a "news" article, oh noes. As for ways of getting "exploited" they are rather limited. You have to have CGI bash scripts installed on you apache, and CGI enabled, which in more modern distros are far and between. So this will mostly affect old servers. The ways which this works to other services is not clear. Also, it only allows exploit to the same user running the service. I doubt a lot it will allow escalation with setuid scripts, because, as far as I remember, bash has not allowed for decades to mark scripts with setuid due to security problems.
You have to have CGI bash scripts installed on you apache
No. This can affect you if you have a Web-facing server-side application, written in any programming language, that calls out to a shell, and the default shell for 'a shell' on that system is bash.
Except that Heartbleed had nothing to do with Linux. Many things out there use OpenSSL.
Ezekiel 23:20
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*
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.
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.
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)