Vulnerability in Bashx2 worst that Heartbleed

[ITGabs]

Hi,

It's time to update linux or everything that is using bash (like git bash in windows)
Full news without jargon http://blogs.wsj.com/cio/2014/09/25/companies-patching-like-crazy-to-stem-shellshock-flaw/

How to test if you are vulnerable

Shellshock CVE-2014-6271

env x='() { :;}; echo vulnerable' bash -c "" | grep vulnerable

If you get the following, your bash is vulnerable:

vulnerable

Aftershock CVE-2014-7169 (after the first patch)

env x='() {(a)=>\' bash -c "echo date" 2>/dev/null; cat echo; rm -f echo

If you get the date, you are still vulnerable:

Fri Sep 26 18:40:39 MST 2014

I tested in x86, x64, debian, centos, ubuntu, kali no idea about Freebsd or Mac

Notice that bash in windows is vulnerable too (git bash as a example)

Edited September 27, 2014 by ITGabs

[Sayonarax]

What patch?

Do you mean a yum update will patch this bug?

[innerspace]

Lot of hype over this but to be honest it does seem a little exaggerated.

Not saying that its not a serious vulnerability, it is since it essentially offers a way to gain full control of any "fully" vulnerable machine.

But the numbers of "vulnerable" computers being thrown around (50 or 500 million I think) is far, far greater than the number of actually compromisable machines.

My PC and all servers were technically vulnerable until they got patched (and patched a second time).

But that said, none of them were actually compromisable by any currently known method.

This bug is only an issue if attackers can actually reach something which is publically exposing bash.

In the 90's any interactive functionality in websites was often coming via CGI scripts, which could often include bash exposure.

But for 10-15 years that has been considered a very bad practice with much better, safer and more powerful methods available (PHP/rails/.NET etc).

While apache, or more commonly scripting languages such as PHP can expose bash very few do. Many hosts even disable functions like exec() due to the security concerns it raises (excluding this new issue).

OpenSSH (not to be confused with OpenSSL of heartbleed fame) is present on the vast majority of linux servers as a popular remote access to terminal shells, such as bash.

So SSH is confirmed to be vulnerable, but only after authentication.

If attackers have a valid SSH login they can take over your machine now (until you upgrade bash).

But, if hackers had a valid SSH login to your server before, even with limited permissions, you would still have been at risk unless your security measures are 110% and the hackers skill under 109%.

DHCP, used by your router to assign an IP address to your computer, is also supposed to have some potential vulnerabilities.

This could prove a good method to piggyback past firewalls, but would get you inside a secure network rather than a secure server.

But these kind of devices are likely to be the biggest long term risk....

Desktops and servers will popup messages telling you that updates are available, or even update security patches automatically.

But when did your router last ask you to update it? Have you ever?

What about your wifi? home theatre? Smart lightbulbs? Smart TV? CCTV system? Baby monitor?

These devices rarely update, if ever. Some have mechanisms built in, some would need returning to the manufacturer to upgrade.

So any linux based devices which use a version of bash released in the 25 years leading up to mid september 2014 could be vulnerable forever.

And as time goes on hackers will find more creative ways to detect and compromise these legacy devices.

With heartbleed if a machine was online and running affected versions it could be compromised. But the compromise was read only unless you hit gold and read passwords or access data.

With shellshock a larger number of ducks need to fall into line - unpatched bash, accessible machine and bash accessible to outside users. Only if all of this is true does it then become much, much more dangerous than heartbleed.

[Chicog]

Thread already open in Linux forum

http://www.thaivisa.com/forum/topic/763320-%E2%80%8Bbigger-than-heartbleed-bash-bug-could-leave-it-systems-in-shellshock/#entry8445301

[ITGabs]

Actually there is quite good security like CageFS in CloudLinux to box jail ssh, mod_ruid2, su_exec su_php mod_fgid etc now is quite a standard and almost all the big hosting companies like dreamhost hostgator and etc offer jailed ssh and without disabled functions in the php.ini (maybe only dl extensions)

My point is that you don't need to access SSH to exploit a server, you can use shell functions in Perl, PHP and you can inclusive add it into a cron using web interface like plesk cpanel or webmin

for example look for a not maintained Wordpress sites using a TimThumb in plugins or themes or super cache, with both of them you can execute remote code, using that vulnerable sites test a symlink race exploit, almost 90% of the servers is not correctly patched, find one account that can execute shell commands,cron,ssh passwords and done, and this is only one way there are thousand of vulnerable code, sure small hosting companies will be affected, I posted here because I know a lot of people here have small companies and they do the updates with luck two times in the year.

I was hacker before, was funny (I edited my post) but this is not the right place or identity xD

This is a version to test in php (for people without ssh access)

<?php
echo `env x='() { :;}; echo vulnerable' bash -c "echo this is a test" | grep vulnerable`;
?>

[phazey]

All i can say was that it was an utter bawl ache patching 20k servers these past two days

[Chicog]

All i can say was that it was an utter bawl ache patching 20k servers these past two days

20k servers? Do you do IT Support for 7/11 or something?

Edited September 27, 2014 by Chicog

[phazey]

All i can say was that it was an utter bawl ache patching 20k servers these past two days

20k servers? Do you do IT Support for 7/11 or something?

Global infrastructure for a large Net Security firm. That's why we had to do it so quickly.....

[Chicog]

All i can say was that it was an utter bawl ache patching 20k servers these past two days

20k servers? Do you do IT Support for 7/11 or something?

Global infrastructure for a large Net Security firm. That's why we had to do it so quickly.....

Well you earned your money, well done!

[Chicog]

Looks like you might get some more overtime.

Patched systems remain vulnerable.

The Shellshock vulnerability in the commonly used Bash command line interpreter shell is likely to require more patches, as security researchers continue to unearth further problems in the code.

Google security researcher Michal "lcamtuf" Zalewski has disclosed to iTnews that over the past two days he has discovered two previously unaddressed issues in the Bash function parser, one of which is as bad as the original Shellshock vulnerability.

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

Common vulnerabilities and exposures numbers CVE-2014-6277 and CVE-2014-6278 have been assigned to the vulnerabilties.

Zalewski has discussed the vulnerabilities with the groups that volunteer to maintain Bash and to Linux OS vendors directly involved in attempting to resolve the original Shellshock vulnerability.

"We want to give people some time to update before we share additional details," Zalewski said.

After the initial disclosure of the Shellshock bug, Zalewski and fellow security researchers Florian Weimer and Tavis Ormandy expressed concern over the continued exposure of the underlying attack surface in Bash.

The three researchers have called for a more robust approach to addressing the issue, and also found a troubling pattern of vulnerabillities in CVE-2014-7186, CVE-2014-7187 and CVE-2014-7169 that Zalewski said suggests the Bash parser may be unsafe.

There is an unofficial patch ready, Zalewski said and he recommends users apply it urgently.

"Somewhere in the middle of all this, Florian Weimer developed an unofficial patch that mitigates this and all future problems in the bash function parser by shielding it from remotely-originating data.

"As of today, this patch is already shipping with several Linux distributions, but many users will need to update manually," he added.

Read more: http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-ineffective.aspx#ixzz3EnBAxUZA