From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=gY0wPpr3; spf=pass (domain: apple.com, ip: 17.171.2.60, mailfrom: afish@apple.com) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) by groups.io with SMTP; Mon, 15 Apr 2019 23:33:21 -0700 Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x3G6Liu2002685; Mon, 15 Apr 2019 23:33:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=JTiz2/4YqtKxuHGalIexru0q9EKJ01XL0b5zVSasMpA=; b=gY0wPpr3XyW1jNa3oLnXRl+tbj5tpz6Hoh9IhUXZqFr//AveM2lnYTvbYaJDWMniNHiQ mbKtwEYwRc66rvxvH5oC/D0RX4C65AcDJzm2Yksk+h3adgeTPgl8YwaRxz/O4DqASbUk M6QYFMmVSK7SJQZ7vMsshqyH/bCcaI4U3y590yXxVHiDKpIT8cjDmbBZD/yI7lH7URgh esP/LhA8god9dkALKg883mni0PuPQn0YUYFBit74unjjwBuEctwFPDMYap7MDpEXfOmM Pvby+cbxHvlR7lYWqug8JrLwzPajYcEMpOhiwzKXSijU0eUEpIj3b+ZPLc1MFSe3WrRF 8A== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2ruee88w3x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Apr 2019 23:33:19 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PQ100284JJJ0M20@mr2-mtap-s02.rno.apple.com>; Mon, 15 Apr 2019 23:33:19 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PQ100000J4GXL00@nwk-mmpp-sz13.apple.com>; Mon, 15 Apr 2019 23:33:19 -0700 (PDT) X-Va-A: X-Va-T-CD: 61d3c18c1019be229d89ab1390c2f7f0 X-Va-E-CD: 0a8789a0b271adbbcb569c00bd71f8fb X-Va-R-CD: 59158ffb31326d39bf7aed58ebd4aa98 X-Va-CD: 0 X-Va-ID: c50bd673-7619-489d-bed7-9e0b80ae545a X-V-A: X-V-T-CD: 61d3c18c1019be229d89ab1390c2f7f0 X-V-E-CD: 0a8789a0b271adbbcb569c00bd71f8fb X-V-R-CD: 59158ffb31326d39bf7aed58ebd4aa98 X-V-CD: 0 X-V-ID: f1ca4e1d-777b-4af4-8cb7-3cea79170471 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-16_02:,, signatures=0 Received: from [17.234.70.238] (unknown [17.234.70.238]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PQ1001RPJJHIV30@nwk-mmpp-sz13.apple.com>; Mon, 15 Apr 2019 23:33:18 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <705DA4CA-CD81-46DC-96F0-A244590CEF3C@apple.com> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling process Date: Mon, 15 Apr 2019 23:33:13 -0700 In-reply-to: Cc: "lersek@redhat.com" , Vincent Zimmer , "Cetola, Stephano" , "Gao, Liming" To: devel@edk2.groups.io, jian.j.wang@intel.com References: <7ccc8cad-bfc0-e9db-5bae-61c1091b3bab@redhat.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-16_02:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_kKRsiNkJrjAPWrM6/kh+oQ)" --Boundary_(ID_kKRsiNkJrjAPWrM6/kh+oQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Apr 15, 2019, at 11:06 PM, Wang, Jian J 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 ] On Behalf Of >> Laszlo Ersek >> Sent: Tuesday, April 16, 2019 1:04 AM >> To: Wang, Jian J >; devel@edk2.groups.io >> Cc: Zimmer, Vincent >; Cetola, Stephano >> >; Gao, Liming > >> 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 >>>> Cc: devel@edk2.groups.io; Zimmer, Vincent ; >>>> Cetola, Stephano ; Gao, Liming >>>> >>>> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling >> process >>>> >>>> (Dropping 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 >>>> >>>> >>> >> >> >> > > > --Boundary_(ID_kKRsiNkJrjAPWrM6/kh+oQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Apr 15= , 2019, at 11:06 PM, Wang, Jian J <jian.j.wang@intel.com> wrote:

Laszlo,

I g= ot your point, and understood the requirements for source released platform= s.
I think it's somethi= ng needing all vendors who have concerns to get agreement
with. It's part of 'optimization' Vin= cent mentioned in another email. Stephano
will set up meetings to drive related discussions.


As Laszlo points o= ut we are an open source project. Seems like how to release binaries is mor= e the purview of the UEFI USRT, so I agree a meeting is a good idea. <= /div>

Thanks,

=
Andrew Fish

