oss-sec mailing list archives
Re: Healing the bash fork
From: Eric Blake <eblake () redhat com>
Date: Mon, 29 Sep 2014 09:59:47 -0600
On 09/29/2014 09:24 AM, Florian Weimer wrote:
On 09/28/2014 03:39 AM, Chet Ramey wrote:OK, here are the more-or-less final versions of the patches for bash-2.05b through bash-4.3. I made two changes from earlier today: the function export suffix is now `%%', which is not part of a the set of valid variable name characters but avoids any potential problems with including shell metacharacters in the name; and this version refuses to import shell functions whose name contains a slash, for reasons I discussed earlier.Chet, thanks for posting an official version of the prefix/suffix patch. I looked at how the “%%” encoding works with Debian's “at” (which is also used by Fedora and downstreams). Unfortunately, it does not address the issue, “at” still prints error messages, both with dash as /bin/sh and bash.
'at' is already broken, independently of bash. For example: https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00300.html echo pwd | env "/tmp/exploit=me" at tomorrow produces a shell script with these lines: #!/bin/sh ... /tmp/exploit=me; export /tmp/exploit So even on Debian, where /bin/sh is dash, this script attempts to execute the file named /tmp/exploit=me, possibly under the privileges of 'at' rather than as the user that created the file. No bash needed. So let's not use 'at' as justification for changing bash, but instead lobby to get 'at' fixed.
As a result, I wonder if a suffix which is actually within the shell variable syntax wouldn't be a better choice (e.g., three randomly chosen alphanumerics), as that would make the “at” environment serialization code work again.
No. Absolutely not. The moment that you pick a suffix which collides with VALID environment variable names, you have opened yourself up to exploitation. And we _still_ have the issue that upstream bash hasn't fully isolated functions to be completely independent of variables. As I've already pointed out on the bash list: function a=b () { :; } export -f 'a=b' export FUNC_BASH_a=one bash -c 'echo "$FUNC_BASH_a" Per POSIX, this MUST output "one", not "() { :; }" - we aren't quite there yet. But your proposal to use alphanumerics as the suffix instead of invalid identifiers will make it all the more apparent when collisions like this occur.
(I'm not concerned about “at” specifically, we'll change it anyway, it's about similar code out there which we don't know about it yet.)
Any code which is not robust to non-identifiers in the names of environment variables already needs to be patched, independently of bash. True, bash's change is making it all the more obvious that there are non-identifiers in the environment, but the problem is not bash's.
Eric, does “%%” even work for Cygwin, or does it cause strange effects there? (For the Windows shell, “%” is the variable starter character, a bit like “$” in sh-type shells.)
Cygwin has no problem with %% in the environment name. Regardless of the version of bash: $ uname CYGWIN_NT-6.2-WOW64 $ env 'a%%=foo' sh -c 'env | grep foo' a%%=foo I don't know if mingw has a problem, but if so, the mingw developers need to propose an alternate solution.
Related to that is that we should try to converge back to uniform bash behavior across distributions. Right now, the majority seems to use “()” as the suffix (which is problematic, per the above), and they also reject characters such as “.:-” in import function names (a restriction which was inherited from the first patch which only tried to block command execution). The latest upstream patch uses “%%”, and allows anything allowed in a regular function definition, except absolute pathnames. I'm not sure how to move towards a common solution. I think avoiding non-serializable environments could be a compelling reason to switch the suffix, but “%%” does not provide that.
I see two probably solutions for 'at'; we need something along these lines ANYWAYS because of the 'env /tmp/exploit=me' situation: 1. ignore ALL non-identifiers, making it impossible to export functions into a bash script run by 'at' (anyone relying on that will now have to define their functions as part of their script startup, instead of inheritance) 2. special-case %% identifiers to generate code in the 'at' script to require #!/bin/bash and use 'export -f' on the function name substring (in other words, make 'at' become smarter about the function conventions of bash). But I see no reason to move away from %% suffixing.
(From a security POV, *requiring* that imported functions contain at least one special character would actually be best, but obviously, that's not backwards-compatible.)
We already discussed that battle, and decided that the security of NO collisions is worth the backwards-compatible break. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- Re: CVE-2014-6271: remote code execution through bash, (continued)
- Re: CVE-2014-6271: remote code execution through bash Michal Zalewski (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash Hanno Böck (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 28)
- Healing the bash fork (was: Re: [oss-security] CVE-2014-6271: remote code execution through bash) Florian Weimer (Sep 29)
- Re: Healing the bash fork Eric Blake (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Tavis Ormandy (Sep 29)
- Re: Healing the bash fork David A. Wheeler (Sep 29)
- Re: Healing the bash fork John Haxby (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Chet Ramey (Sep 29)
- Re: Healing the bash fork gremlin (Sep 29)
- Re: Healing the bash fork Florian Weimer (Sep 30)
- Re: Healing the bash fork Gennady Kupava (Sep 30)
- Re: Healing the bash fork gremlin (Sep 30)