oss-sec mailing list archives
Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability)
From: Kurt Seifried <kseifried () redhat com>
Date: Fri, 26 Sep 2014 12:07:34 -0600
On 26/09/14 11:55 AM, Rich Felker wrote:
On Fri, Sep 26, 2014 at 01:41:45PM +0100, Mark R Bannister wrote:Arguments that people shouldn't have setuid shell scripts don't stack up, because even if you write your setuid program in some other language, you might unwittingly exec something written in bash. As /bin/sh is symlinked to /bin/bash in RHEL, the moment you call out to the system to do a piece of work for you, you're at risk of invoking bash and thereby being vulnerable to a root exploit. For example: $ env bzip2='() { echo vulnerable >&2; }' /usr/bin/bzdiff /tmp/file1.bz /tmp/file2.bz $ env test='() { echo vulnerable >&2; }' /usr/bin/ldd /usr/bin/gcc So this is not about whether or not someone has written a setuid shell script. This has uncovered a potential new exploit for any setuid program. Indeed the very first setuid program that I discovered this exploit with was a binary (compiled C program) that happened to exec ldd while it was running. I don't think this issue can be swept under the carpet.Any setuid program that's execing an external program that was not also designed to be run setuid, without scrubbing the environment and other environmental state (rlimits, inherited file descriptors, ...), or else fully dropping privileges to the original invoking user, is a gaping security hole already. This has nothing to do with bash. Rich
This is a classic case of "yes the correct thing to do is..." but the reality is "we should fix this centrally rather than try to make everyone do the right thing (aka boiling the ocean)". This is like tmp vulns, it's 2014, the solution for tmp vulns is polyinstantiated /tmp per user, and per application /tmp dirs in addition to this. Solve it once centrally (e.g. in PAM/systemd) and boom, done. We should always try to do the best/safest thing because most devs are going to try to do the most insanely dangerous thing. -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability), (continued)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Chet Ramey (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Christos Zoulas (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Loganaden Velvindron (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Guido Berhoerster (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Mark R Bannister (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Simon McVittie (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Rich Felker (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Kurt Seifried (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Rich Felker (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Rich Felker (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Kurt Seifried (Sep 26)