[Esapi-dev] Crypto and the "ESAPI for Java" release 2.1.0
jim.manico at owasp.org
Tue Sep 3 08:56:36 UTC 2013
Just to be clear, the following release was due to a crypto bug in ESAPI for Java. This is a significant issue. If you are currently depending on the default ESAPI crypto configuration settings,
then we recommend that you upgrade, decrypt your data, and re-encrypt with with ESAPI 2.1.0.
Thank you to Kevin and everyone else who worked on this issue.
> A new version of ESAPI, release 2.1.0, has been uploaded to
> both the Google Code downloads list as well as being made
> available via Maven Central.
> Full release notes are available with the Google Code download at
> Most importantly, if fixes Google Issue #306 which is closed with this
> release. See
> for details of that issue.
> Please note that this new ESAPI jar (esapi-2.1.0.jar) is *NOT* a
> signed jar. OWASP's code signing certificate had expired. We will
> sign the jar and re-release this (or possibly another patch release)
> once we obtain the new code signing certificate.
> Note that if you had been following along the discussion of Philippe Arteau's
> finds first posted to the ESAPI-Dev mailing list (for details, see
> this is what Google Issue #306 addresses. I have applied for a CVE identifier,
> and once obtained, we will left everyone know the CVE ID and get this
> appropriately documented for NIST's NVD, etc.
> While technically, this Google Issue is an "exposure" rather than a
> "vulnerability" (in Mitre's usage of the terms at https://cve.mitre.org/),
> it is still important that you patch this, especially if you were using
> ESAPI's symmetric crypto with CBC mode (the default) to encrypt something
> that might be exposed to the Internet, such as HTTP parameters or
> HTTP cookies, as this exposure would allow one to develop a padding
> oracle attack. (Note that if you are using one of the "combined"
> cipher modes such as CCM or GCM, you would not be affected by this
> Finally, while it looks as though there were a lot of files recently
> changed (there were), the actual fix boiled down to changing 2 lines
> of code...one to change a log message and the other to return 'false'
> rather than 'true'. Because that original code branch was there to
> handle backward compatibility with ESAPI 1.4 (in hindsight, a really
> bad idea; my bad for not resisting more than I did), changing the
> code to return 'false' broke that backward compatibility. Consequently,
> I removed the deprecated encrypt() / decrypt() methods from the Encryptor
> interface. Most of the other changes was either new test cases, general
> code cleanup, or related to the removal of those interface methods.
> If you have any questions, feel free to send them to the list or directly
> to me and I will attempt to answer them as I find time.
> Compute securely,
> P.S.- Special thanks to Philippe Arteau for bringing this to our
> attention and to Chris Schmidt for building the
> final release deployment and fixing the pom.xml that I had
> apparently screwed up.
More information about the Esapi-dev