[seam-dev] Re: Adding a security audit to the Seam QA (release) process

[Anil Saldhana]

Pete Muir wrote:
>
> On 16 Oct 2008, at 14:22, Anil Saldhana wrote:
>
>> Pete Muir wrote:
>>>
>>> On 16 Oct 2008, at 14:04, Anil Saldhana wrote:
>>>
>>>> Pete,
>>>> thanks for the information.   I just returned from a software forum 
>>>> conducted by the US Government. I got the feeling that there is 
>>>> some element of internal push toward web 2.0 and open source 
>>>> software in the government space. They are pretty strict on 
>>>> security practices etc and they view open source software as a form 
>>>> of COTS that cannot be trusted.  I am sure this extends to 
>>>> governments and financial institutions around the world. :)
>>>>
>>>> Security conscious customers want to see a proactive approach 
>>>> (secure design practices etc) rather than a reactive approach 
>>>> (patch management).  This can be a key differentiator for us.
>>>>
>>>> We have to adopt a global security policy (vulnerability reporting, 
>>>> handling and public notification).  I am sure Marc will have the 
>>>> lead role in this.  The email alias (security at jboss.org) + online 
>>>> vulnerability reporting contact form + 2-way feedback cycle/rapport 
>>>> with the National Vulnerability Databases (Mitre for CVE and NIST 
>>>> for NVSD) is all we need as a start IMO. :)
>>>
>>> We feel we are missing a page on jboss.org that outlines our 
>>> notification procedure. We currently describe how you report a 
>>> vulnerability to us, but *not* what we do when one is discovered. We 
>>> need this information in one place, and very clearly stated;  We 
>>> have this on http://www.redhat.com/security/team/contact/ but not on 
>>> jboss.org. I think we need a similar page, including a link to 
>>> http://www.redhat.com/security/updates/advisory/ and a link to 
>>> http://www.redhat.com/mailman/listinfo/jboss-watch-list. WDYT?
>> Yeah, that is what I was referring to.  We have to come up with a 
>> policy (which I plan to discuss with MarcS) as to how we do things at 
>> JBoss with reference to security and put it up on
>> http://jboss.org/security
>
> Do you have a timescale for said policy. If it's short (e.g. a month) 
> then we'll hold off going our own way, otherwise we will put up some 
> words on seamframework.org for the interim.
>
I would say a month or certainly end of the year. The Security response 
team may already have answers because they have been doing this for a 
long long time (fedora/rhel).
>>
>>
>> We need to figure out how we handle things - vulnerabilities that are 
>> public information and those that are extremely sensitive in nature 
>> (analogy, the DNS flaw that got leaked - Dan Kaminsky episode). We 
>> should rope in all the .org leads into discussion. :)
>
> Ok, where do you want to discuss this?
I will create a mailing list for this and add all the leads on this one. 
We can then discuss there.  I know, it is one more ML. But we can have 
the discussions archived there. :)
>
>>
>>
>> My presentation from Tuesday is:
>> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-docs/trunk/presentations/SecuringOpenSource.pdf 
>>
>>
>>
>>>
>>>>
>>>>
>>>> Irrespective of these processes, please continue with your 
>>>> aggressive innovation. ;)
>>>>
>>>> Cheers,
>>>> Anil
>>>>
>>>> Pete Muir wrote:
>>>>> Marc, Christian, Jay and I met and discussed this. Here is the 
>>>>> outcome:
>>>>>
>>>>> 1) Create a wiki page and list out the "top ten" web security 
>>>>> problems. This page should list not actual exploits, but the 
>>>>> underlying problems (for example XSS and XSRF). This page will 
>>>>> also link to good resources describing the problem, and common 
>>>>> solutions. Christian and Marc will collaborate to build this page.
>>>>>
>>>>> 2) Create a second wiki page to discuss how these problems affect 
>>>>> the various points at which Seam is exposed (e.g. JSF, Wicket, 
>>>>> remoting), the resources collected for (1) can be used to identify 
>>>>> and help close any holes. Currently there is no-one leading this 
>>>>> effort.
>>>>>
>>>>> 3) At release time QA will run through the list from (1) and 
>>>>> identify if there are any new features added to Seam which could 
>>>>> be affected. If there are, and the developer has not documented 
>>>>> them on (2), QA will discuss the problem with the developer. 
>>>>> Jay/QA to lead.
>>>>>
>>>>> 4) Building out a "Securing your application" chapter and tools 
>>>>> which Seam users can follow to secure their application built 
>>>>> using Seam. An example of this is provide a tool which can 
>>>>> generate a unique token to prevent XSRF attacks. Currently there 
>>>>> is no one leading this, but the same person as (2) should own it IMO.
>>>>>
>>>>> If someone would like to volunteer for (2) & (4) who has an 
>>>>> interest in security, that would be great :-)
>>>>>
>>>>> We also discussed the process for dealing with found exploits:
>>>>>
>>>>> 1) We already tell people to email security at jboss.org with any 
>>>>> suspected problems.
>>>>>
>>>>> 2) We need to publish the response policy, probably on jboss.org. 
>>>>> Christian will talk to Anil about publishing this, and the jboss 
>>>>> advisory list info.
>>>>>
>>>>> 3) It is at the discretion of the JBoss Security Response Team to 
>>>>> decide whether to embargo an issue, and discuss just with a 
>>>>> developer, and not make it public until there is a release or 
>>>>> whether the issue is more general and should be discussed on 
>>>>> seam-dev at lists.jboss.org
>>>>>
>>>>>
>>>>> On 6 Oct 2008, at 11:55, Pete Muir wrote:
>>>>>
>>>>>> Marc,
>>>>>>
>>>>>> Sounds great. I'm in the UK, so GMT+1 atm. Christian, will you 
>>>>>> join us to discuss?
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> On 6 Oct 2008, at 11:13, Marc Schoenefeld wrote:
>>>>>>
>>>>>>> Hi Pete,
>>>>>>>
>>>>>>> that sounds like a good plan, let's schedule some initial 
>>>>>>> planning for
>>>>>>> next week, because this week I am quite busy with after-PTO 
>>>>>>> workload
>>>>>>> and SOA testing. How about next tuesday? BTW, which timezone are 
>>>>>>> you
>>>>>>> in,  maybe we can start with a phone chat?
>>>>>>>
>>>>>>> The first things that come into my mind are JSF view state 
>>>>>>> injection,
>>>>>>> XSS in all different kinds, remoting misuse, insecure servlet 
>>>>>>> mappings.
>>>>>>> During this week I will catch with the current Seam codebase by
>>>>>>> findbugs-ing through it, and maybe already stumble over the one or
>>>>>>> other place to start poking into.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Marc
>>>>>>>
>>>>>>> Pete Muir wrote:
>>>>>>>> Hi Marc,
>>>>>>>>
>>>>>>>> Something that we've been discussing is the idea creating a 
>>>>>>>> security
>>>>>>>> audit checklist that will cover Seam and the ways it interacts 
>>>>>>>> with
>>>>>>>> the outside world; initially, we want to focus on JSF, Seam 
>>>>>>>> Remoting
>>>>>>>> (Ajax) and Servlet but we will also consider adding in WS 
>>>>>>>> including
>>>>>>>> JAX-RS, Wicket, GWT and perhaps others, though these are what I 
>>>>>>>> can
>>>>>>>> think off. This checklist would then be added to the Seam QA 
>>>>>>>> process
>>>>>>>> (which is run through at release time).
>>>>>>>>
>>>>>>>> We were wondering if you would be able to work with us on this? My
>>>>>>>> suggestion is, that as you (I hope ;-) have a good 
>>>>>>>> understanding of
>>>>>>>> the general approaches that could be used to exploit a Seam 
>>>>>>>> that you
>>>>>>>> would be to work with us both on an initial list of areas to 
>>>>>>>> focus on,
>>>>>>>> and then help us develop the checklist.
>>>>>>>>
>>>>>>>> Let us know :)
>>>>>>>>
>>>>>>>> Pete
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Marc Schoenefeld / Red Hat Security Response Team