POODLE is a recent attack on SSLv3. This article will explain the attack in detail:

The POODLE attack on SSL Version 3, that sometimes allows an attacker to decrypt a single byte of an SSLv3 protected conversation. Repeating the attack might allow an attacker to decrypt multiple bytes of a secret (for example Session-Cookie, Password…) that is repeatedly send.

 When can the POODLE attack be applied?

The POODLE attack can be applied if:

• A network connection is secured using SSLv3
• A block cipher is used for the connection
• The attacker is an active adversary in the path between the client and the server and he is able to intercept and modify network traffic

To improve the success probability, the attacker should be able to:

• Force the client to repeatedly send a secret over that network connection
• Force the client to vary the position of that secret in the transmission

What can an attacker gain using the POODLE attack?

An attacker will be able to decrypt a single byte of the encrypted content with a probability of 1/256. By repeating the attack (the same secret is send again), he will be able to decrypt that single byte with probability 1. By varying the position of a secret content, he will be able to fully recover that secret.

What cannot be done using POODLE?

Using POODLE, it is not possible to:

• Impersonate an SSL/TLS Server
• Recover the secret key of an SSL/TLS Server
• Modify any data that is transmitted

What is the weak point of SSLv3 that is exploited?

When using a block cipher for SSv3, the data to be transmitted is protected against unauthorized modification by adding a MAC to that data first. The result will most likely not have a length that is an integral multiple of the block length of the block cipher. To expand the data to be encrypted to a proper length, a padding is added. The last byte of the padding contains the length of the padding, so that the padding can be properly removed. The data is then encrypted with the block cipher in CBC mode.

Assuming that the last block of the ciphertext ($latex C_i$) is entirely filled with padding. The last byte of plaintext in this block will be the length of the padding $latex l$. An attacker might now replace that block $latex C_i$ with a previous block in that session $latex C_j$. The server will decrypt that block by computing $latex P_i = D(C_j) \oplus C_{i-1}$. If the last byte of $latex P_i$ is now $latex l$, the server will correctly decode the length of the padding and will decode the entire ciphertext correctly. If the last byte differs, the server will very likely fail to decode that ciphertext correctly and close the connection.

This can be used to decode the last bytes of arbitrary ciphertext blocks in a conversation by repeating the process. The attacker might also shift the secret in a conversation to fully decode it.

What countermeasures are possible?

As long as SSLv3 is not used (also, SSLv2 is very weak and should not be used anymore), the attack is not possible. I consider disabling SSLv3 on the server or the client side (best is both sides) to be the best solution. If for any reasons, SSLv3 still needs to be used, you might disable all block cipher suites. However, the only stream cipher available in SSLv3 is RC4, which is also broken. I would currently assume that it takes more repeated conversations in SSLv3 using RC4 to recover a secret than it takes to decrypt a secret using POODLE. However, attacks against SSLv3 using RC4 can be done passively.

Will I notice the attack?

As long as logging is used on the client or the server, the attack will very likely produce a lot of error messages related to MAC verification failures or incorrectly terminated connections.

Which methods are available to shift a secret in a conversation?

That depends on the protocol. If the secret is for example a session cookie, the request URL in an HTTP request might be altered to have a varying length. As a result, this will also shift the position of a session cookie in the transmission.

Which methods are available to make a client to repeat a conversation?

That also depends on the protocol. For POP3/IMAP, this might happen automatically. For HTTP, the attacker might run javascript code or similar things in the victims browser to make it reload a certain URL. You don’t need an exploit for the browser to do this.