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.

  • $\begingroup$ TL;DR maybe these posts help you, aswell as the official announcement. $\endgroup$ – SEJPM Jun 1 '15 at 19:57
  • $\begingroup$ all the sources miss the point i don't get: if the last byte of the cookie is NOT 15 - every. single. source. simply states that one can "try again" - but try again changing what part of the input? $\endgroup$ – billdoor Jun 2 '15 at 10:29
  • 1
    $\begingroup$ You try again with the same input, It will be encrypted differently (different IV, maybe different key), so what comes out when you substitute the target block for the last block will be random. 1 in 256 it will be 15, and the message will be accepted, and then you know what the byte is in the plaintext. $\endgroup$ – Steve Peltz Jun 2 '15 at 17:16

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.

  • $\begingroup$ your last point actually contradicts the paper i found on openssl.com (openssl.org/~bodo/ssl-poodle.pdf) which states that the Problem is that the padding is not deterministic, ie. all padding bytes beeing random but the last one. $\endgroup$ – billdoor Jun 2 '15 at 5:23
  • $\begingroup$ also, again from (openssl.org/~bodo/tls-cbc.txt) in a mail from 11/5/2003: "TLS allows up to 256 bytes of padding, i.e. you can use more than the block size if desired" $\endgroup$ – billdoor Jun 2 '15 at 6:06
  • $\begingroup$ I was describing attack against PKCS#7 style padding, not SSL 3.0, sorry. I corrected it. PKCS#7 padding is deterministic, yet it's still vulnerable (and depending on how easy it is to to distinguish between padding error and MAC error, actually a simpler attack). Re: max padding size, I fixed it to specify SSL 3.0; allowing a larger size in TLS doesn't help much, you'll still get a padding error when the rest of the pad bytes don't match, and checking the pad bytes can lead to an additional timing attack, which would require a very careful (and slow) implementation to completely eliminate. $\endgroup$ – Steve Peltz Jun 2 '15 at 16:06
  • $\begingroup$ @billdoor you should feel welcome to answer your own question and let others upvote it or offer their own answer. $\endgroup$ – user3201068 Jun 2 '15 at 16:41
  • $\begingroup$ Steves post answered my question completely. What i did not understand was, that "try again" really just means, sending the exact same payload again and depend on the encryption beein different for it to work. $\endgroup$ – billdoor Jun 5 '15 at 18:48

Your Answer

