Hacker News new | past | comments | ask | show | jobs | submit login

My understanding of the padding oracle vulnerability so far, mainly from the patch [0]: it's possible to make a "valid" message that has the pad length byte higher than maxpad (total_length - digest_length - 1) [1]. If you make it high enough, I think you'll push the offset used in the constant time comparison masks enough below 0 to entirely skip the MAC check [2]. But then your entire plaintext will have to match the pad byte to pass the check, and I think you can use that as a padding oracle.

In other words, constant time programming, which by definition means that you have to behave normally even if your offsets go negative, is HARD. (And when you don't put comments ANYWHERE, it's even harder.)

[0]: https://github.com/openssl/openssl/commit/70428eada9bc4cf314...

[1]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...

[2]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...

For the record, there is nothing Go or Rust could have done here. The bug is caused by having to write code that runs in constant time, by employing masks and behaving in exactly the same way irrespective of the pad value. If you want to blame the design of something, blame Mac-then-Encrypt in TLS 1.0.

See also The Cryptographic Doom Principle [3].

[3]: https://moxie.org/blog/the-cryptographic-doom-principle/

EDIT: Interestingly, this was found with TLS-attacker [4], a new framework to analyze, test and attack TLS libraries. Finding it was probably "just" a matter of sending a plaintext made entirely of the same right byte value, and noticing that the MAC check passes when it should not. However, so far we didn't have any tool or testsuite (which I'm aware of) to perform this kind of checks.

[4]: https://github.com/RUB-NDS/TLS-Attacker

IMPACT [EDIT]: to sum up, if a client uses AES-CBC to connect to a server with AES-NI support, a MitM can recover at least 16 bytes of anything it can get the client to send repeatedly, together with attacker-controlled data (think Cookies or such, using Javascript cross-origin requests).

That's a second-order padding attack, in the same sense that an integer overflow most often creates a second-order buffer overflow: a first bug transitions your program to a state where a second bug --- very exploitable, and one the program tried to guard against --- is revealed.

What's interesting about crypto to me is the prospect that every common crypto flaw has second- and third- order variants that we will not find out about for many years, the same way we've barely now got a grip on the interaction between C integers and buffer counting.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact