HIGHEST LEVEL 10 CERT/NIST ALERT TODAY: BASH bug brings down linux/MacOS like house of cards

[Thad Floryan]

I caught the news flash at the Reuters site about 20 minutes ago:

New 'Bash' software bug may pose bigger threat than 'Heartbleed'
http://www.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUSKCN0HJ2FQ20140924
http://uk.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUKKCN0HJ2FQ20140924

Vulnerability Summary for CVE-2014-6271 - NVD - Detail
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

Bourne Again Shell (Bash) Remote Code Execution Vulnerability
https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability

Bourne Again Shell (Bash) Remote Code Execution ...
http://www.pcisecuritypolicies.com/bourne-again-shell-bash-remote-code-execution-vulnerability/

Thad

[David Kaye]

Post by Thad Floryan
New 'Bash' software bug may pose bigger threat than 'Heartbleed'

Oh, they're slipping. Names like Heartbleed and Cryptolocker are
intriguing; Bash sounds like something some dude cooked up in his bedroom
while his parents were shopping.




---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Thad Floryan]

Post by David Kaye

Post by Thad Floryan
New 'Bash' software bug may pose bigger threat than 'Heartbleed'

Oh, they're slipping. Names like Heartbleed and Cryptolocker are
intriguing; Bash sounds like something some dude cooked up in his bedroom
while his parents were shopping.

Hi David,

Funny!

Seriously, it's the main program used at the terminal on *BSD,
Linux, MacOS X, Solaris and UNIX systems:

http://en.wikipedia.org/wiki/Bash_%28Unix_shell%29

Thad

[David Kaye]

Post by Thad Floryan
Seriously, it's the main program used at the terminal on *BSD,

Oh *that* bash. I thought they'd just run out of names.




---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Thad Floryan]

Post by Thad Floryan
New 'Bash' software bug may pose bigger threat than 'Heartbleed'
http://www.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUSKCN0HJ2FQ20140924
http://uk.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUKKCN0HJ2FQ20140924
Vulnerability Summary for CVE-2014-6271 - NVD - Detail
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
Bourne Again Shell (Bash) Remote Code Execution Vulnerability
https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability
Bourne Again Shell (Bash) Remote Code Execution ...
http://www.pcisecuritypolicies.com/bourne-again-shell-bash-remote-code-execution-vulnerability/

To check whether you are vulnerable, enter the following 'env x= ...'
and you'll either see "vulnerable" or not

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Thad

[Rob Warnock]

Thad Floryan <***@thadlabs.com> wrote:
+---------------
| To check whether you are vulnerable, enter the following 'env x= ...'
| and you'll either see "vulnerable" or not
|
| $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
| this is a test
|
| $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
| vulnerable
| this is a test
+---------------

Even with a "fixed" Bash, you should also try the tests given in
the comments in the bug report noting that the fix is "incomplete",
starting here:

https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23
Tavis Ormandy at 2014-09-24 17:17:00 EDT
This fix seems incomplete. You can for sure overwrite files
at least, like this: [...]

where he shows how even with the "fixed" version of "bash"
you can still cause files to be overwritten, and then
generalizing that into execution of arbitrary code.
Does this:

env -i X='() { (a)=>\' bash -c 'date'

cause an empty file named "date" to be created in the
current directory? If so, you still have (part of) the bug".

And for those wondering how to inject such weird environments
into a system without any authentication, consider what happens
with old-fashioned CGI scripts with the environment variable
named "QUERY_STRING". [And remember than on Linux system,
"/bin/sh" is really Bash.]


-Rob

-----
Rob Warnock <***@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[Rob Warnock]

p.s. I just wrote:
+---------------
| Even with a "fixed" Bash, you should also try the tests given in
| the comments in the bug report noting that the fix is "incomplete",
| starting here:
|
| https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23
| Tavis Ormandy at 2014-09-24 17:17:00 EDT
| This fix seems incomplete. You can for sure overwrite files
| at least, like this: [...]
+---------------

