@TerryChia interesting thought, that will be one of the key bits. Though to an extent if you an install a library, you'll probably use it at least once, so code execution on instantiation would work too...

One large issue with that is that if there's code execution during runtime it's usually in the context of a normal user. By default Python's package manager requires root to install so code execution during install directly leads to root.

So you know how you debug a program, and put a bunch of print statements in. And when you run the program you're like, "Damn it I forgot the \n's!!"? Now imagine you put debug statements into a kernel, built it, packed it and flashed a device and then checked for the print statements only to realize you didn't put \n's in.... >.<

Thus, with SSL 3.0, there is some room for modifications that will not impact the decrypted data (since they fall in the padding bytes whose value is ignored), but that will impact the decryption of the next record, since the encryption of the last padding block serves as IV for the next record.

So at that point I'll try to substitute the first block of the next record with the encryption of a block that has identical contents except for the first byte, that is unknown and that I want to guess.

@ThomasPornin I'm having trouble seeing what the end goal really is. If your end goal is to derive the key, or predict plaintext values wouldn't you need a fairly high number of records within the same session?

Attacker is both inside (hostile Javascript) and outside (has control of the WiFi hotspot). Attacker wants to get the victim's cookie on some other site.

Hostile Javascript issues a GET HTTPS request to the bank site; the request contains the cookie. Encryption is CBC, let's say with 3DES. In the stream, attacker arranges for the last byte of the cookie to be the first of an 8-byte block.

The attacker knows the bytes immediately after the cookie (start of the next HTTP header).

So attacker sees y = E((X || c) xor d) where X is the last byte of the cookie, c is the next (known) 7 bytes, and d is the previous encrypted block (also known).

Attacker then instructs his Javascript to issue a request including the bytes A || c such that A is his guess of the unknown byte, and that sequence happens as first block of a record.

Attacker also arranges for the previous record to have length such that the padding for the previous record has length 8 bytes.

The attacker intercepts and alters the two records (the one that contains 'A || c' and the previous one).

He replaces the last block of the first record with d, and the first block of the second record with y.

Replacement in the first record has probability 1/256 of being accepted by the server, because of the SSL 3.0 padding (it depends on whether decryption yields a final byte of value 7, the other bytes being ignored).

The attacker can see that by just setting a small delay between sending of the two records, just to see if the server complains or not.

If the server does not complain, then it will accept the subsequent record, or not, depending on whether A = X or not.

Thus, with an average of 128*256 calls, the attacker guesses the last byte of the cookie.

He then iterates with the previous one, and so on.

There are details to adjust in the description above (data after A || c must match the modification of the first encrypted block of the second record) but it seems that it works on the paper.

The root cause: SSL 3.0 CBC padding allows for a lot of modifications that will be ignored upon decryption, which gives leverage to play IV-based games.

In TLS 1.0 all the padding bytes are fixed and the implementations must check them, so this attack does not work.

RFC 7366 (encrypt-then-MAC) would actually help a lot against these attacks. But it is not defined for SSL 3.0.

@RоryMcCune I don't have a twitter account. If you want, you may answer in my name: "my guess is a BEAST-like attack that abuses the ignored bytes in SSL 3.0 padding (1/256 chance of unnoticed alteration, modifies IV for next record)".

@ThomasPornin What would be grand is a blog post on it - just expanding your brief chatroom summary. I'm definitely not qualified, but if you (or one of our other crypto folks) wanted to draft up a blog post for publication tomorrow as a place to go for all (insert name of new SSL3 vuln here) questions we could ping that around the intarwebsphere

@RоryMcCune I don't have a twitter account. If you want, you may answer in my name: "my guess is a BEAST-like attack that abuses the ignored bytes in SSL 3.0 padding (1/256 chance of unnoticed alteration, modifies IV for next record)".

Not sure whether it's significant, but I posted Thomas's summary to the security mailing list, and the official announcement went live 15 minutes later. Pornin might have moved the timetable by guessing it early, or perhaps it was just a coincidence.

Canonical question regarding the recently disclosed padding oracle vulnerability in SSL v3. Other identical or significantly similar questions should be closed as a duplicate of this one.
What is the Poodle vulnerability?
I use [product]. Am I affected?
Is [product] vulnerable to the Poodl...