Unshocking the shell (deconstructing the Bash mess)

moisespedro · 10-02-2014, 08:53 PM

Well, I found another way to check bash's vulnerabilities and I've got contradictory results.

You issue:

Code:

curl https://shellshocker.net/shellshock_test.sh | bash

Output with the latest bash package provided by Pat:

Code:

CVE-2014-6271 (original shellshock): not vulnerable
bash: shellshocker: command not found
CVE-2014-6278 (Florian's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
bash: line 44: 11174 Segmentation fault      bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' 2> /dev/null
CVE-2014-7186 (redir_stack bug): VULNERABLE
CVE-2014-7187 (nested loops off by one): not vulnerable

As you can see, the results differ on CVE-2014-7186.

I've tested CVE-2014-7186 manually with this and it looks like it is still vulnerable.

Code:

pedro@slack [~] $ bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"                                                                                                                                                        
Segmentation fault
CVE-2014-7186 vulnerable, redir_stack

EDIT: I am not really sure why they differ.
EDIT2: Since the manual test reports it as vulnerable I would say this test is more reliable than the one posted on the previous post.

moisespedro · 10-02-2014, 11:05 PM

I meant to post these two posts into the "Slackware vulnerabilities" thread but I made a mistake. Can some mod move the posts to there, please?

keefaz · 10-03-2014, 05:12 AM

Quote:

Originally Posted by moisespedro

I've tested CVE-2014-7186 manually with this and it looks like it is still vulnerable.

Code:

pedro@slack [~] $ bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"                                                                                                                                                        
Segmentation fault
CVE-2014-7186 vulnerable, redir_stack

EDIT: I am not really sure why they differ.
EDIT2: Since the manual test reports it as vulnerable I would say this test is more reliable than the one posted on the previous post.

Just curious, how this code could be exploitable?

Then, why not just do:

Code:

bash -c 'kill -SIGSEGV $$' || echo vulnerable

moisespedro · 10-03-2014, 06:56 AM

Quote:

Red Hat yesterday disclosed two out-of-bounds memory issues it discovered that apparently affect Bash back to 3.2 or earlier. They've
been designated CVE-2014-7186 and CVE-2014-7187.

According to mancha on this post

GazL · 10-03-2014, 08:14 AM

Now, this one I find particularly scary ( http://seclists.org/oss-sec/2014/q4/33 ) as it shows that even using absolute paths isn't safe:

Code:

env $'BASH_FUNC_#badname%%'=$'() { :; }\n/bin/ls () { echo wrongfunc; }  ' bash -c '/bin/ls'

keefaz · 10-03-2014, 08:15 AM

Yes I saw it, but I still fail to see why a programmer would write a script like this (with all those EOFs)
And if it was an attacker and was able to execute bash code, he could do worst things than make his script segfaulting.

I understood the security breach using bash env to execute code. But why a programming language would be considered vulnerable because a script is segfaulting using bad code?

volkerdi · 10-03-2014, 02:15 PM

Quote:

Originally Posted by GazL

Now, this one I find particularly scary ( http://seclists.org/oss-sec/2014/q4/33 ) as it shows that even using absolute paths isn't safe:

Code:

env $'BASH_FUNC_#badname%%'=$'() { :; }\n/bin/ls () { echo wrongfunc; }  ' bash -c '/bin/ls'

I tend to agree with Chet that this example isn't scary, or even really a security issue:

http://www.openwall.com/lists/oss-security/2014/10/02/9

Also, Florian's patch effectively ended the security relevance of all the other bugs to the point where you'd be protected even if you skipped all the other patches. As Chet points out, if an attacker controls the *name* of an environment variable across a security boundary it's a security problem with whatever is misusing the shell. I don't think there's any shell that could secure against such usage since the attacker could set LD_LIBRARY_PATH or play an infinite number of other games.

GazL · 10-03-2014, 05:27 PM

What concerns me is that on a system where /bin/sh is bash there will now be additional environment variables to sanitise that would be harmless on a system where /bin/sh isn't provided by bash. SGID/SUID executables would be the 'security boundary' and unless the programmers took a whitelisting rather than blacklisting approach to the environment sanitisation I can see potential for issues in this area.

qweasd · 10-03-2014, 06:03 PM

What I don't understand is why everyone is so eager to point their fingers at Bash. It is amazing that Bash developers had a fix on such a short notice, and a convincing testimony to how professional they are. Do they really deserve ANY flac? Here's what I don't get: it's been known for years that Bash parses and/or executes code found in the environment variables. It was a feature. So why did Web servers decide it was a good idea to copy Web user input and paste it into the environment? All I see now is the Bash devs making Bash robust enough to handle direct input from the Web (a considerable stretch of its original design goals), while the fault for the security breach belongs squarely to the folks who gave the Web users access to the Bash environment. In a way, Bash is stepping up to fix a giant %@$*-up by multiple other parties because Bash finds itself in the best position to protect the users of these crappy Web, DHCP, and SSH servers.

GazL · 10-04-2014, 04:08 AM

Quote:

Originally Posted by qweasd

it's been known for years that Bash parses and/or executes code found in the environment variables.

Has it? I wasn't aware of it and I've been using linux 20 years, UNIX somewhat longer, and would consider myself fairly knowledgeable (though I only know what I know and not everything). It came as a surprise to me, and I suspect it did to a lot of others.

Unless anyone has studied the bash man-page and happened to notice that 'export' has a non-standard '-f' flag and read up on it they're not likely to know.

I'm not bashing the bash developers, especially the current ones whose effort to address this is much appreciated. Their response to these issues has been excellent, but I do feel that its a case of "can't see the wood for all of the trees" and that this 'feature' was just a bad idea from the start: which might go some way to explaining why no other shell does it.

Serious question: Would anyone be upset if they ripped this dubious feature out, or at least disabled it by default? Is there anything that actually uses this function definition exporting/importing for a legitimate purpose? And if you really wanted to make your definitions available in other shell invocations, why wouldn't you just stick them in a file and use either $BASH_ENV or 'source' to load them? It's a lot more reliable and wouldn't waste system resource by unnecessarily enlarging the process environment.

What is needed is for one of the current bash developers to be brave enough to stick their head above the parapet and say; "This long-standing feature was a mistake. Apologies to anyone who is making use of it, but there are better/safer ways to achieve what you need, and for the greater good this needs to be disabled by default."

As always, that just my opinion and YMMV. I'm done pontificating on this now.

metaschima · 10-04-2014, 10:49 AM

It is definitely a dubious feature that very few know about. Don't try to pass it off as if you knew about it. Yes the bash devs need some bashing because there is no reason for this feature and it is insecure by design. For that they need bashing, for the other things obviously not.

eloi · 10-05-2014, 01:31 PM

When here and in other forums and mailing lists, discussing even with old Unix users and developers, from my total ignorance and using pure common sense I use supposedly "off-topic", "non technical", "insulting" phrases like:

"Think carefully about what you really need."

"Nowadays all is bloated."

"Don't encourage the fake 'easy to use' adding layers and layers of the same reinvented wheel."

"Don't encourage the 'adding features to the infinite' creating unified monolithic monsters."

"Stop constructing!"

Even in front of the facts, some insists in calling the KISS approach zealotry. Other in mistaking it for laziness. Lately Linus Torvalds called it a "mindset". They indeed "bash" themselves (directly and recursively :-)). And everybody suffers the consequences.

ReaperX7 · 10-06-2014, 08:17 PM

I've migrated just about all my user accounts to zsh, but I still leave core script functions to bash respectively. I redid all my system scripts and boot scripts to call /bin/bash directly rather than /bin/sh as /bin/sh points to zsh now.

Nothing is broken, everything works, and life continues onward.

GazL · 10-08-2014, 06:58 AM

You know what they say... If you want something doing...

We've had a couple of rainy days here so I spent a little time coming up with a patch for bash to make it work the way I want it to. In short, I've added a new configure option that can be used to set whether function loading is done by default, and added command-line arguments to override whatever default you set on the configure.

On the off-chance that anyone is still interested, here are the patches to be used against the 4.3.27 in -current.

Full details are in the patchfile.

metaschima · 10-08-2014, 10:08 AM

That's interesting, maybe submit it to the bash devs. The ability to turn off this useless feature would be most useful.