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

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

Laszlo,

I got your point, and understood the requirements for source released platforms.
I think it's something needing all vendors who have concerns to get agreement
with. It's part of 'optimization' Vincent mentioned in another email. Stephano
will set up meetings to drive related discussions.

Jian

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, April 16, 2019 1:04 AM
> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
> Cc: 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
> 
> On 04/15/19 07:36, Wang, Jian J wrote:
> > 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.
> 
> They don't need to agree on the latest date to release the fix. They
> need to agree on the earliest date of release though. That's the *point*
> of an embargo.
> 
> Assume Red Hat is invited to discuss a security issue in one of the edk2
> modules that affects OVMF. Red Hat participates in the analysis, patch
> review, maybe Red Hat even contributes one or two of the patches. (We
> could even report a security issue in the first place; there have been
> examples.)
> 
> After a bit of work, everyone agrees that patches prepared by the
> infosec group are fine, and we set an embargo / earliest release date,
> before informing the grand public, and posting the upstream patches to
> edk2-devel.
> 
> However, assume that every vendor is permitted to ship the fixes
> whenever they want, in their own products. Great, Red Hat ships the OVMF
> firmware as host-OS *software* packages, as binary and as *source* RPMs.
> So, if involved vendors themselves are not required to adhere to the
> embargo in their own products, then let's say Red Hat ships the patches
> in *source code* form, complete with issue description / commit
> messages, in just two weeks after the patches are considered
> functionally appropriate, by the infosec group.
> 
> All the while physical platform vendors might need half a year or more.
> 
> Would all vendors like that? I don't think so.
> 
> And, if Red Hat is expected to wait for physical vendors, we certainly
> expect the same in return.
> 
> This is not a theoretical question: until now, we've *significantly*
> delayed product features at least twice, waiting for physical firmware
> vendors, under security issues that we have reported.
> 
> > The longer a security issue exists in a product, the more damage
> > may be caused potentially.
> 
> No doubt.
> 
> This is why setting embargo dates is a trade-off. Any given vendor wants
> to get the fix as quickly as possible to its own users, obviously. At
> the same time, they should not screw over the users of *other* vendors
> (e.g. users of their competitors) -- so that next time, they can
> reasonably expect the other vendors to wait for them, in exchange.
> 
> All vendors need to take some extra risk in order to protect the users
> of the *other* vendors. How long exactly vendors are willing to wait for
> each other should be a case-by-case discussion, but the generic
> principle is that they do set a *common* earliest release date.
> 
> > 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.
> 
> I disagree.
> 
> What you describe implies shipping the fix in binary-only form, or with
> other means of obfuscation.
> 
> This would hugely discriminate against open source vendors, as they ship
> all fixes (security or not) in both binary and source form.
> 
> > 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.
> 
> Integrate into their products: yes. Release to their users: no.
> 
> > 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.
> 
> Agreed!
> 
> Thanks,
> Laszlo
> 
> > Vincent, please correct me if anything wrong here.
> >
> > Regards,
> > Jian
> >>
> >> Thanks
> >> Laszlo
> >>
> >>
> >
> 
> 
>