|
Message-ID: <54243561.5020905@debian.org> Date: Thu, 25 Sep 2014 16:31:45 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: CVE-2014-6271: remote code execution through bash On 25/09/14 16:17, John Haxby wrote: > At some stage scripts are going to break, especially if they're relying > on command, but this whole exercise leaves me feeling uneasy. ssh and > sudo both restrict environment variables, but I just tried this: > > $ xxx='() { echo hello; }' su > Password: > # xxx > hello > > Of course, su isn't affected, but if I drop one of these in for an > overly-trusting admin who runs su on my terminal ... An overly-trusting admin who runs su on your terminal is already doomed, because the su in your $PATH could be something that prompts for a password, captures it, stuffs it into the real su's stdin while suppressing the password prompt, then pipes su's stdout and stdin to/from the terminal. But, more generally, as I said while dealing with a D-Bus- and environment-variable-related vulnerability, I think anything that starts in a potentially attacker-controlled environment, and escalates its privileges, should filter the environment through a (small!) whitelist of known-good variables before it does anything non-trivial. pkexec is an example of a setuid executable that is on the "good list" here: if you don't try to execute one of its few "good" variables (e.g. LANG, TERM) as the name of a command, then you won't execute an exported function of this type. Unfortunately, this is not consistently done, and in particular su(8) has not traditionally sanitized the environment in this way before invoking PAM modules (which are a plugin architecture, hence an unbounded attack surface). The particularly nasty thing about CVE-2014-6271 is that the name of the variable is not relevant when exploiting that vulnerability, only the value, which means it will bypass many whitelists of safe variable names. I don't think that reduces the value of filtering attacker-supplied environments through a whitelist when not using a version of bash that is vulnerable. S
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.