3 ms·

> > 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,

> > 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.

upofadown 4y ago
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.
- CiPHPerCoder 4y ago
  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.
  - upofadown 4y ago
    >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.
    - CiPHPerCoder 4y ago
      https://www.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting 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.

upofadown 4y ago

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.

CiPHPerCoder 4y ago
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.
- upofadown 4y ago
  >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.
  - CiPHPerCoder 4y ago
    https://www.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting 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.