[Owasp-board] [Esapi-dev] ESAPI Java and Authenticated encryption implementation
jim.manico at owasp.org
Thu Aug 22 23:34:02 UTC 2013
If you follow the thread between Jeff Walton and Kevin Wall, you will
see that #1 and #2 and close to being done.
I'm very much eager to hear what you and Kevin think is the best plan
of attack. I recommend you pull Jeff Walton (noloader at gmail.com) into
the conversation due to his very deep background in applied crypto.
Please CC me in as well, I am very familiar with the code in question.
In the meantime I will respect your wishes and give you and Kevin time
to figure out a plan of action.
On Aug 23, 2013, at 12:13 AM, Chris Schmidt <chris.schmidt at owasp.org> wrote:
> Wow - let's slow this train down a minute...
> 1) I am in-fact, in the process of preparing a migration to GitHub
> 1A) That has absolutely nothing to do with the bug...
> 2) We will formulate a plan of attack to address this issue and
> distribute the proper disclosures publicly as was decided when we
> discussed the vulnerability disclosure policy for OWASP projects many
> many moons ago.
> * Step 1 - Verify the vulnerability
> * Step 2 - Determine if there is a workaround solution that can be
> employed until a proper patch is released
> * Step 3 - Release a disclosure publicly detailing the vulnerability
> and how it can be resolved.
> * Step 4 - Develop a regression test to prove the vulnerability
> * Step 5 - Fix the vulnerability
> * Step 6 - Release a patch with another disclosure demonstrating the
> vulnerability has been resolved
> At the last OWASP Summit in Portugal I hosted a talk on this very
> subject, which 1 person (Brad Causey) actually showed up to. There is a
> lot of code in OWASP Projects and *no one* is perfect - I was attempting
> to lay the groundwork for how this should be addressed when it did come up.
> We are talking about a library that is literally used by thousands of
> organizations to secure their applications to one degree or another so
> shouting out to the world that there is an issue in the crypto may seem
> at first to be the responsible approach, but in fact it is putting those
> 4000 organizations at greater risk. While this issue is currently public
> since it is on the ESAPI-Dev list, it is still a fairly limited audience
> of people that is aware of this, and arguably most of them are not *bad
> guys* as it were.
> I think that we need to maintain a strong sense of responsibility as we
> work through this issue following the steps I outlined above to
> remediate and notify. The cat is out of the bag, but he has only made it
> to the living room right now - anyone looking in the living room will
> see him but perhaps it isn't the right time to put his picture up in
> Times Square until we have a little more information for our users?
> This is my $0.02 and I will be working with Kevin over the next couple
> days to figure out a detailed plan of attack for this issue.
> On 8/22/13 3:38 PM, Jim Manico wrote:
>> The next step is to give Kevin and Chris some time to make a public disclosure statement. I am fairly sure they are both willing to do the right thing here since the cat is already out of the bag. If there is no action in this front, I'll do it myself - but I'd much rather see this come from the ESAPI project leaders.
>> Unfortunately, the reporting individual decided to disclose publicly instead of giving us the time to fix it first. If the disclosure was private, then I think Kevin and Chris should have been given the time to patch before the official bug report. The only reason I think we need to make a public official statement on this now is because the bad guys already have this information.
>> Right now there are over 4000 organizations that depend on ESAPI for security of critical systems. We need to let them know they are depending on insecure software and provide guidance as to how to fix the problem.
>> Transparency does two things : it breeds trust and it defeats cronyism.
>> Kevin Wall and Chris Schmidt have spent countless hours working on ESAPI. In no way do I want to shame them.
>> But this bug is so critical, that I think we should be willing to pay Kevin or someone else to invest serious time in providing a major revision of ESAPI (version 2.5?) that fixes this problem as soon as possible.
>> My 2 cents,
>> - Jim
>>> Hmm... Good point, Jim.
>>> What next, indeed! Can we have some suggestions on how to move forward with
>>> this issue? Kevin and Chris, I would like to hear your thoughts on how we
>>> can rectify the situation.
>>> On Thu, Aug 22, 2013 at 12:30 PM, Kevin W. Wall <kevin.w.wall at gmail.com>wrote:
>>>> Jim... agree. In this specific case, using GitHub would not make a
>>>> difference. The person reported this referenced the Google Code site and
>>>> for whatever reason chose to post to the ESAPI Dev mailing list rather than
>>>> submitting a Google issue. (Not that I'm against using GitHub though. Chris
>>>> and I have discussed it.)
>>>> Sent from my Droid; please excuse typos.
>>>> On Aug 22, 2013 3:24 PM, "Jim Manico" <jim.manico at owasp.org> wrote:
>>>>> Google Code offers bug tracking and anyone can submit a patch to us...
>>>>> Jim Manico
>>>>> (808) 652-3805
>>>>> On Aug 22, 2013, at 9:06 PM, Dennis Groves <dennis.groves at owasp.org>
>>>>>> This is a great reason for the code to be in github, we could then
>>>>> leverage the github infrastructure for bug tracking to identify and
>>>>> communicate serious issues such as this, as well as giving the community
>>>>> open access to fix it.
>>>>>> On 22 Aug 2013, at 3:45, Michael Coates wrote:
>>>>>>> I am curious about the disclosure policy / approach for reported
>>>>>>> vulnerabilities in code we provide. Who is the current esapi leader we
>>>>> should ask?
>>>>>> [Dennis Groves](http://about.me/dennis.groves), MSc
>>>>>> [Email me](mailto:dennis.groves at owasp.org) or [schedule a meeting](
>>>>>> Unless someone like you...cares a whole awful lot...
>>>>>> nothing is going to get better...It's not."
>>>>>> -- The Lorax
More information about the Owasp-board