[RFC 0/1] security-process: update with mailing list details

[RFC 0/1] security-process: update with mailing list details

[P J P]

From: Prasad J Pandit <pjp@fedoraproject.org>

Hello,

* After upstream discussions and considering various options like
  LaunchPad bugs, GitLab issues etc.

  -> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg04266.html
  -> https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg00059.html

  We are about to introduce a 'qemu-security' mailing list to receive and
  triage upstream QEMU security issues.

* Intention is to allow more community participation in handling and
  triaging of the QEMU security issues.

* This change relieves current set of individual contacts from the
  responsibility of handling upstream QEMU issues. Of course they are
  welcome to the new 'qemu-security' mailing list.

* To simplify the encrypted communication process, we keep only a single
  contact of <secalert@redhat.com> from our previous list of contacts.

  This way reporters need not look for and manage GPG keys of multiple
  contacts.

* This patch updates the QEMU security-process web page with these
  details.

I'd appreciate if you have any inputs and/or suggestions for this change.

Thank you.
--
Prasad J Pandit (1):
  security-process: update process information

 contribute/security-process.md | 105 +++++++++++++++++----------------
 1 file changed, 55 insertions(+), 50 deletions(-)

--
2.28.0

[RFC 1/1] security-process: update process information

[P J P]

From: Prasad J Pandit <pjp@fedoraproject.org>

We are about to introduce a qemu-security mailing list to report
and triage QEMU security issues.

Update the QEMU security process web page with new mailing list
and triage details.

Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
---
 contribute/security-process.md | 105 +++++++++++++++++----------------
 1 file changed, 55 insertions(+), 50 deletions(-)

diff --git a/contribute/security-process.md b/contribute/security-process.md
index 1239967..a03092c 100644
--- a/contribute/security-process.md
+++ b/contribute/security-process.md
@@ -3,43 +3,54 @@ title: Security Process
 permalink: /contribute/security-process/
 ---
 
