[Esapi-user] [Esapi-dev] [Owasp-leaders] Crypto attack and OWASP
Kevin W. Wall
kevin.w.wall at gmail.com
Mon May 3 07:37:28 EDT 2010
Kevin W. Wall wrote:
> Jeff Williams wrote:
>> IMHO this is just one more sign of a healthy security ecosystem.
>> There will always be folks who think it's 37337 to release an
>> unknown exploit regardless of the harm it causes. But complaining
>> about it won't help. No matter what, we need to have a measured
>> response capability ready. It's entirely possible that this is an
>> esoteric risk that doesn't really expose any real applications, however
>> it could also be critical. At this point we don't know. I'm looking
>> forward to evaluating the alleged flaw, whatever it might be.
> Been researching Padding Oracle Attacks a bit. Looks like we are presently
> doing one thing right and (at least) one thing wrong. We are using a
> "combined" mode or the have the ability of using an HMAC-SHA1 to ensure
> the authenticity. At least one thing that we are doing wrong is providing
> two _different_ end user errors for the cases of where attempting the
> decryption failed vs. when the decryption succeeded but the authenticity
> check failed. That is easy to correct, especially since we have two separate
> errors, one that is logged on the server and one that is returned to the
> end user / application.
After sleeping on this over night, I realized in the shower this morning
that not only do we need to have the failure to the client be the same
message, but that failure for no matter what reason needs to TAKE THE
SAME AMOUNT OF TIME!!! Otherwise, there is still a side-channel attack
known as a timing attack that is possible. That will take a bit longer to
address but it is still isolated to a single method in JavaEncryptor so
it shouldn't be too hard. However, I may have to resort to ensuring that
failures take some minimal amount of time do accomplish this. We'll see.
As I was also thinking about this, I realized (assuming I remember it correctly;
it's been 3 yrs or so since I've read the W3C spec) that the XML Encrypt
standard is also vulnerable to the Padding Oracle attack. (It uses CBC mode
and PKCS#5 padding and the random IV is exposed.) That's a much bigger problem.
So you'd better be using XML Encrypt over SSL or using it with XML Digital
Signature or otherwise you are screwed. Since XML Encrypt is used in the OASIS
SAML spec, certain versions of that would be vulnerable as well. (1.0, I think.
IIRC, the 1.1 and 2.0 specs require the SAML assertions to be signed.)
Anyhow, looks like the development community has some cleanup in aisle 5 to
do. I will post to back to list when the ESAPI cleanup is through and check with
Rizzo and Duong to make sure we've covered everything else as well.
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents." -- Nathaniel Borenstein, co-creator of MIME
More information about the Esapi-user