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.

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