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

["Andrew Fish" <afish@apple.com>]

[-- Attachment #1: Type: text/plain, Size: 8440 bytes --]



> On Apr 15, 2019, at 11:06 PM, Wang, Jian J <jian.j.wang@intel.com> wrote:
> 
> 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.
> 

As Laszlo points out we are an open source project. Seems like how to release binaries is more the purview of the UEFI USRT, so I agree a meeting is a good idea. 

Thanks,

Andrew Fish

> Jian
> 
>> -----Original Message-----
>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> [mailto: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 <mailto:jian.j.wang@intel.com>>; devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>> Cc: Zimmer, Vincent <vincent.zimmer@intel.com <mailto:vincent.zimmer@intel.com>>; Cetola, Stephano
>> <stephano.cetola@intel.com <mailto:stephano.cetola@intel.com>>; Gao, Liming <liming.gao@intel.com <mailto: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
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 19133 bytes --]