I've been digging around the webs for a bit since I first posted this question.
According the original discoverer of the bug, bash prior to the CVE-2014-6271 patch imported a function such as:
foo=() {
code
}
by replacing the equals sign with a space and interpreting it... which meant interpreting beyond the function definition was possible.
The patch for CVE-2014-6271 introduced a special mode of the parse_and_execute() function to limit evaluation to the function definition, and not beyond it.
However, as explained in this thread, the specially crafted environment variable of the CVE-2014-7169 vulnerability test is designed to 1) confuse the parser to death 2) leave scraps in the buffer 3) completely change what the original bash command does when it combines with the scraps already in the buffer.
So to dissect the environment variable:
X='() { (a)=>\'
- The parser will analyze
() { (a)=>\
. Note that \
is part of the string; it is not escaping the trailing single quotation.
() {
- The parser identifies this as a function definition.
(a)=
- This confuses the parser to death.
>\
- The parser leaves the final two characters sitting in the buffer.
>\[NEWLINE]
- At some point before the
sh
command is run, a newline is placed in the buffer.
>\[NEWLINE]echo date
- When
sh
is called (which is probably a symlink to bash in this case), it adds its command arguments, echo date
, to the characters already existing in the buffer.
>echo date
- Since the newline is escaped, bash will parse the buffer as
>echo date
, which has the same effect as date > echo
. A file named echo
is created and the stdout of the date
command is redirected into it.
; cat echo
- The second command simply displays the contents of the newly created file.