There's a padding oracle in the form of RSA used by both TLS and SSLv2; by repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures for this attack.
But SSLv2's countermeasures are sabotaged by the crappy ciphers it also supports. In both TLS and SSLv2, the anti- padding- oracle trick is that the server detects bad messages and then generates a fake message to continue running the protocol with, instead of aborting (which would reveal to the attacker that the message was corrupt, thus enabling the padding oracle). But when SSLv2 does that, the attacker can detect that it did, because the cipher key lengths in SSLv2 are so short that they can be brute forced. The attacker knows when the SSLv2 server replaced its message with a fake one, and thus has a working padding oracle.
The big problem here is that people run old SSLv2 servers with the same RSA keypairs as their TLS servers. So you can take messages you captured from the TLS servers, and, with some very clever message manipulation owing to an older Bardou paper, make them intelligible to SSLv2, and use the SSLv2 padding oracle to decrypt them.
It's a great, great paper. The Bardou "trimmer" stuff was news to me too! :mind-blown-emoji:
The top line takeaway on DROWN for most people seems to be "export ciphers are evil". I think: (a) boring! (b) misses the more important point.
To me, the real problem here is RSA. Virtually every system on the Internet that does RSA uses PKCS1v15 padding (DNSSEC, which is only now being rolled out after nearly two decades of standards work, uses PKCS1v15 padding!). Moreover, RSA directly exposes an encryption primitive, unlike DH+signature forward-secure protocols, and RSA ciphertexts are surprisingly malleable.
To me, the real takeaway: RSA is obsolete. Stop using it.
† We walk you through this vulnerability in our challenges here: http://cryptopals.com/sets/6/ --- start with #46