bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: demonstration of CVE-2014-7186 ShellShock vulnerability


From: Jean-Christian de Rivaz
Subject: Re: demonstration of CVE-2014-7186 ShellShock vulnerability
Date: Sat, 27 Sep 2014 15:04:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0

Le 27. 09. 14 07:53, Eric Blake a écrit :
[...]

So, to FULLY test whether you are still vulnerable to ShellShock, we
must come up with a test that proves that NO possible function body
assigned to a valid shell variable name can EVER cause bash to invoke
the parser without your consent.  For that, I use this (all on one line,
even if my mailer wrapped it):

$ bash -c "export f=1 g='() {'; f() { echo 2;}; export -f f; bash -c
'echo \$f \$g; f; env | grep ^f='"

which is sufficient to test that both normal variables and functions can
both be exported, AND show you whether there is a collision in the
environment.  Ideally, you would see the following result (immune to
shell-shock):

1 () {
2
f=1

It may also be possible that your version of bash decided to prohibit
function exports (either permanently, or at least by default while still
giving you a new knob to explicitly turn them back on), in which case
you'd see something like this (also immune to shell-shock):

1 () {
f: bash: f: command not found
f=1

But if you see something like the following, YOU ARE STILL VULNERABLE:

bash: g: line 1: syntax error: unexpected end of file
bash: error importing function definition for `g'
1
2
f=1
f=() { echo 2

By the way, this vulnerable output is what I get when using bash 4.3.26
with no additional patches, which proves upstream bash IS still
vulnerable to CVE-2014-7186, _because_ it invokes the parser on
arbitrary untrusted input that can be assigned to a normal variable.

Red Hat's approach of using 'BASH_FUNC_foo()=() {' instead of 'foo=() {'
as the means for exporting functions is immune to all possible
ShellShock attacks, even if there are other parser bugs, because it is
no longer possible to mix normal variables with arbitrary content with
exported functions in the environment (ALL normal variable contents pass
through unmolested, with no attempt to run the parser on them).  In
conclusion, I hope Chet will be providing additional patches soon (both
a patch to fix the CVE-2014-7186 parser bug, and a patch to
once-and-for-all move exported functions into a distinct namespace).

I suppose that you are talking about the variables-affix.patch  and
parser-oob.patch posted at http://seclists.org/oss-sec/2014/q3/712. There are now into the last 4.2.37(1) in Debian and effectively show immunity to your test. But bash-4.1.13(1), bash-3.1.19(1), and 2.05b.0(1) with all officials patches fails the same test. Hope that patches will soon be available for all bash versions.

Jean-Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]