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.

SSLv3 is Broken

With the advent of POODLE, all the cipher suites used by SSLv3 have been compromised, and the protocol should be considered irreparably broken.

Websites

You can check if your website is available over SSLv3 with curl(1):

curl -v -3 -X HEAD https://www.example.com

The -v argument turns on verbose output, -3 forces curl to use SSLv3, and the -X HEAD limits the output on a successful connection.

If you are not vulnerable, you should not be able to connect, and your output should look something like this:

* SSL peer handshake failed, the server most likely requires a client certificate to connect

If you are vulnerable, you should see normal connection output, including the line:

* SSL 3.0 connection using SSL_NULL_WITH_NULL_NULL

Other Services

It's not just websites that are available over SSL. Mail, irc, and LDAP are three examples of services available via secured connections, and are similarly vulnerable to POODLE when they accept SSLv3 connections.

To connect to a service using SSLv3, you can use the openssl(1) s_client(1) command:

openssl s_client -connect imap.example.com:993 -ssl3 < /dev/null

The -connect argument takes a hostname:port parameter, the -ssl3 argument limits the protocol versions negotiated to SSLv3, and piping in /dev/null to STDIN immediately terminates the connection after opening it.

If you connect successfully, SSLv3 is enabled; if you get a ssl handshake failure then it is not.

See Also

There is an excellent question and answer on the Security SE: https://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability