From kevin.w.wall@gmail.com on August 25, 2013 21:51:40

Note that Philippe Arteau's original post to the ESAPI-DEV mailing list mentioned two conditions. Condition #1 had to do with tampering with the MAC length in the generated serialized ciphertext and setting that length to zero. That is what this issue and the attached file, is about. An exploit for condition #2 as mentioned in his email post has not yet been developed. I am looking at that issue as well, but that will require design changes and some may be substantial otherwise it may introduce other errors.

Cc: philippe...@gmail.com

From chrisisbeef on August 25, 2013 22:39:04

Let's create a second issue to address the second condition and prepare a patch release to address the vulnerability this week. I will run the release - Kevin can you verify the patch resolves the problem and that all tests pass.

From kevin.w.wall@gmail.com on August 27, 2013 21:03:31

Additional Precautions

Once a fix is made available and you have downloaded and installed it, you may wish to take the extra precaution of generating all new symmetric encryption keys that you have been using, including the Encryptor.MasterKey in your ESAPI.properties file if you have been using that. (Of course, if you plan to do so, if you have persisted any encrypted data using the old keys, you will first want to decrypt that data so it could be re-encrypted with the replacement keys just as if you were doing a key change operation.)

The reason that you might want to consider taking this additonal precaution is that this vulnerability could lead to a padding oracle attack against your system using the ESAPI 2.0 symmetric encryption--but only if you were using CBC mode and a MAC, which are the default configuration; if you were using CBC mode and no MAC and/or the deprecated encrypt() / decrypt() methods from ESAPI 1.4 then you were already screwed before this vulnerability. As Duong and Rizzo showed us, it is possible to use a padding oracle attack to eventually divulge the secret encryption key.

Of course, because doing all this will take quite a bit of effort, especially if you have persisted encrypted data encrypted with the keys that need replaced, there is a way to tell if anyone has attempted this attack against your system.

Assuming that you have have ESAPI logging enabled and have kept those logs around, I would recommend that you look through those logs for this string that will be in the log file should this vulnerability be attempted against your system:

Cannot validate MAC as it was never computed and stored. Decryption result may be garbage even when decryption succeeds.

If your logs can be trusted (i.e., not writtable by everyone and their brother), then you should be safe if you do NOT see this string in your ESAPI logs. (Note that if you do see this string in your ESAPI logs, it is not proof positive that this vulnerability was attempted. It could also result of someone calling the deprecated Encryptor.encrypt(String) with a different key than was used to encrypt the plaintext. That is, someone could just have tried the wrong Encryptor.MasterKey.)

It is advised that you look back through your ESAPI logs at least back to August 21, 2013 which is when Philippe Arteau first posted an announcement of this vulnerability to the public.

From kevin.w.wall@gmail.com on September 02, 2013 19:56:30

Here's the latest updated JUnit test which should test this vulnerability out-of-the-box without requiring tweaks to your ESAPI.properties file. Just drop it in your
\src\test\java\org\owasp\esapi\crypto folder and run your JUnit tests as normal. If it passes, you're good. If the test fails, your version of ESAPI is vulnerable.

Attachment: ESAPICryptoMACByPassTest.java

From kevin.w.wall@gmail.com on September 02, 2013 19:58:49

Fixed in ESAPI release 2.1.0, released on 2013/09/02. See release notes for additional details.

Status: Verified

From kevin.w.wall@gmail.com on September 02, 2013 20:05:22

Note: We've applied for a CVE identifier for this issue. I will add reference it here as well as update the release notes once we have it.

From kevin.w.wall@gmail.com on September 02, 2013 20:08:34

Changing label 'Type-Vulnerability' to 'Type-Defect' so that everyone can now view this Google Issue.

Labels: -Type-Vulnerability Type-Defect

From kevin.w.wall@gmail.com on September 03, 2013 22:39:34

Mitre has assigned the CVE identifier "CVE-2013-5679" for this issue. More details to be provided later.

After reading the last two posts here: https://code.google.com/p/owasp-esapi-java/issues/detail?id=306
I'm confused as to the fix of CVE-2013-5960.
I understand that commit 41138fe fixes CVE-2013-5679, but not CVE-2013-5960. If that is the case, is there another commit for the latter CVE?