Re: [edk2-devel] [RFC] Propose update of security bug handling process

["Wang, Jian J" <jian.j.wang@intel.com>]

Laszlo,


> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Friday, April 12, 2019 8:52 PM
> To: Wang, Jian J <jian.j.wang@intel.com>
> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>;
> Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming
> <liming.gao@intel.com>
> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling process
> 
> (Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the address
> list, as that should be a list to receive automated Bugzilla email.)
> 
> On 04/12/19 10:43, Wang, Jian J wrote:
> > Hi,
> >
> > Currently, we generally follow below process to handle security bugs.
> > But there're no document to describe the detailed working flow. There're
> > also discussions on lacking of important information, poor issue description
> > and no timely notification on update, etc.
> >
> >        "0 - New Security Bug"
> >   -> "1 - Triage"
> >   -> "2 - Mitigation"
> >   -> "3 - Embargo"
> >   -> "4 - Disclosure"
> >   -> "5 - Exit";
> >
> > I have a proposal at following page to elaborate the process and try to address
> > all problems reported so far. Following content is for discussion only. Once the
> > process is finalized, it will be moved to official edk2 wiki page.
> >
> > https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-
> issue-process
> >
> > Any opinions and suggestions are welcomed.
> 
> Thanks for working on this!
> 
> I've skimmed the diagrams. I have one suggestion and one request for
> clarification.
> 
> 
> - Suggestion: a CVE number should be requested (if appropriate) as soon
> as the CVSS score (i.e. the nature of the vulnerability) has been
> calculated, and it has been determined whether platforms in practice
> (both physical and virtual) are affected.
> 
> This is important because vendors should have a common (cross-vendor)
> reference for tracking the issue even in their own internal systems, and
> this reference should be available to all vendors internally as soon as
> upstream determines the issue has security impact.
> 
> Additionally, as soon as members begin collaborating on actual patches,
> the patches should carry the CVE number in the subject line(s).
> 

No strong opinion. If no objection, let's do as you suggested.

> 
> - Request for clarification: the Embargo diagram should clarify that
> vendors are *forbidden* from shipping fixes in their own products,
> regardless of format, until the embargo is lifted. The point of an
> embargo is to release/ship the fixes all at once, across all vendors.
> 
> It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3
> Open BZ To Public" / "4.4 Open source the patch". That's the interval
> when vendors would release their fixes all together.
> 
> It's *not* OK, for any vendor, to ship their own fixes before "3.5
> Announce Embargo End".
> 
> Yes, this means that some vendors will have to wait on other vendors,
> and some vendors will have to work more hastily than they are used to,
> for the sake of other vendors. This is what coordinated/responsible
> disclosure means, and it aims to benefit the cumulative user base.

I think it's impractical to ask all vendors to release the fixes at the same
time. The longer a security issue exists in a product, the more damage
may be caused potentially. I don't think any vendor want to risk that. But
it's reasonable and feasible to ask vendors not to expose the issue details
in the embargo period.

So my understanding is that embargo is for preparing the security issue
information disclosure purpose, during which all vendors should integrate
the mitigation solution into their products. Actually, once someone else
find the same issue and open it to public in the period, we should end the
embargo immediately. This step is missing in the work flow chart.

Vincent, please correct me if anything wrong here.

Regards,
Jian
> 
> Thanks
> Laszlo
> 
>