[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
