oss-sec mailing list archives
Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability)
From: Simon McVittie <smcv () debian org>
Date: Fri, 26 Sep 2014 14:06:21 +0100
On 26/09/14 09:54, Mark R Bannister wrote:
Patch every OS to clear the environment on setuid/setgid and live with a few other programs that might break?
Apache suexec, among other things, can't work if the environment is cleared. It needs to pass the CGI environment variables through, and is setuid itself. Properly-written setuid components are often a necessary part of letting unprivileged components benefit from privilege-separation (e.g. CGI scripts running with less privilege than the web server, with neither running as root). The problem is that not all setuid components are properly-written.
Tell everyone to stop using setuid/setgid now and forever?
Minimizing use of setuid/setgid, and making sure the setuid/setgid things are suitably hardened, is a good idea. However, tools for controlled privilege escalation (sudo, pkexec, Apache suexec) rely on setuid in order to work. There's a reason the feature exists at all. I still think a large part of the answer is "consider it to be a serious bug when a setuid/setgid tool does non-trivial things without first filtering its attacker-controlled environment through a whitelist". If it needs to pass environment variables through to a child, this pseudocode is a good pattern (AIUI, sudo does this): let saved_environ = copy of environ let environ = empty setenv(PATH = "/usr/bin:/bin") # or some other safe value setenv(HOME = "/") # ... and repeat for a few other well-known variables that are # often relied on if saved_environ["LANG"] has a safe value { setenv(LANG = saved_environ["LANG"]) # ... and repeat for a few other well-known variables # that can safely be passed-through if their values are # suitably constrained } parse options decide what to do do PAM authentication/authorization etc. drop privileges / set up privileges as necessary if configured to pass environment through { copy some or all of saved_environ back into environ } exec(child, child_args) Regards, S
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) Giles Coochey (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Ed Prevost (Sep 29)
- RE: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Sona Sarmadi (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Ramon de C Valle (Sep 29)
- 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) 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)