demonstration of CVE-2014-7186 ShellShock vulnerability

[Eric Blake]

[posting a rehash of what has been said in several other threads, to
pull all the information into one easier-to-find location]

I know that ShellShock has been getting all the focus lately, but MOST
sites that I have seen that offer advice on how to test whether a build
is vulnerable are testing ONLY for CVE-2014-6271 (arbitrary command
execution after the '}' of a function definition) and/or CVE-2014-7169
(file creation if a syntax error is followed by trailing redirection and
backslash).  This email exists to call attention to the fact that as
long as there are exploitable off-by-one bugs in the parser, your system
is vulnerable to all such exploits UNTIL bash is patched to place
exported functions in a separate namespace and/or prohibit exported
functions.  *In particular*, note that applying 4.3 patch 25 patches
only CVE-2014-6271, and patch 26 patches only CVE-2014-7169, but if
those are the only two patches you apply, YOU ARE STILL VULNERABLE TO
SHELLSHOCK ATTACKS.  One of these is CVE-2014-7186 (the parser does
out-of-bounds referencing if more than 10 heredocs are nested in a
single command).

On the other hand, it is possible to patch bash to avoid CVE-2014-7186
_without_ actually patching the parser bug (ideally, you want both
patches together) - but fortunately, the parser bug is only a security
hole IF there is a way to trigger the parser via arbitrary environment
variable contents.  So distros like Red Hat that are using the
additional downstream patch to place exported functions into their own
namespace are automatically immune to ALL possible ShellShock attacks,
even if bugs remain in the parser.  For more details on the patch Red
Hat is using:
http://www.openwall.com/lists/oss-security/2014/09/25/13

So, here's a few tests you can run to see if your 'bash' still has problems:

First, determine if your bash is still has the parser bug documented by
CVE-2014-7186.  Remember, having this bug does not, by itself, make you
vulnerable to ShellShock attacks; conversely, if your bash has been
patched to avoid this bug, you may still be vulnerable to ShellShock
attacks via other parser bugs.

$ bash -c ':<<a<<b<<c<<d<<e<<f<<g<<h<<i<<j<<k<<l<<m<<n'

In a working bash, this will print repetitive lines similar to:
bash: line 2: warning: here-document at line 2 delimited by end-of-file
(wanted `a')
for all letters 'a' through 'n' (I tested as old as bash 4.1; it might
not warn at all in older versions of bash, since the warning about
assumed end delimiter was a relatively recent addition to bash).  But in
bash builds with a faulty parser, you may see any number of other
behaviors: in my testing, I've seem some systems that dump core, others
that quit printing anything after the message about 'j', and others with
odd messages such as:
bash: line 2: make_here_document: bad instruction type -2147228432
or:
bash: line 2: warning: here-document at line 2 delimited by end-of-file
(wanted `l<<m<<n
')

Since this is an out-of-bounds array access, it MIGHT be possible for a
determined hacker to find a way to smash the stack or heap, and turn
that smash into an arbitrary code exploit, merely by causing the parser
to scan some variation of a nested heredoc (I have only attempted to use
the coredump to prove whether the bug exists or has been patched, and
not take the exploit further by seeing if I could massage the input to
cause a reliable non-coredump in its place), and even if only coredumps
are possible, it may still serve as a means for a denial-of-service
attack.  But it is only a ShellShock attack if an attacker can inject
that heredoc attack into a place where bash will parse it without user
consent.  So the next test to perform is this multiline test:

$ env 'f=() { :<<a<<b<<c<<d<<e<<f<<g<<h<<i<<j<<k<<l<<m<<n
a
b
c
d
e
f
g
h
i
j
k
l
m
n
}' bash -c 'echo hi'

This test does NOT trigger the problem of CVE-2014-6271 (there is no
code after the function body), so patch 25 will not prevent it.  This
test does NOT trigger the problem of CVE-2014-7169 (the function body is
syntactically correct, according to POSIX), so patch 26 will not prevent
it.  But it DOES try and tickle the out-of-bounds reference covered by
CVE-2014-7186.

If you see any output other than 'hi', then YOU ARE STILL VULNERABLE TO
SHELLSHOCK attacks - bash is parsing what should be a syntactically
valid function body, and tripping up.  If all you see is 'hi', then this
test alone is indeterminate - you also need the test mentioned above to
see if the only reason this test was silent is because the out-of-bounds
reference has also been patched.  And even then, that does not tell you
whether OTHER lurking parser bugs may bite you.

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).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature