Hacker News Reader

Comment by upofadown | Hacker News Reader

>Now you’ve successfully downgraded the message to the legacy format, which didn’t provide any authentication over the ciphertext.

... and the system accepts the old format? Wouldn't that be the actual problem here? Is there something wrong with the old format that caused a security weakness?

>Using either of the two methods, with the HMAC check completely bypassed, you’ve reduced the security of this construction to unauthenticated AES-CBC mode, which is vulnerable to a Padding Oracle Attack.

Well was this particular system actually vulnerable to a padding oracle attack?

I hate these security writeups that prime the reader but never actually get to the punch line. If something has a security weakness you should explicitly state exactly what it is. Don't leave it to the reader to figure it out. If it turns out that there was no actual issue then you are being misleading by the implication that there was.

View on HN

> > Using either of the two methods, with the HMAC check completely bypassed, you’ve reduced the security of this construction to unauthenticated AES-CBC mode, which is vulnerable to a Padding Oracle Attack.

> Well was this particular system actually vulnerable to a padding oracle attack?

Yes. That's what the thing you just quoted says.

This isn't a theoretical leap, either. It's unauth CBC with PKCS#7 padding with OpenSSL's API.

> I hate these security writeups that prime the reader but never actually get to the punch line.

But it did. "X uses Y which is vulnerable to Z" does, emphatically, state that X is vulnerable to Z. Your rant is unnecessary.

I asked for an explicit statement that it was vulnerable, not if it could be vulnerable. To have a padding oracle attack against CBC, the attacker needs:

* The ability to submit a lot of messages for decryption.

* A error specific to a padding oracle issue.

* Some sort of provided reverse channel to get that error information back to the attacker.

Does the system in question have these attributes?

I note that you have not explicitly stated that the system is susceptible to a padding oracle attack either. That's because you have read the same article and can not.

The blog post is written in conversational English. It is not meant to be a technical, formal paper about their protocol. If you're going to get hung up on that, that's entirely your problem, not mine.

Yes, their fucking thing is vulnerable, because of how PHP + ext/openssl handles padding errors by default. They can mitigate this behavior by suppressing error reporting, but the underlying behavior will still be observable later in the application when `false` is provided instead of a string.

To trigger the vulnerability, you would need the ability to modify a ciphertext. This requires privileged access to where the encrypted data is stored.

Exploit procedure:

  1. Modify ciphertext
  2. Access PHP script that processes said ciphertext under-the-hood
  3. Did it spit out a PHP error?
     * Yes -> Invalid padding
     * No -> Valid padding

Am I going to laboriously describe one of the most well-tested padding oracle exploit paths in the web programming ecosystem in an informal blog post whose purpose is to describe coding/design flaws? No, because that's a waste of everyone's time.

I don't generally write articles with the premise that my audience needs every logical conclusion spoon-fed to them.

> I note that you have not explicitly stated that the system is susceptible to a padding oracle attack either. That's because you have read the same article and can not.

I wrote it, actually.

>They can mitigate this behavior by suppressing error reporting,

Did they?

I am not trying to annoy. I have seen very misleading articles where a weakness is strongly implied but after digging into things did not and could not exist.

https://www.php.net/manual/en/errorfunc.configuration.php#in...

I don't know what their PHP configuration is set to in production.

As a rule, I don't test systems that require me to send packets. I only look at code. This keeps me from having to care about the Computer Fraud and Abuse Act.

What I know: The particular bit of code that Paul tweeted is vulnerable, and the mitigation you're asking about only reduces it from a "grep the HTTP response body" oracle to a timing oracle, so it doesn't actually eliminate the issue.

Reply on news.ycombinator.com