[Esapi-dev] Status of CVE-2013-5960

Kevin W. Wall kevin.w.wall at gmail.com
Thu Mar 12 06:58:25 UTC 2015


(Oh God; not another one of Kevin Wall's TL;DR emails.)

On Wed, Mar 11, 2015 at 12:08 AM,  <owasp-esapi-java at googlecode.com> wrote:
>
> Comment #12 on issue 306 by philippe.arteau: Crypto MAC by-pass makes
> default ESAPI symmetric encrytion using CBC mode vulnerable to padding
> oracle attacks
> https://code.google.com/p/owasp-esapi-java/issues/detail?id=306
>
> I thought the CVE-2013-5960 was never fixed. As it would require a redesign.
>
> Summary :
> CVE-2013-5679 => MAC can be set to null
> CVE-2013-5960 => It is possible to alter metadata of the ciphertext **
>
> ** The real exploitability was proven by Synactive team
> http://www.synacktiv.fr/ressources/synacktiv_owasp_esapi_hmac_bypass.pdf
>
> @Kevin : Am I correct ?

I am posting this because of the ongoing comments to ESAPI Google Code
issue #306. We have moved the ESAPI issues to GitHub show we should not
really be updating the ESAPI issues at Google Code. Furthermore, it's
difficult to have an ongoing dialog on any bug tracking system. Those comments
were meant for comments about how things should be fixed, etc., not status
inquiries or things like requests about notifying Mitre that CVE-2013-5679
has already been fixed. (I notified Mitre originally about it and did so again
in early January, but that's what kicked off this whole discussion in the
issue's comments to start with.)

However, I wanted to respond to Philippe Arteau who posted the above
to the Google
issue 106. (That and redirect any follow-up discussions here where it
is easier to
respond.) At any rate, I think I owe people an explanation of what's
going on with this.

First off, Philippe is correct in his assessment that while
CVE-201305679 was fixed in 2.1.0, CVE-2013-5960 entails more of a
design change to fix and is not yet in ESAPI production code. As the report
by SynAcktiv Digital Security so astutely noted, the particular exploit
that they used is fixed in the kww-crypto-2.1.1 branch on Google Code.
As they also noted, the code on that branch was never rolled into
production.

Furthermore the mitigation that they noted in section 1.4 of their
report is accurate and fortunately both CCM and GCM authenticated
encryption (AE) modes are now standard in the SunJCE provider that comes
with JDK 7 and later versions. Had that been the case in JDK 6,
most of the implementation of ESAPI crypto would have been unnecessary
and I would likely have made one of those 2 modes the default, or perhaps
*only* allowed AE modes. However, since no AE modes were available
in JDK 6 or earlier, one had to use something like BouncyCastle as the JCE
provider to get an AE mode, so it was suggested by David Wagner to use
CBC with an HMAC and an encrypt-then-MAC approach as the default.

The last sentence of section "1.4 Mitigation" of Synacktiv's report states:
    Even if the ESAPI HMAC is broken, the underlying encryption
    algorithm will have it's own MAC which will prevent padding oracle
    attacks.

I have verified this, but what I remember off the top of my head
that no actual HMAC is even computed or checked if one of the
recognized AE modes is used. (IIRC, the HMAC in the serialized
CipherText object is just a single null byte and the maclen set
to one, but it might be that the maclen is set to 0; too lazy to
look at the code at this hour, but pretty sure that is the case
for 2.1.0 as well as earlier 2.0.x versions.)

Also, as Synacktiv's report notes, where the current 2.1.0 release
breaks down is that I had made the poor choice of using assertions for
a bunch of checks rather than conditional if/else checks. In the
kww-crypto-2.1.1
branch, I was methodically going through all the assertions and
replacing them with conditional checks (or at least those cases that could
be driven directly from programmatic input). However, one workaround /
mitigation that Synacktiv did not note was that that one could just
enable assertion checking for the ESAPI crypto classes. I think that
using the following flags to 'java'

    -ea:org.owasp.esapi.crypto -ea:org.owasp.esapi.reference.crypto

should be sufficient, however I have not tested it. Using an AE mode
like CCM or GCM--if that is an option available to you--is the preferred way
to use ESAPI crypto if you can't wait until a fix. (And if you are still using
JDK 6 or earlier and thus an AE mode is not available to you, then trust
me, you have much bigger problems to worry about than this CVE.)

And speaking of a fix for CVE-2013-5960, here's where things stand. As
I started looking more deeply at the code I started to notice lots of other
things wrong that were not commented on by any prior code reviews (which,
knowing what I now know, I am not surprised). There were small things like
using assertions where a conditional check and throwing an
IllegalArgumentException was really called for, larger things like how
I insecurely set the JCE provider (dynamically, thereby allowing a
rogue third party library to change the preferred provider), and things
like how I did not include the cipher transformation, version #, etc. into
the HMAC calculation which was where most of the redesign was involved.
Most of those things I have fixed in the latest commits to the
kww-crypto-2.1.1 branch in Google Code.

One reason why this is taking longer than I wanted to is because
I've decided to fix some other things that I thought really do need
addressing as realistically, this likely will be the last release of ESAPI 2.x.

Some of those things include:

    1) A way to do the encryption with a different, but specific, IV each
       time rather than having it just choose a random IV each time. I've
       created a new protected method to do that. The intent is to use it
       for regression testing and cross platform testing where it is sorely
       needed. Jeffrey Walton had been asking me for test vectors for the
       OWASPI ESAPI C++ crypto code that he had been working on at
       one time and I was unable to provide those without this functionality.
       It is long overdue as it will allow us a way to write regression tests
       much easier, including the types of crypto attacks like Philippe and
       Synacktiv wrote as exploits.
    2) The ability to use different JavaEncryptor objects with different
       cipher modes or key sizes, etc. For instance, if you wanted to encrypt
       something for Alice using AES and something for Bob using DESede,
       previously there was no way to do this. Now you can, although it
       cannot be done directly from the Encryptor interface. You have to
       explicitly call a new JavaEncryptor CTOR to do this. This took a
       considerable hacking because JavaEncryptor had for some reason
       been originally implemented as a singleton (as sadly, IMO, most of
       the rest of ESAPI 2.x has been). I did not address the singletons
       in the other ESAPI reference implementation classes, but I did in
       the crypto because without it, it made some use cases such as
       using different cipher algorithms impossible in the same JVM.
       (Well, almost; I did have a non-thread-safe trick to temporarily change
       the cipher algorithm, but it's something that I only used in
       the JUnit tests and not something that you would ever want to
       use in your production code.)
    3) Tried to consider what other potential attacks might come through
       rogue 3rd party code that could subvert ESAPI crypto and try to
       address those.
    4) Other miscellaneous bug fixes in ESAPI (many of which others have
       been fixing).

