<div dir="ltr">I am curious about the disclosure policy / approach for reported vulnerabilities in code we provide. Who is the current esapi leader we should ask?<br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">
<br>--<br>Michael Coates | OWASP | @_mwc<br><br></div></div>
<br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 10:54 PM, Jim Manico <span dir="ltr"><<a href="mailto:jim.manico@owasp.org" target="_blank">jim.manico@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>Applied crypto is tough. The crypto in our flagship project, ESAPI for Java, is broken, see below. The NSA donated a review for us and missed this (big surprise). There is no hiding this, it was publicly reported on the ESAPI-dev list.</div>

<div><br></div><div>It's going to take a major release to fix this. I would like to suggest that we pay Kevin Wall to push a new revision for us.</div><div><br></div><div>We also need to disclose this somehow to warn the many users of this project.</div>

<div><br></div><div>You can read about the details below as we as on the ESAPI-dev list.</div><div><br></div><div>Thoughts?</div><div><br><div>--</div><div>Jim Manico</div><div>@Manicode</div><div><a href="tel:%28808%29%20652-3805" value="+18086523805" target="_blank">(808) 652-3805</a></div>
</div>
<div><br>Begin forwarded message:<br><br></div><blockquote type="cite"><div><b>From:</b> "Kevin W. Wall" <<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>><br><b>Date:</b> August 22, 2013, 7:44:50 AM GMT+02:00<br>

<b>To:</b> Jeff Walton <<a href="mailto:noloader@gmail.com" target="_blank">noloader@gmail.com</a>><br><b>Cc:</b> Jim Manico <<a href="mailto:jim.manico@owasp.org" target="_blank">jim.manico@owasp.org</a>>, Chris Schmidt <<a href="mailto:chris.schmidt@owasp.org" target="_blank">chris.schmidt@owasp.org</a>>,  Dave Wichers <<a href="mailto:dave.wichers@owasp.org" target="_blank">dave.wichers@owasp.org</a>>, Jeff Williams <<a href="mailto:Jeff.Williams@owasp.org" target="_blank">Jeff.Williams@owasp.org</a>><br>

<b>Subject:</b> <b>Re: [Esapi-dev] ESAPI Java and Authenticated encryption implementation</b><br><br></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><div><div><div><div><div>I like the idea of the labels on the KDF. You and I have even discussed<br>

it in the past.<br><br>The problem is how to extract a label to apply automagically.<br>
</div>Only thing I could think of is to use the IP address or the MAC<br>address (much harder to get on the web; client IP is hard even<br></div>given proxies, NAT, etc.). Otherwise we 1) break backward<br>compatibility and 2) make people specify it, which means an<br>


interface change which means clients have to change their<br>code not just deploy an new ESAPI jar.<br><br></div>There is a timestamp in serialized cipher text. That's the only other<br></div>simple solution I can think of that wouldn't require interface changes.<br>


</div>Ideally, one would like to see some sort of user identity or purpose<br>string used for the label, but I can't see how to do that w/out changing<br></div>encrypt() / decrypt() interfaces (or adding new ones to an already,<br>


</div>overbloated Encryptor interface).<br><br></div>Long term, best thing would be to start from scratch. If I had to do it<br>all over again, I would have bit the bullet and implemented CMS<br>(Cryptographic Message Syntax as defined in RFC 5652).<br>


At least it is standard. There are lots of implementations in C/C++,<br>but none that I saw (at least at the time) for .NET or PHP or<br>any of the other implementations that we had at the time.<br><br></div><div>I'm beginning to see the wisdom of Jim's pleading with me to<br>


</div><div>implement ESAPI crypto w/out ESAPI. At least I could<br></div><div>change the interfaces to better fit the needs of the crypto<br>community. I have been reluctant to do so because if I<br>forked it I would have 2 projects to apply bug fixes to when<br>


</div><div>stuff like this inevitably happens.  If I do that, then Chris is<br>going to have to take over the ESAPI Java project full time<br></div><div>or Jim or someone new has to step up and drive it.<br><br></div><div>


