Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

seclists.org

Post reply on HN
Print view View original

71–80 of 226 posts

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#71

Post by lovelearning »

sounds wrote: post #52
lovelearning wrote: post #51

I'd like to check if my home router is vulnerable to this over HTTP or DHCP or SSH. Is there any tool I can use, like the heartbleed folks had? My router runs DD-WRT (an old version which I can't upgrade), has an administration web page and has ssh access enabled. It does not have remote web administration enabled. Any tips?

SSH in and look at your iptables. If any inbound ports are open besides state RELATED,ESTABLISHED (required for NAT), delete those rules. Reboot the router and verify that the lines do not reappear -- you may need to add a startup script to your admin page that deletes the rules on each startup. That doesn't prevent an XSS attack on the admin page if you view a malicious web page on a browser within your home network…

Thank you!

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#72

Post by cft »

agwa wrote: post #23
jtchang wrote: post #22

I'm starting to see automated attack attempts using HTTP_HOST headers set to '() {'.

Are you seeing any from IP addresses besides 209.126.230.72, which is Robert Graham scanning the Internet[1]? [1] http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in...

I am seeing:

  web22 ~> grep "() {" logs/access_log
  209.126.230.72 - - [24/Sep/2014:17:16:46 -0700] "GET / HTTP/1.0" 200 5733 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" 13378 () { :; }; ping -c 23 209.126.230.74 80 74529

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#73

Post by [deleted] »

skuhn wrote: post #57
jvreeland wrote: post #50

Does anyone know what Apples policy on fixing this might be? I understand why they ship with an older version of bash and other GNU userspace tools but is there a precedent they've set for backporting?

They won't have to backport the fix, there is a patch directly against bash-3.2 (which ships in OSX): http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 They do update bash occasionally, even though it is trapped forever in a pre-GPLv3 world: http://www.opensource.apple.com/source/bash/ . For instance, bash-86.1 shipped in 10.8 and bash-92 shipped in 10.9. I don't know if they will hop right on this (and per…

[deleted]

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#74

Post by atmosx »

rcthompson wrote: post #63

I run an Ubuntu server in my closet as a general-purpose file server and such, mostly just for my own use or for sending files to friends. I have just turned it off and disabled all port forwards to it, and I will wait at least a few days and check for a more definitive fix before opening it back up to the internet. I recommend anyone in a similar situation do the same.

Why?

Why don't you uninstall bash all-together? Most programs should be using '/bin/sh' and not bash.(IIRC Linux might have symlink between the two, which is awful) You could install zsh.

You could add further security layers, harden your network-level access, monitor your logs and so forth. Security is a set of policies. If you think that there are users who have unauthorized access to your system or you run bash-enabled cgi scripts, well then disable them (you shouldn't be using those in first place anyway), lock-out unauthorized users, change your passwords, etc.

The panic is for admins who handle systems with multiple users (universities, etc.) and offer (even restricted) shell access. For these guys might be hard to sleep at night, but for someone running a fileserver, shouldn't really make any diff.

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#75

Post by finnn »

Soliah wrote: post #45
vhost- wrote: post #35

Earlier quoted context omitted.

I typically use the CVE RSS feeds http://nvd.nist.gov/download/nvd-rss.xml and plug them into an IRC bot.

Great idea. Setup IFTTT to do the same to a Slack channel: https://ifttt.com/recipes/206224-post-nvd-vulnerability-noti...

Doesn't slack have it's own RSS bot? Why not use that?

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#76

Post by Soliah »

finnn wrote: post #75
Soliah wrote: post #45

Earlier quoted context omitted.

Great idea. Setup IFTTT to do the same to a Slack channel: https://ifttt.com/recipes/206224-post-nvd-vulnerability-noti...

Doesn't slack have it's own RSS bot? Why not use that?

Ah cool didn't know Slack had RSS integration.

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#77

Post by ambrop7 »

Can someone explain why bash is evaluating and looking for function definitions in every environment variable? What would be broken if this entire "feature", whatever it is, was completely disabled?

That's almost like a C compiler looking for C programs in string literals. It just doesn't make sense to me.

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#78

Post by bodyfour »

bodyfour wrote: post #20
danielweber wrote: post #13

Earlier on a mailing list someone pointed out that there is still an awful lot of string processing going on by bash even after this afternoon's fix. So further bugs were likely to be found now that everyone is constantly sniffing around the place.

That was one of my first thoughts as well. There is way too much code that's being exposed here. This will be a gift that keeps on giving. For people who want to do environment sanitation, do we know what values can trigger this 'feature'? Is it only "()" as the first two characters? First two non-whitespace characters?

Answering my own question, since I got curious enough to look a the source:

    if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
So it has to start with that four character sequence exactly.

I hope there are patches to webservers, sshd, etc to cleanse environment variables with that value. Even if bash is fixed, it is too risky to send untrusted strings to its parser.

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#79

Post by bodyfour »

skuhn wrote: post #57
jvreeland wrote: post #50

Does anyone know what Apples policy on fixing this might be? I understand why they ship with an older version of bash and other GNU userspace tools but is there a precedent they've set for backporting?

They won't have to backport the fix, there is a patch directly against bash-3.2 (which ships in OSX): http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 They do update bash occasionally, even though it is trapped forever in a pre-GPLv3 world: http://www.opensource.apple.com/source/bash/ . For instance, bash-86.1 shipped in 10.8 and bash-92 shipped in 10.9. I don't know if they will hop right on this (and per…

OS/X does use bash as /bin/sh unfortunately so it is fairly vulnerable. Probably most people won't be affected though since there aren't many good attack vectors against a client machine, and not many people are still using macs for servers.

I don't think that the issue is overblown at all though. CGI is old and crusty but it's sitting in all sorts of random places. All you need to do is to find a script that will call system()/popen()/etc and it's game over. Plus those are just the sorts of forgotten environments that people won't remember to patch. I'm sure there will be thousands of exploitations in the next couple days. This is a big deal.

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#80

Post by asveikau »

ambrop7 wrote: post #77

Can someone explain why bash is evaluating and looking for function definitions in every environment variable? What would be broken if this entire "feature", whatever it is, was completely disabled? That's almost like a C compiler looking for C programs in string literals. It just doesn't make sense to me.

From reading one of the threads I think I get it. It allows you to "export" functions (export -f). I guess that's passed via the environment, so process start scans for them.

The issue is that it was evaluating the whole variable to get them into your process. So if you have "garbage" at the end it's interpreted as the next command following the function definition.

Post reply on HN