Anyway, I'd say that most of this redesigned / restructured crypto code
is written, but there are not yet *any* new JUnit tests that have been written
for it to test the updates (especially, being able to decrypt things encrypted
with earlier versions of ESAPI 2.x, which is the tricky part).

The bad news is that my latest commits to the kww-crypto-2.1.1 branch
in Google Code never were migrated to GitHub, and because of
that, I've lost most of my incentive and motivation. (I know, mea culpa,
or as you "young whippersnappers" would say "My bad". Now GET
OFF MY LAWN!!! :)

Frankly, I am not enough of a Git expert to know how to do this
migration from the kww-crypto-2.1.1 branch in Google Code to
GitHub in any easy manner. I had asked various folks for assistance
in the past, but no help was forthcoming so I had diverting my effort
 to other activities, some OWASP related and some not.

Also, perhaps a further deterrent to me finishing this up as I look at the
uses of ESAPI, about 99% of the uses are either only for the encoders or
validators (or both) and I've only seen / heard of maybe 3 cases where
someone was even thinking of using ESAPI crypto (which aside, I sometimes
have talked them out of unless they were already using ESAPI for other
things; I don't feel anyone should have to suffer the jar dependency
baggage that comes with ESAPI if there are other good solutions such
as KeyCzar available). So it seems a fair assumption if relatively few
people are using ESAPI crypto to begin with, few will benefit from a
fix.

Okay, so there. I've laid my soul bare. I really would like someone to
help out with this, but it has to be someone who not only knows Java but
who has more than a superficial knowledge of crypto. I know a few people
like that, but I have been unable to convince any of them to commit time
out of their already busy lives to assist. An ESAPI evangelist, I am not.

So, I guess the *really* bad news is that I have stopped saying when
CVE-2013-5960 will be fixed. I have a redesign done and have even
documented it, but really need a peer whom I can trust--who has some
Java and crypto expertise--to bounce some final ideas off. And someone
with some in depth knowledge of Maven / pom.xml and git / GitHub would
be very helpful as well.  Any takers?

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.


More information about the Esapi-dev mailing list