Damn, why couldn't have this happened closer to the<br>ESAPI hack-a-thon at AppSecUSA? Then at least I would<br>have some interesting stuff to work on.<br><br></div><div>Sigh. I can tell that I'm not going to get a lot of sleep tonight.<br>


</div><div>Insomnia for 2 nights in a row. Woohoo!<br><br></div><div>-kevin<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 1:03 AM, Jeffrey Walton <span dir="ltr"><<a href="mailto:noloader@gmail.com" target="_blank">noloader@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Aug 21, 2013 at 11:16 PM, Kevin W. Wall <<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>> wrote:<br>



> ...<br>
><br>
</div><div>> Also, there is a high-level design document at:<br>
> <a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-crypto-design-goals.doc" target="_blank">http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-crypto-design-goals.doc</a><br>



> (Sorry; it's a MS Word doc. I can convert if to PDF if need be.)<br>
</div>Page 9, Section 3.1.2: "... Providing a MAC key that is different for<br>
each unique encryption key is the best policy ...".<br>
<br>
If you look at, for example, some of the RFCs, you will see the use of<br>
a label. The label ensures a key derived under the same password with<br>
different parameters is different. So, if using the KDF for<br>
AES/CBC/PKCS5, then you might do:<br>
<br>
    key = KDF( "AES/CBC/PKCS5", <password>, <salt>, <count>)<br>
<br>
If you use it with TripleDES, then it might look like:<br>
<br>
    key = KDF( "3DES/CBC/PKCS5", <password>, <salt>, <count>)<br>
<br>
And with an HMAC:<br>
<br>
    key = KDF( "AES/CBC/PKCS5" || "HMAC-SHA1", <password>, <salt>, <count>)<br>
<br>
Because the HmacLen may be tampered, go ahead and do:<br>
<br>
    key = KDF( "AES/CBC/PKCS5" || "HMAC-SHA1" || HmacLen, <password>,<br>
<salt>, <count>)<br>
<br>
The labels ensure the same password produces different results under<br>
different uses.<br>
<br>
If Phillip lops off your HMAC and tampers with the serialization, then<br>
the different labels ensure different keys are derived, so the plain<br>
text should remain unrecoverable.<br>
<div><div><br>
Jeff<br>
<br>
>> On Wed, Aug 21, 2013 at 10:14 PM, Jeffrey Walton <<a href="mailto:noloader@gmail.com" target="_blank">noloader@gmail.com</a>><br>
>> wrote:<br>
>> > On Wed, Aug 21, 2013 at 9:01 PM, Kevin W. Wall <<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>><br>
>> > wrote:<br>
>> >> ...<br>
>> >>><br>
>> >>> The problem is that the MAC validation can be bypassed under certain<br>
>> >>> conditions.<br>
>> >>><br>
>> >>> Condition #1: if the Ciphertext is tampered to contains a MAC that is<br>
>> >>> null<br>
>> >>> ...<br>
>> >>> Condition #2: if the cipherSpec is tampered to use a different mode<br>
>> >>> that<br>
>> >>> is not part of combinedCipherModes<br>
>> > This was very clever! I wonder how many other systems suffer the same.<br>
>> ><br>
>> > I'd recommend throwing if the tag is less than 64-bits. Recommend<br>
>> > 96-bit tag for data in transit; and a 128-bit tag for data at rest.<br>
>> > Its consistent with NIST SP 800-38D.<br>
>> ><br>
>> >>> ....<br>
>> >>> The design to compute the mac for only a portion of the message is<br>
>> >>> kind of<br>
>> >>> broken. The mac should cover all parameters serialized. Authenticated<br>
>> >>> encryption implementation should not use logic that support optional<br>
>> >>> MAC.<br>
>> > Another good find.<br>
>> ><br>
>> >> I had thought of including EVERYTHING, but those on the crypto list<br>
>> >> said<br>
>> >> that you really only needed to MAC the<br>
>> >> IV+ciphertext.<br>
>> > I may have lead you astray here. My apologies.<br>
>> ><br>
>> > In the systems I build, there's only {IV, CT, MAC} - and no optional<br>
>> > parameters. So my rule is to MAC everything, which for me is IV and<br>
>> > Ciphertext. On occasion I also need to include the version.<br>
>> ><br>
>> > For reference, the rule to MAC everything is called "Semantic<br>
>> > Authentication", a.k.a "The Horton Principle" from Horton Hears a Who.<br>
>> > It was introduced by Wagner and Schneier in "Analysis of the SSL 3.0<br>
>> > protocol" back in 1995,<br>
>> > <a href="https://www.schneier.com/paper-ssl-revised.pdf" target="_blank">https://www.schneier.com/paper-ssl-revised.pdf</a>.<br>
>> ><br>
>> > The Horton Principle is great at finding protocol cruft: if a field<br>
>> > has value then it must be authenticated. The contrapositive ferrets<br>
>> > the cruft: if a field does not need authentication, then its useless<br>
>> > and can be removed. Start removing fields and see which ones really<br>
>> > have value ;)<br>
>> ><br>
>> > Don't apply The Horton Principle to code signing in Apple, BSD and<br>
>> > Android (probably et al). You will be horrified at what you find. I<br>
>> > warned Android Security about the problems a year or so before Bluebox<br>
>> > released their "Master Key" exploit.<br>
>> ><br>
>> >> OK, here's what I'm not getting about Condition #2. In your PoC code,<br>
>> >> you<br>
>> >> had ESAPI.properties set to:<br>
>> >><br>
>> >>     Encryptor.CipherTransformation=AES/OFB/NoPadding<br>
>> >>     Encryptor.cipher_modes.combined_modes=OFB<br>
>> >>     Encryptor.cipher_modes.additional_allowed=CBC<br>
>> >>  ...<br>
>> >> So, what I am not understanding about your Condition #2 is how your<br>
>> >> exploit<br>
>> >> will get past this first test (right after checking if either of the<br>
>> >> parameters are null)?<br>
>> > So, my [uneducated] opinion: don't waste time debating the ways a<br>
>> > Turing machine does or does not stop. Validate the parameters and<br>
>> > throw on failure. Validate the MAC length is at least 64-bits and<br>
>> > throw otherwise.<br>
>> ><br>
>> > Or, put another way: Meh... fix it and move on.<br>
>> ><br>
>> >> Anyhow, I thank you again for looking hard at this. I was never real<br>
>> >> comfortable<br>
>> >> with the way I was doing the serialization and where the MAC was<br>
>> >> applied,<br>
>> >> but tried to catch other issues in other manners (such as the earlier<br>
>> >> test<br>
>> >> for cipher mode).<br>
>> > So, when the changes are cut-in, be sure the new version derives to a<br>
>> > new set of keys. That is, the same password or shared secret in V3<br>
>> > should derive to a different key than in V4. Otherwise you'll be<br>
>> > susceptible to a downgrade attack like Winzip.<br>
>> > <a href="http://cse.ucsd.edu/node/1340" target="_blank">http://cse.ucsd.edu/node/1340</a>.<br>
</div></div></blockquote></div><br><br clear="all"><span class="HOEnZb"><font color="#888888"><br>-- <br>Blog: <a href="http://off-the-wall-security.blogspot.com/" target="_blank">http://off-the-wall-security.blogspot.com/</a><br>
"The most likely way for the world to be destroyed, most experts agree,<br>

is by accident. That's where we come in; we're computer professionals.<br>We *cause* accidents."        -- Nathaniel Borenstein
</font></span></div>
</div></blockquote></div>
<br>_______________________________________________<br>
Owasp-board mailing list<br>
<a href="mailto:Owasp-board@lists.owasp.org">Owasp-board@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-board" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-board</a><br>
<br></blockquote></div><br></div>