-QEMU takes security very seriously, and we aim to take immediate action to
-address serious security-related problems that involve our product.
-
-Please report any suspected security vulnerability in QEMU to the following
-addresses. You can use GPG keys for respective receipients to communicate with
-us securely. If you do, please upload your GPG public key or supply it to us
-in some other way, so that we can communicate to you in a secure way, too!
-Please include the tag **\[QEMU-SECURITY\]** on the subject line to help us
-identify your message as security-related. 
-
-## QEMU Security Contact List
-
-Please copy everyone on this list:
-
- Contact Person(s)	| Contact Address		| Company	|  GPG Key  | GPG key fingerprint
-:-----------------------|:------------------------------|:--------------|:---------:|:--------------------
- Michael S. Tsirkin	| mst@redhat.com		| Red Hat Inc.	| [&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0xC3503912AFBE8E67) | 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
- Petr Matousek		| pmatouse@redhat.com		| Red Hat Inc.	| [&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3E786F42C44977CA) | 8107 AF16 A416 F9AF 18F3 D874 3E78 6F42 C449 77CA
- Stefano Stabellini	| sstabellini@kernel.org 	| Independent	| [&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x894F8F4870E1AE90) | D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90
- Security Response Team | secalert@redhat.com		| Red Hat Inc.	| [&#x1f511;](https://access.redhat.com/site/security/team/contact/#contact) |
- Michael Roth		| michael.roth@amd.com	| AMD		| [&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3353C9CEF108B584) | CEAC C9E1 5534 EBAB B82D 3FA0 3353 C9CE F108 B584
- Prasad J Pandit 	| pjp@redhat.com		| Red Hat Inc.	| [&#x1f511;](http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=0xE2858B5AF050DE8D) | 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D 
-
-## How to Contact Us Securely
-
-We use GNU Privacy Guard (GnuPG or GPG) keys to secure communications. Mail
-sent to members of the list can be encrypted with public keys of all members
-of the list. We expect to change some of the keys we use from time to time.
-Should a key change, the previous one will be revoked.
-
-## How we respond
-
-Maintainers listed on the security reporting list operate a policy of
-responsible disclosure. As such they agree that any information you share with
-them about security issues that are not public knowledge is kept confidential
-within respective affiliated companies. It is not passed on to any third-party,
-including Xen Security Project, without your permission.
+Please report any suspected security issue in QEMU to the security mailing
+list at:
+
+* <qemu-security@nongnu.org>
+
+To report an issue securely via GPG encrypted email, please send it to the
+Red Hat Product Security team at:
+
+* <secalert@redhat.com>  [GPG key](https://access.redhat.com/security/team/contact/#contact)
+
+Note: after the triage, encrypted issue details shall be sent to the upstream
+'qemu-security' list for archival purposes.
+
+## How to report an issue:
+
+* Please include as many details as possible in the issue report.
+  Ex:
+    - QEMU version, upstream commit/tag
+    - Host & Guest architecture x86/Arm64/PPC, 32/64 bit etc.
+    - Affected code area/snippets
+    - Stack traces, crash details
+    - Malicious inputs/reproducer steps etc.
+    - Any configurations/settings required to trigger the issue.
+
+* Please share the QEMU command line used to invoke the guest VM.
+
+* Please specify whom to acknowledge for reporting this issue.
+
+## How we respond:
+
+* Steps to triage:
+    - Examine and validate the issue details to confirm whether the
+      issue is genuine and can be misused for malicious purposes.
+    - Determine its worst case impact and severity(Low/M/I/Critical)
+    - Negotiate embargo timeline (if required)
+    - Request a CVE and open an upstream bug
+    - Create an upstream fix patch
+
+* Above security lists are operated by select analysts, maintainers and/or
+  representatives from downstream communities.
+
+* List members follow a **responsible disclosure** policy. Any non-public
+  information you share about security issues, is kept confidential within the
+  respective affiliated companies. Such information shall not be passed on to
+  any third parties, including Xen Security Project, without your prior
+  permission.
+
+* We aim to triage security issues within maximum of 60 days.
 
 Email sent to us is read and acknowledged with a non-automated response. For
 issues that are complicated and require significant attention, we will open an
@@ -51,24 +62,23 @@ of the following steps:
 If a security issue is reported that is not already publicly disclosed, an
 embargo date may be assigned and communicated to the reporter. Embargo
 periods will be negotiated by mutual agreement between members of the security
-team and other relevant parties to the problem. Members of the security contact
-list agree not to publicly disclose any details of the security issue until
+list and other relevant parties to the problem. Members of the security list
+agree not to publicly disclose any details of the security issue until
 the embargo date expires.
 
 ### CVE allocation
 
-An security issue is assigned with a CVE number. The CVE numbers will usually
-be allocated by one of the vendor security engineers on the security contact
-list.
+Each security issue is assigned a CVE number. The CVE number is usually
+allocated by one of the vendor security engineers on the security list.
 
-## When to contact the QEMU Security Contact List
+## When to contact the QEMU Security List
 
-You should contact the Security Contact List if:
+You should contact the Security List if:
 * You think there may be a security vulnerability in QEMU.
 * You are unsure about how a known vulnerability affects QEMU.
 * You can contact us in English. We are unable to respond in other languages.
 
-## When *not* to contact the QEMU Security Contact List
+## When *not* to contact the QEMU Security List
 * You need assistance in a language other than English.
 * You require technical assistance (for example, "how do I configure QEMU?").
 * You need help upgrading QEMU due to security alerts.
@@ -122,8 +132,3 @@ used to write programs for the SoC device. In such developer environments, it
 is generally assumed that the guest is trusted.
 
 And thus, this buffer overflow turned out to be a security non-issue.
-
-## What to Send to the QEMU Security Contact List
-
-Please provide as much information about your system and the issue as possible
-when contacting the list.
-- 
2.28.0

Re: [RFC 1/1] security-process: update process information

[Darren Kenny]

Hi Prasad,

Thanks for writing this up.

I have some comments below on the response steps.

On Tuesday, 2020-11-24 at 19:52:38 +0530, P J P wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> We are about to introduce a qemu-security mailing list to report
> and triage QEMU security issues.
>
> Update the QEMU security process web page with new mailing list
> and triage details.
>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
>  contribute/security-process.md | 105 +++++++++++++++++----------------
>  1 file changed, 55 insertions(+), 50 deletions(-)
>
> diff --git a/contribute/security-process.md b/contribute/security-process.md
> index 1239967..a03092c 100644
> --- a/contribute/security-process.md
> +++ b/contribute/security-process.md

...

> +## How we respond:
> +
> +* Steps to triage:
> +    - Examine and validate the issue details to confirm whether the
> +      issue is genuine and can be misused for malicious purposes.
> +    - Determine its worst case impact and severity(Low/M/I/Critical)
> +    - Negotiate embargo timeline (if required)
> +    - Request a CVE and open an upstream bug
> +    - Create an upstream fix patch
> +
> +* Above security lists are operated by select analysts, maintainers and/or
> +  representatives from downstream communities.
> +
> +* List members follow a **responsible disclosure** policy. Any non-public
> +  information you share about security issues, is kept confidential within the
> +  respective affiliated companies. Such information shall not be passed on to
> +  any third parties, including Xen Security Project, without your prior
> +  permission.
> +
> +* We aim to triage security issues within maximum of 60 days.

I always understood triage to be the initial steps in assessing a bug:

- determining if it is a security bug, in this case

- then deciding on the severity of it

I would not expect triage to include seeing it through to the point
where there is a fix as in the steps above and as such that definition
of triage should probably have a shorter time frame.

At this point, if it is not a security bug, then it should just be
logged as any other bug in Qemu, which goes on to qemu-devel then.

But, if it is a security bug - then that is when the next steps would be
taken, to (not necessarily in this order):

- negotiate an embargo (should the predefined 60 days be insufficient)

  - don't know if you need to mention that this would include downstream
    in this too, since they will be the ones most likely to need the
    time to distribute a fix

- request a CVE

- create a fix for upstream

  - distros can work on bringing that back into downstream as needed,
    within the embargo period

I do feel that it is worth separating the 2 phases of triage and beyond,
but of course that is only my thoughts on it, I'm sure others will have
theirs.

Thanks,

Darren.

Re: [RFC 1/1] security-process: update process information

[P J P]

  Hello Darren, all

+-- On Tue, 24 Nov 2020, Darren Kenny wrote --+
| I always understood triage to be the initial steps in assessing a bug:
| 
| - determining if it is a security bug, in this case
| - then deciding on the severity of it
|
| I would not expect triage to include seeing it through to the point
| where there is a fix as in the steps above and as such that definition
| of triage should probably have a shorter time frame.

* Yes, initial triage is to determine if a given issue is a security one and 
  its impact if so.

* After above step, an upstream bug (or GitLab issue) shall be filed if the
  issue can be made public readily and does not need an embargo period.

* Following step about creating a patch is needed considering the influx of 
  these issues. If such a patch is not proposed at this time, we risk having 
  numerous CVE bugs open and unfixed without a patch.

* Sometimes proposed patches take long time to get merged upstream. Hence the 
  60 days time frame.

* It does not mean issue report will remain private for 60 days, nope.


| But, if it is a security bug - then that is when the next steps would be
| taken, to (not necessarily in this order):
| 
| - negotiate an embargo (should the predefined 60 days be insufficient)
|
|   - don't know if you need to mention that this would include downstream
|     in this too, since they will be the ones most likely to need the
|     time to distribute a fix

* Embargo period is negotiated for important/critical issues. Such embargo 
  period is generally not more than 2 weeks.

* Yes, embargo process includes notifying various downstream communities about 
  the issue, its fix(es) and co-ordinating disclosure.

| - request a CVE
| - create a fix for upstream
|   - distros can work on bringing that back into downstream as needed,
|     within the embargo period
| 
| I do feel that it is worth separating the 2 phases of triage and beyond,
| but of course that is only my thoughts on it, I'm sure others will have
| theirs.

* Yes, I appreciate it, thanks so much for sharing.

* This patch is to get the qemu-security list up and running. I'll refine the 
  process further with above/more details as we start using it. Hope that's 
  okay.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [RFC 1/1] security-process: update process information

[Darren Kenny]

On Wednesday, 2020-11-25 at 18:18:56 +0530, P J P wrote:
>   Hello Darren, all
>
> +-- On Tue, 24 Nov 2020, Darren Kenny wrote --+
> | I always understood triage to be the initial steps in assessing a bug:
> | 
> | - determining if it is a security bug, in this case
> | - then deciding on the severity of it
> |
> | I would not expect triage to include seeing it through to the point
> | where there is a fix as in the steps above and as such that definition
> | of triage should probably have a shorter time frame.
>
> * Yes, initial triage is to determine if a given issue is a security one and 
>   its impact if so.

Sounds good.

>
> * After above step, an upstream bug (or GitLab issue) shall be filed if the
>   issue can be made public readily and does not need an embargo period.

OK

> * Following step about creating a patch is needed considering the influx of 
>   these issues. If such a patch is not proposed at this time, we risk having 
>   numerous CVE bugs open and unfixed without a patch.
>
> * Sometimes proposed patches take long time to get merged upstream. Hence the 
>   60 days time frame.

Absolutely understand that.

>
> * It does not mean issue report will remain private for 60 days, nope.

OK, it is not the embargo period then, got it.

>
>
> | But, if it is a security bug - then that is when the next steps would be
> | taken, to (not necessarily in this order):
> | 
> | - negotiate an embargo (should the predefined 60 days be insufficient)
> |
> |   - don't know if you need to mention that this would include downstream
> |     in this too, since they will be the ones most likely to need the
> |     time to distribute a fix
>
> * Embargo period is negotiated for important/critical issues. Such embargo 
>   period is generally not more than 2 weeks.

I always thought that the purpose of an embargo period was to enable
downstream to have patches available and ready for distribution, and
preferably distributed already if its something a malicious guest could
use. In that case 2 weeks seems like a pretty short time-frame for all
of that to be completed, especially if it is something that could be
exploitable as soon as the patch lands and is thus visible in upstream
code.

But I guess the negotiation would iron that out at the time, so it's
probably OK to default to 2 weeks.

> * Yes, embargo process includes notifying various downstream communities about 
>   the issue, its fix(es) and co-ordinating disclosure.

OK.

> | - request a CVE
> | - create a fix for upstream
> |   - distros can work on bringing that back into downstream as needed,
> |     within the embargo period
> | 
> | I do feel that it is worth separating the 2 phases of triage and beyond,
> | but of course that is only my thoughts on it, I'm sure others will have
> | theirs.
>
> * Yes, I appreciate it, thanks so much for sharing.
>
> * This patch is to get the qemu-security list up and running. I'll refine the 
>   process further with above/more details as we start using it. Hope that's 
>   okay.

OK, since it was an RFC I didn't think it was the actual patch yet, just
looking for comments ;-)

I'm alright if it gets ironed out more after...

Thanks,

Darren.

>
>
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [RFC 1/1] security-process: update process information

[Red Hat Product Security]

[-- Attachment #1.1: Type: text/plain, Size: 3578 bytes --]

Hello!

INC1531976 ([RFC 1/1] security-process: update process information) has been updated.

Opened for: Prasad Pandit
Followers: stefanha@gmail.com, peter.maydell@linaro.org, sstabellini@kernel.org, Petr Matousek, pjp@fedoraproject.org, konrad.wilk@oracle.com, michael.roth@amd.com, mst@redhat.com, qemu-devel@nongnu.org, darren.kenny@oracle.com, Daniel Berrange

A Guest updated your request with the following comments:

Reply from: darren.kenny@oracle.com
 Hi Prasad,
 Thanks for writing this up.
 I have some comments below on the response steps.
 On Tuesday, 2020-11-24 at 19:52:38 +0530, P J P wrote:
> From: Prasad J Pandit 
>
> We are about to introduce a qemu-security mailing list to report
> and triage QEMU security issues.
>
> Update the QEMU security process web page with new mailing list
> and triage details.
>
> Signed-off-by: Prasad J Pandit 
> ---
> contribute/security-process.md | 105 +++++++++++++++++----------------
> 1 file changed, 55 insertions(+), 50 deletions(-)
>
> diff --git a/contribute/security-process.md b/contribute/security-process.md
> index 1239967..a03092c 100644
> --- a/contribute/security-process.md
> +++ b/contribute/security-process.md
 ...
 > +## How we respond:
> +
> +* Steps to triage:
> + - Examine and validate the issue details to confirm whether the
> + issue is genuine and can be misused for malicious purposes.
> + - Determine its worst case impact and severity(Low/M/I/Critical)
> + - Negotiate embargo timeline (if required)
> + - Request a CVE and open an upstream bug
> + - Create an upstream fix patch
> +
> +* Above security lists are operated by select analysts, maintainers and/or
> + representatives from downstream communities.
> +
> +* List members follow a **responsible disclosure** policy. Any non-public
> + information you share about security issues, is kept confidential within the
> + respective affiliated companies. Such information shall not be passed on to
> + any third parties, including Xen Security Project, without your prior
> + permission.
> +
> +* We aim to triage security issues within maximum of 60 days.
 I always understood triage to be the initial steps in assessing a bug:
 - determining if it is a security bug, in this case
 - then deciding on the severity of it
 I would not expect triage to include seeing it through to the point
where there is a fix as in the steps above and as such that definition
of triage should probably have a shorter time frame.
 At this point, if it is not a security bug, then it should just be
logged as any other bug in Qemu, which goes on to qemu-devel then.
 But, if it is a security bug - then that is when the next steps would be
taken, to (not necessarily in this order):
 - negotiate an embargo (should the predefined 60 days be insufficient)
  - don't know if you need to mention that this would include downstream
 in this too, since they will be the ones most likely to need the
 time to distribute a fix
 - request a CVE
 - create a fix for upstream
  - distros can work on bringing that back into downstream as needed,
 within the embargo period
 I do feel that it is worth separating the 2 phases of triage and beyond,
but of course that is only my thoughts on it, I'm sure others will have
theirs.
 Thanks,
 Darren.

How can I track and update my request?

To respond, reply to this email. You may also create a new email and include the request number (INC1531976) in the subject.

Thank you,
Product Security

Ref:MSG36787539

[-- Attachment #1.2: Type: text/html, Size: 5159 bytes --]