<= div class=3D"">Jian
-----Original Messa= ge-----
From: devel@edk2.groups.io<= /a> [mailto:devel@edk2.groups.io] On Behalf O= f
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, Jia= n 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<= br class=3D"">To: Wang, Jian J <jian.j.wang@intel.com>
Cc: devel@edk2.groups.io; Zimmer, Vince= nt <vincent.zimme= r@intel.com>;
Cetola, Stephano <stephano.cetola@intel.com>; Gao= , Liming
<liming.gao@intel.com>
Subject: Re: [edk2-devel] [RF= C] Propose update of security bug handling
process

(Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the addres= s
list, as that should be a list to receive automated Bugzill= a email.)

On 04/12/19 10:43, Wang, Jian J wrot= e:
Hi,
Currently, we generally follow below process to handle security= bugs.
But there're no document to describe the detailed work= ing flow. There're
also discussions on lacking of important i= nformation, 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
<= /blockquote>address
all p= roblems reported so far. Following content is for discussion only. Once
the
process is finalized, it will be moved to offi= cial edk2 wiki page.

htt= ps://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-<= br class=3D"">
issue-process

Any opinions and suggestions are welcomed.<= br class=3D"">

Thanks for working on this!

I've skimmed the diagrams. I have one suggestion an= d one request for
clarification.


- Suggestion: a CVE number should be requested (if appropri= ate) as soon
as the CVSS score (i.e. the nature of the vulner= ability) has been
calculated, and it has been determined whet= her platforms in practice
(both physical and virtual) are aff= ected.

This is important because vendors shoul= d have a common (cross-vendor)
reference for tracking the iss= ue even in their own internal systems, and
this reference sho= uld be available to all vendors internally as soon as
upstrea= m determines the issue has security impact.

Ad= ditionally, as soon as members begin collaborating on actual patches,
the patches should carry the CVE number in the subject line(s).

No strong opinion. I= f no objection, let's do as you suggested.


- Request for clarificatio= n: the Embargo diagram should clarify that
vendors are *forbi= dden* from shipping fixes in their own products,
regardless o= f format, until the embargo is lifted. The point of an
embarg= o 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 pat= ch". That's the interval
when vendors would release their fix= es all together.

It's *not* OK, for any vendor= , to ship their own fixes before "3.5
Announce Embargo End".<= br class=3D"">
Yes, this means that some vendors will have to= wait on other vendors,
and some vendors will have to work mo= re hastily than they are used to,
for the sake of other vendo= rs. This is what coordinated/responsible
disclosure means, an= d it aims to benefit the cumulative user base.
<= br class=3D"">I think it's impractical to ask all vendors to release the fi= xes 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 R= ed Hat is invited to discuss a security issue in one of the edk2
modules that affects OVMF. Red Hat participates in the analysis, pat= ch
review, maybe Red Hat even contributes one or two of the p= atches. (We
could even report a security issue in the first p= lace; 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 dat= e,
before informing the grand public, and posting the upstrea= m patches to
edk2-devel.

However= , assume that every vendor is permitted to ship the fixes
whe= never 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 wit= h issue description / commit
messages, in just two weeks afte= r the patches are considered
functionally appropriate, by the= infosec group.

All the while physical platfor= m vendors might need half a year or more.

Woul= d 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*
dela= yed product features at least twice, waiting for physical firmware
vendors, under security issues that we have reported.
=
The longer a security i= ssue exists in a product, the more damage
may be caused poten= tially.

No doubt.
<= br class=3D"">This is why setting embargo dates is a trade-off. Any given v= endor wants
to get the fix as quickly as possible to its own = users, obviously. At
the same time, they should not screw ove= r the users of *other* vendors
(e.g. users of their competito= rs) -- so that next time, they can
reasonably expect the othe= r vendors to wait for them, in exchange.

All v= endors 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 rel= ease date.

I don't think any vendor want to risk that. But
it's reason= able and feasible to ask vendors not to expose the issue details
in the embargo period.

I d= isagree.

What you describe implies shipping th= e 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 b= oth binary and source form.

So my understanding is that embargo is for preparing = the security issue
information disclosure purpose, during whi= ch all vendors should integrate
the mitigation solution into = their products.

Integrate into th= eir 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 e= nd the
embargo immediately. This step is missing in the work = flow chart.

Agreed!

Thanks,
Laszlo

<= blockquote type=3D"cite" class=3D"">Vincent, please correct me if anything = wrong here.

Regards,
Jian

Thanks
Laszlo









--Boundary_(ID_kKRsiNkJrjAPWrM6/kh+oQ)--