Security advisories for Monday

[Posted September 29, 2014 by ris]

Debian has updated chromium-browser (multiple vulnerabilities).

Fedora has updated libvncserver (F20: multiple vulnerabilities), nodejs (F20; F19: denial of service), perl-Data-Dumper (F20: denial of service), and v8 (F20; F19: multiple vulnerabilities).

Mageia has updated bash (code injection, command execution) and kernel (MG3: denial of service).

Mandriva has updated perl-XML-DT (file overwrites).

openSUSE has updated bash (13.1, 12.3; 12.3; 13.1; 11.4; 13.2: multiple vulnerabilities), dbus-1 (13.1; 12.3: multiple vulnerabilities), kernel (11.4: multiple vulnerabilities), geary (13.1: TLS certificate issues), bash (11.4: command execution), mozilla-nss (13.1, 12.3: signature forgery), NSS (11.4: signature forgery), php5 (11.4: multiple vulnerabilities), php5 (11.4: more vulnerabilities), srtp (13.1: denial of service), and wireshark (13.1, 12.3: multiple vulnerabilities).

Slackware has updated firefox (multiple vulnerabilities), thunderbird: (multiple vulnerabilities) and seamonkey (multiple vulnerabilities).

SUSE has updated bash (SLE11, SLE10: multiple vulnerabilities) and mozilla-nss (SLES11 SP2: signature forgery).

bash

Posted Sep 29, 2014 19:47 UTC (Mon) by proski (subscriber, #104) [Link] (17 responses)

I think it's a safe bet that there will be more bash fixes soon. People have started looking at it. I wonder if a bash fork is coming.

bash

Posted Sep 29, 2014 20:00 UTC (Mon) by corbet (editor, #1) [Link] (16 responses)

I'd be surprised to see a fork. There don't appear to be maintainership issues here; it's more a matter of people having the time to actually look at and fix the code. What we're more likely to see is projects moving away from bash where a simpler shell will do; see Debian's use of dash, for example.

bash

Posted Sep 29, 2014 20:09 UTC (Mon) by proski (subscriber, #104) [Link] (15 responses)

The question is whether dash gets as many eyeballs as bash. Or maybe we should be talking of eyeballs per line of code?

bash

Posted Sep 29, 2014 21:01 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (14 responses)

eyeballs didn't help bash much when these issues were there for decades. functionally minimal implementations should have less security issues perhaps.

bash

Posted Sep 29, 2014 23:19 UTC (Mon) by sjj (guest, #2020) [Link] (13 responses)

Ubuntu started using dash as /bin/sh eight (!) years ago. Debian five years ago. I vaguely remember security (as smaller, simpler codebase) being mentioned, but maybe it was just driven by efficiency.

Still, I wish RH or at least Fedora would have followed suit. I'd rather keep shell script interpreter basic and encourage people to use a real scripting language instead (and yes, I break my own recommendation all the time).

Is symlinking dash to /bin/sh going to get Red Hat support respond with "sorrythatsnotasupportedconfigurationkthxbai"?

bash

Posted Sep 29, 2014 23:49 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (12 responses)

I don't think the dash change had anything to do with security (https://lwn.net/Articles/343924/) and anyone is welcome to volunteer to do the work on Fedora. Since the default interactive shell remains bash in Debian/Ubuntu, I don't see much of a security advantage.

As for RHEL, you will have to look at the support policy to answer that but if you should be ok if you can reproduce the issues with whatever is considered a supported configuration. Atleast this was the way custom kernels/kernel modules were treated.

bash

Posted Sep 30, 2014 1:36 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (4 responses)

But bash is intended to be an interactive shell, so it makes sense there. On the other hand, dash is *not* meant to be interactive, so I don't see why it not also being the default login shell is a reason to not make /bin/sh point to dash (or ash…really anything which is stricter about POSIX semantics so we don't get "but /bin/sh is bash anyways, so why should I have an accurate shebang line?" excuses).

bash

Posted Sep 30, 2014 2:17 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

I understand the technical accuracy part of it but the advantage of being more efficient on bootup which was the original reason for the change in Ubuntu/Debian is not there anymore since systemd doesn't rely on shell scripts for that but like I said, if someone wants to volunteer to do it, go ahead.

bash

Posted Sep 30, 2014 6:25 UTC (Tue) by eru (subscriber, #2753) [Link] (2 responses)

Even with systemd, /bin/sh gets invoked non-interactively all the time in a running Linux system as "glue". So making it fast and light-weight would still be a win.

bash

Posted Sep 30, 2014 10:53 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Has anyone measured that?

bash

Posted Sep 30, 2014 12:35 UTC (Tue) by eru (subscriber, #2753) [Link]

Has anyone measured that?

Dunno. The answer probably depends on the work-load, so I suspect there is no single answer. In any case it cannot hurt, except for the one-time work of fixing #!/bin/sh -marked scripts containing bash-isms.

bash

Posted Sep 30, 2014 7:31 UTC (Tue) by matthias (subscriber, #94967) [Link] (6 responses)

It is a security advantage. People who already have a login shell can already do everything, which this bug allows them to do. They just login and execute their code.

The security problems arise when the shell is invoked non-interactively and then executes injected code (by CGI scripts, from dhcp client, etc.). People could execute arbitrary code with root privileges on all computers in the LAN by just running a malicious DHCP server, when the DHCP client copies some data from the DHCP offer to environment variables and then executes a shell script using bash. This is a standard configuration in some distributions.

bash

Posted Sep 30, 2014 10:55 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

Couldn't that be fixed by restricting the bash feature like the latest Red Hat patch does?

bash

Posted Sep 30, 2014 17:51 UTC (Tue) by perlwolf (guest, #46060) [Link] (4 responses)

As long as the restrictions cover all of the security breaks that are in bash, including the ones that haven't been found yet! (I.e. not very likely.)

With bash being a interactive shell, it has lots of features that are useful to the interactive user - each of those features is a piece of code that could conceivably have a bug that allows non-interactive use run things in an unexpected way. Each pair of features (both the basic features and the extre interactive features) can have bugs in the way the two features affect each other - the number of such interactions goes up as the square of the total number of features.

The shells that don't have the extra interactive features have fewer places that might provide leaks, both in the code of the features that are omitted and in the myriad ways that those features could have interacted with the rest of the shell's capabilities. So, while the smaller shells can also have their own bugs, there are probably far fewer of them than with bash.

bash

Posted Sep 30, 2014 21:00 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

> the number of such interactions goes up as the square of the total number of features.

That's assuming the interactions between A and B is orthogonal to C. I wouldn't bet on this. I'd bet more on it being some exponential function.

bash

Posted Sep 30, 2014 21:13 UTC (Tue) by perlwolf (guest, #46060) [Link]

square is exponential :-)

You're right, of course - if there a a way of using the interaction between A and B, there will often be related interactions between C, D, ... with either A or B (or both) that can take advantage of the same effect in a similar way.

Bugs travel in swarms.

bash

Posted Oct 2, 2014 0:17 UTC (Thu) by nix (subscriber, #2304) [Link]

It's actually quite likely. The only code paths you need to consider to make bash secure against untrusted attackers are those that use the values of *arbitrary* environment variables to feed the parser. If the env vars aren't arbitrary, a successful attack requires the ability to set environment variables with particular names, whereupon the attacker could just set LD_LIBRARY_PATH or BASH_ENV; equally, if they could influence the command line they could execute arbitrary code in any number of ways (that's, y'know, the point).

bash

Posted Oct 2, 2014 4:59 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

That was useful. Thanks. I have posted

https://lists.fedoraproject.org/pipermail/devel/2014-Octo...