Huge bash exploit CVE-2014-6271 - Page 2

deadite66 · 27-09-2014, 17:26

My rss server picked the blog update at 10:39am

qasdfdsaq · 29-09-2014, 01:24

Not sure how that helps, unless your Ubuntu server runs system updates off an RSS blog...

deadite66 · 29-09-2014, 05:37

it helped to answer 'your' question of when the update came out, sometime around 10am.

Qtx · 29-09-2014, 12:38

Still not over...

Further flaws render Shellshock patch ineffective

Quote:

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.

There are a few more CVE's other than those listed too.

List of PoCs for various services

Makes you wonder if GCHQ and the NSA are weeping that these have been found :p

qasdfdsaq · 29-09-2014, 14:43

Quote:

Originally Posted by deadite66

it helped to answer 'your' question of when the update came out, sometime around 10am.

I didn't ask when the update came out, but that's good to know. I was just puzzled as to why the auto-update didn't ... auto update.

---------- Post added at 14:13 ---------- Previous post was at 14:11 ----------

Quote:

Originally Posted by Qtx

Still not over... Further flaws render Shellshock patch ineffective There are a few more CVE's other than those listed too. List of PoCs for various services Makes you wonder if GCHQ and the NSA are weeping that these have been found :p

So even the second patch is ineffective? Funnily reminds me of the whole Heartbleed debacle again.

Literally thousands upon thousands of companies including high-end tech vendors relying on 'free' software to power their product yet nobody pays any attention to the code or contributes to development until a major flaw is found. Then all of a sudden everyone starts caring and paying attention and dozens upon dozens of ancient flaws come to light...

---------- Post added at 15:43 ---------- Previous post was at 14:13 ----------

Here's something else I'm concerned about - it looks like Ubuntu aren't going to release fixed versions for even their second most recent edition (13.10) or the one before that (13.04) which I expect will leave a lot of vulnerable systems unpatched. Sure, servers should be running LTS but I know a good few that aren't. Redhat on the other hand have just about patched everything released in the last decade.

tweetiepooh · 29-09-2014, 17:01

But you pay for Redhat while Ubuntu is free.

OpenSuse and Mint have patches for both, whether this secures things remains to be seen. It does highlight a big issue in testing.
Most testing works through scenarios to show the program works as expected. It doesn't (and realistically can't) test for it behaving "badly". One way to do that is to give it to a group of children/teens and just let them loose, maybe add a bit of hacking/cracking resource to show what can be done. This won't necessarily cover all the bases but it will cover some of them. Too many times I've seen code released fail because a user does something unexpected that's not catered for, some take great pleasure in trying this.

qasdfdsaq · 29-09-2014, 17:14

Well, I don't pay for RedHat, plus the upstream fixes from RedHat make it into CentOS (which is completely free) as well.

That said I personally (when I used to write software anyway) made a habit of always testing each step or function of everything I wrote with broken or invalid data just to make sure it was fully robust, and also making sure every possible exception thrown gave some sort of human-readable error message. I'm guessing that's also what the security researchers discovering these holes are doing.

Qtx · 29-09-2014, 20:01

The first two patches do stop those holes being used but the new vulnerability found isn't much different yet does get through. They should really take the plunge and just release a patch which stops Bash parsing the data itself, even if breaks some setups. Not that hard for them to do it for the other versions too.

Bash is ancient so when made no one was thinking about security. Not even sure if the usual automatic fuzzing methods would have found these particular holes, not that they were about back then anyway.

Qtx · 29-09-2014, 22:02

Some sites that will test urls for various methods of exploiting this:

http://www.shellshocktest.com/
http://shellshock.brandonpotter.com/
http://bashsmash.ccsir.org/

Can't 100% vouch for the trustworthiness of these sites and what they do with the test results, so use of your own back. Don't think there will be any issues using them though.

If you are using debian or Ubuntu and are worried doing all the upgrades may break things, you can use this to just update bash:

Code:

sudo apt-get update && sudo apt-get install --only-upgrade bash

qasdfdsaq · 30-09-2014, 01:18

Similarly for Redhat/centos:
yum update bash

Pretty easy, and tbh, anyone managing any sort of environment where auto-updates aren't feasible should know this stuff off by heart anyway.

Qtx · 30-09-2014, 15:17

Quote:

OS X bash Update 1.0
Bash

Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5, OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5

Impact: In certain configurations, a remote attacker may be able to execute arbitrary shell commands

Description: An issue existed in Bash's parsing of environment variables. This issue was addressed through improved environment variable parsing by better detecting the end of the function statement.

This update also incorporated the suggested CVE-2014-7169 change, which resets the parser state.

In addition, this update added a new namespace for exported functions by creating a function decorator to prevent unintended header passthrough to Bash. The names of all environment variables that introduce function definitions are required to have a prefix "__BASH_FUNC<" and suffix ">()" to prevent unintended function passing via HTTP headers.

Qtx · 01-10-2014, 13:08

VMware Bash bulletin, showing which of their products need patching and if they have released the patch

Ignitionnet · 01-10-2014, 21:33

Glad most of my employer's products have no CGI in the web interface and no access to BASH without having a level of access to the CLI which gives root on BASH via a standard CLI command anyway.

Still have flappy customers contacting daily asking for patches, naturally, but pointed out that the steady flow of CVEs mean they either wait a couple of days and get one roll-up patch or they have the pleasure of a .3, .4, .5, .6... etc version and disrupt their production networks repeatedly.

qasdfdsaq · 02-10-2014, 00:27

Quote:

Originally Posted by Qtx

VMware Bash bulletin, showing which of their products need patching and if they have released the patch

Thankfully no reasonably recent version of their hypervisors are affected, that said most of our infrastructure runs on Xen instead of VMWare and yesterday's XSA-108/CVE-2014-7188 is causing panic among Xen sysadmins the world over...

Apple finally released their shellshock fix yesterday too, after several days delay, Citrix seems to think it's a non-issue

Ignitionnet · 02-10-2014, 19:27

Well here's how to do a vulnerable server via XSS. *Sigh*