poodle padding multiple blocks?

Question

I'm quite new to the topic and read a bit about poodle and padding oracle.

I quite understand the "regular" padding oracle attack, substituting the last byte of block(n-1) to determine the last byte of block(n) - by "myguess" XOR 0x01 for the last byte and so on.

Articles on poodle however state, that the attack is based on placing my target block to replace the padding. As the padding is not checked, the server will accept the message if the last byte of my replacement happens to be the length of the padding, as the server will cut the padding correctly and be able to check the MAC.

Now, as stated here there always is padding, as you could not otherwise know, if the message just happened to fit into blocks.

I understand poodle to work like this:

• i forge request with javascript, forcing the victims' browser to copy the encrypted sessioncookie-block as padding
• i create at max 256 of these requests, moving my cookie-block further down the line, thus creating longer and longer paddings until the server accepts the request, telling me that the decrypted last byte is the position of the last byte in the forged padding
• i "write down" the last byte, drop it and repeat the process with the second to last byte and so on.

if the last byte of my sessioncookie now happens to be FF, is would need a padding of 255 bytes length, which is multiple blocks of just padding.

Will sslv3.0 implementations just accept that i padded more than is reasonably neccessary?

Or have i misunderstood the concept? I have not found an article really explaining in detail.

I'm glad for links to detailed technical descriptions, videos, most of all for simple corrections in my description of the process if it isn't correct.

Answer 1

If the last byte in the block is larger than the block size, that would generate a padding error in SSL 3.0.

SSL 3.0 padding is up to $BlockSize-1$ bytes of unspecified data, and one byte with the length of the padding (not including the length byte itself). TLS 1.0 and above allow padding longer than the block size, and requires that each byte contains the length. The POODLE attack is against 3.0 (after downgrading the connection).

In the POODLE attack, you need to arrange two things, the length of the message (plus MAC) is exactly a multiple of the block size, and the byte you want to find out is moved to be the last byte in a block.

If you substitute the padding block with the block with the desired byte, it will occassionally (1 in 256) decode to be 15 (for a 128-bit block size), and the message will be accepted (because the padding byte now leads to a correct MAC, which is at the end of the previous block). If it isn't accepted, generate a new encrypted message and try again (which will randomly change what that last byte decodes to, from any or all of a new key, a new IV, or any changed fields in the plaintext).

If you take the last byte, XOR it with the last byte of the previous block's ciphertext, then XOR it again with the last byte of the ciphertext preceding the original location of that block, you'll get the correct value of that byte.

Repeat after manipulating the plaintext so that another (unknown) byte is in the last byte of a block (without changing the required padding amount).

An earlier version of my answer was describing a Padding Oracle attack against PKCS#7 style padding, which relies on being able to distinguish between a padding error and a MAC error, the POODLE attack distinguishes between error and no error.

With TLS, padding can be longer than one block, and the implementation shouldn't distinguish between padding and MAC errors, but it's still susceptible to timing attacks, even if it calculates a MAC after detecting a padding error.