Poodle: Yet another attack on SSLv3 (SSL 3.0)

In the CBC mode, the decryption works as follows:

* For any block Ci, its decryption is given by Decrypt(K, Ci) XOR Ci-1, where C0 = IV

Now we know that the last ciphertext block, when decrypted, will yield the padding block (whose last byte has a value of 15). We could now exploit this fact as follows:

1. 1. Suppose we want to know the plaintext corresponding to block C3, we would send a message of such length that it requires a full padding block to the server with block C3 copied as the last block (in lieu of Cn). The attacker needs to fix the padding block to a known length, e.g., 16 bytes in this case, to know the value of the last byte. This could be done by varying “attacker padding” in the plaintext request.
   2. The server will either accept this request or reject it based on whether the padding is correct – meaning whether the last byte of the padding block has a value of 15.
   3. In the CBC mode of encryption, the decryption of the new last block will be Decrypt(K, C3) XOR Cn-1.
   4. Usually the server will reject the request since the last byte will not be 15 (if the last byte is not in the range of 0..15, the server will reject the message outright. If it is in the 0..15 range, the server will strip those many bytes of padding and then proceed to validate the MAC, which will fail).
   5. If the attacker makes the same request (although the request is same, the ciphertext will be randomized due to random IV) over and over again, then on an average every 256 requests it will find that the server will accept the request. The plaintext content of block C3 doesn’t change between requests, but it is XORed with Cn-1, which does change between requests, and the server will accept the request when these two happen to align such that it results in a valid padding length byte, e.g. 15. In such cases the attacker knows the last byte of the decrypted message must be 15. The attacker can use the above fact to find out the last byte of the plaintext corresponding to the block C3 as follows: P3[15] = Cn-1[15] XOR C2[15] XOR 15.
   6. Now that the attacker has figured out one byte of plaintext, the attacker can effectively shift the plaintext message by one byte (by adding a fake byte at the beginning and removing a byte somewhere after the targeted block to maintain the same message length) such that the next byte of interest in the C3 block is in the last position.
   7. The process repeats itself until the entire message or part of the message is decrypted.

In the simplest scenario, an attacker can run JavaScript in one origin in a browser and cause the browser to make requests to other origin. The injected JavaScript code has complete control over the path and the body of the HTTP request. This injected code can now “manage” the length of the path and the body to ensure that the plaintext plus the MAC will result in one full padding block when SSL 3.0 encrypts the request. The browser will do “its thing” and send cookies with the request. The attacker, who also controls the client-server connection, can now launch this attack by duplicating the block of interest (as the last block). If the receiver accepts the record then the attacker knows last byte of the cookie using (on average) 256 requests. Since the attacker has complete control over the path and the body of the message, it can shift and align content to create a full padding block.