They've opened a new CVE-2014-7169 to deal with the
incomplete fix, and the Red Hat bug for that is 1146319:

https://bugzilla.redhat.com/show_bug.cgi?id=1146319
Bug 1146319 - (CVE-2014-7169) CVE-2014-7169 bash:
code execution via specially-crafted environment
(Incomplete fix for CVE-2014-6271)

It contains useful pointers back to the previous bug# and CVE,
and suggests that they [the "upstream" developers] have found
a candidate patch for the remaining issues, but I don't know
if it's made it into any distribution channel(s) yet...


-Rob

-----
Rob Warnock <***@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[Keith Keller]

Post by Rob Warnock
And for those wondering how to inject such weird environments
into a system without any authentication, consider what happens
with old-fashioned CGI scripts with the environment variable
named "QUERY_STRING". [And remember than on Linux system,
"/bin/sh" is really Bash.]

I was under the impression that most web servers would exec() a CGI
script, not call a shell to start it. So the problem (as the RedHat
security blog entry noted) was if a CGI itself called a shell to do
something (which is rare but not rare enough).

--keith

[Rob Warnock]

Keith Keller <kkeller-***@wombat.san-francisco.ca.us> wrote:
+---------------
| Rob Warnock <***@rpw3.org> wrote:
| > And for those wondering how to inject such weird environments
| > into a system without any authentication, consider what happens
| > with old-fashioned CGI scripts with the environment variable
| > named "QUERY_STRING". [And remember than on Linux system,
| > "/bin/sh" is really Bash.]
|
| I was under the impression that most web servers would exec() a CGI
| script, not call a shell to start it.
+---------------

If a CGI "script" is actually a native-code program (written
in C, Ada, Common Lisp, whatever), then the web server can
"exec()" it. But if it's an actual shell script [a text file
with the execute bit set], then the web server has no choice
but to exec() "/bin/bash" with the script name as an argument.
[And if you're thinking about "#!/bin/sh" scripts, see above
comment about "/bin/sh" really being "bash".]

+---------------
| So the problem (as the RedHat security blog entry noted) was
| if a CGI itself called a shell to do something (which is rare
| but not rare enough).
+---------------

That too. Or calls something that calls "system()", which internally
fork/execs a shell. Or calls something that calls "popen()".
Etc., etc., &c.


-Rob

-----
Rob Warnock <***@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[Keith Keller]

Post by Rob Warnock
|
| I was under the impression that most web servers would exec() a CGI
| script, not call a shell to start it.
+---------------
If a CGI "script" is actually a native-code program (written
in C, Ada, Common Lisp, whatever), then the web server can
"exec()" it. But if it's an actual shell script [a text file
with the execute bit set], then the web server has no choice
but to exec() "/bin/bash" with the script name as an argument.

I'm not sure that's right. I think it looks at the shebang line and
exec's that. I don't think I've seen Apache, for example, start bash to
run a Perl CGI.

Post by Rob Warnock
[And if you're thinking about "#!/bin/sh" scripts, see above
comment about "/bin/sh" really being "bash".]

I am thinking of "#!/usr/bin/perl" scripts, or other scripts where the
shebang line is not a shell. Those should not be vulnerable unless
they subsequently do a system() or exec() which potentially calls bash.

Yes, CGI scripts written in bash are certainly vulnerable. I don't know
a whole lot of those.

--keith

[Eli the Bearded]

And remember than on Linux system, "/bin/sh" is really Bash.

On many Linux systems, but not all. For example, /bin/sh has been
dash not bash since release 6.10 of Ubuntu and the "Squeeze" verion
of Debian:

http://en.wikipedia.org/wiki/Almquist_shell

dash is the Debian variant of ash, the Almquist shell.

Elijah
------
bash as sh was almost as stupid as environment variables that get run as code