[Esapi-user] [Esapi-dev] ESAPI Random Number Generation Broken

Kevin W. Wall kevin.w.wall at gmail.com
Mon Jun 30 03:39:59 UTC 2014


On Sun, Jun 29, 2014 at 9:47 PM, Jim Manico <jim.manico at owasp.org> wrote:

> ​[snip]​
>
> I am upset that the ESAPI team "blew off" this "poor CSRF token entropy"
> finding in 2011 when I was asked not to report Rook's finding even when his
> results were repeatable. It led to me leaving the project at the time. This
> is not just you, it was a group decision that I disagreed with. I did wait
> two years before disclosure and I'm glad to see it fixed.
>
​
Either I'm missing something, I'm more forgetful than I realize,
or I need some clarification.​  First of all, the first that I'm
seeing of this was some email that Jim forwarded from me that
came from David Rook back on Feb 21, 2012, not 2011.  Did he
actually discover this earlier?

Second of all, I never recall anyone saying that we shouldn't
report this as a Google Issue. I do recall that several of us
wanted to better understand what was causing the unintuitive
Burp Sequencer results and there was a LOT of theories regarding
the explanation, but I personally don't recall anyone trying to
sweep in under the table. In fact as the years went by, I had
just assumed that their was a Google issue opened on it. I'm
surprised now to see that Jim opened issue 323 only back in
April of this year.

I personally had spent some time trying to get to the bottom
up it and come up with and explanation of the Burp Sequencer
results, but I gave up when I couldn't find a root cause. The
only thing that I did convince myself off was that it didn't
have anything at all to do with not reseeding SecureRandom.
(Note: Don't take that as a fact that I'm in support of the
use of DefaultRandomizer as a singleton or that we never
reseed it; I'm just stating that there was no way and no how
that we would ever seen any bias such as we observed with the
Burp Sequencer tests that David Rook ran in only 20k tokens.)

And truthfully, since the ESAPI crypto didn't use ESAPI Randomizer
and I wasn't convinced that it wasn't specifically a crypto
related problem, I lost interest and got involved with other
OWASP projects during GSoC and work on the Dev Guide.

So we all stand equally guilty to the OWASP community. Let's
get past that and come together and get it resolved.

First off is, Jeff has submitted a fix for this. Are we all in
agreement that foxes the root cause of this observed poor
results in the Burp Sequencer tests that David Rook first
made us aware of?

If we are all in agreement to that, how do we want to proceed?

Obviously a new version (2.1.1 or 2.1.0.1) would be the next in
line. Do we wish to include anything else in this new release?
Who will help out with it? Where should we host the new release
(besides Maven Central)? Should we have a CVE that we create for
this?

Personally, I would like us to work together to do what's best
for the community of ESAPI users and most of all for the OWASP
reputation, and we are NOT clearing doing now.

If a few of you wish to vent your frustrations / feelings, I
think that that should be done on a personal level, and not
in public here. When I was being brought up, I was taught that
you praise in public and admonish in private and I still think
that's pretty good advice.

Maybe I'm sticking my neck in where it doesn't belong, but I'm
trying to be a peace maker here for the could of the OWASP
community and all this sniping is not helping. I know that,
you both know that, and everyone that is on these ESAPI
lists knows that as well.

So let's please act respectfully to each other...at least in
public so as not to further sully OWASP brand.

And if you want to flame me in person, that's fine. But if
you wish to do it in public, let's please keep it civil, polite,
and respectful and treat others like you would like to be treated.

That's all I have to say. Thanks for listening.

-kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-user/attachments/20140629/5d43b115/attachment.html>


More information about the Esapi-user mailing list