[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] =?utf-8?B?UmU6IENWRS0yMDE0LTYyNzE6IHJlbW90ZSBjb2RlIGV4ZWN1dGlvbiB0aHJvdWdo?= =?utf-8?
From:       "=?utf-8?B?TWFyayBSIEJhbm5pc3Rlcg==?=" <mark () proseconsulting ! co ! uk>
Date:       2014-09-26 8:54:40
[Download RAW message or body]

[Attachment #2 (text/plain)]

Testing patch 25 and 26 from Chet, it looks to me like this is still an incomplete fix.  The \
third vulnerability I'd like to report is the feature itself in bash that allows functions to \
be passed in the environment, e.g. $ env ls='() { echo vulnerable; }' bash -c ls

This allows an attacker to replace a command used by a bash script with arbitrary code.  It is \
then down to an attacker to find a suitable command that the bash script (or any child shells) \
might call without a path component.

I can't see this being a problem for Apache custom headers (the variable name is turned to \
uppercase and prefixed by HTTP_), nor sudo commands if env_reset is on (the default), but this \
continues to be a major vulnerability for setuid/setgid scripts (S_ISUID or S_ISGID) where the \
environment is preserved.

One might say that importing functions from the environment is a feature, not a bug, and that \
the security of setuid/setgid has long been questioned.  However, folk rely on it nonetheless, \
and bash makes it exceptionally easy to exploit.  I've demonstrated a root exploit this morning \
using this vulnerability with the latest bash source code and patches. 

Prior to Chet's patches I could also do:

$ env /bin/ls='() { echo vulnerable; }' bash -c /bin/ls

... but with patch 25 this permutation is disallowed.

I'm not sure what the answer should be here.  Remove the feature from bash and live with the \
few programs that break?  Patch every OS to clear the environment on setuid/setgid and live \
with a few other programs that might break?  Tell everyone to stop using setuid/setgid now and \
forever?

Any other suggestions ... ?

Best regards,
Mark R. Bannister.



[prev in list] [next in list] [prev in thread] [next in thread]