Re: Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang

Re: Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang

[Ian Jackson]

Xen.org security team writes ("Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang"):
> This issue was predisclosed under embargo by the Xen Project Security
> team, on the 27th of November.  We treated the issue as not publicly
> known because it was not evident from the public sources that this
> erratum constitutes a vulnerability (particularly, that it was a
> vulnerability in relation to some Xen configurations).
> 
> Since then, the fact that this CPU erratum is likely to constitute a
> security problem has been publicly disclosed, on the oss-security
> mailing list.

This is a reference to this message:
  http://www.openwall.com/lists/oss-security/2013/11/28/1

This was sent by MITRE as part of the CVE assignment.  It seems likely
to us (the Xen Project security team) that the CVE assignment was a
consequence of our embargoed predisclosure to xen-security-issues.

The effect of this has been that we have had to end the embargo early.
I think there is room for discussion here about whether we all did the
right thing.  In particular:

 * Should the Xen Project security te4am have treated this issue with
   an embargo at all, given that the flaw itself was public ?

 * Should we have anticipated that other software would be in a
   similar position and sent message(s) to some other suitable set of
   vendor(s) ?  Which vendors, and how ?

 * Should MITRE have been asked /not/ to publicly disclose the
   relationship between CVE-2013-6885 and AMD CPU erratum 793,
   until the embargo ended ?

 * Were we right to treat MITRE's message as a trigger for disclosure ?

Thanks,
Ian.

Re: [oss-security] Re: Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang

[Kurt Seifried]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/02/2013 10:22 AM, Ian Jackson wrote:
> Xen.org security team writes ("Xen Security Advisory 82
> (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host
> hang"):
>> This issue was predisclosed under embargo by the Xen Project
>> Security team, on the 27th of November.  We treated the issue as
>> not publicly known because it was not evident from the public
>> sources that this erratum constitutes a vulnerability
>> (particularly, that it was a vulnerability in relation to some
>> Xen configurations).
>> 
>> Since then, the fact that this CPU erratum is likely to
>> constitute a security problem has been publicly disclosed, on the
>> oss-security mailing list.
> 
> This is a reference to this message: 
> http://www.openwall.com/lists/oss-security/2013/11/28/1
> 
> This was sent by MITRE as part of the CVE assignment.  It seems
> likely to us (the Xen Project security team) that the CVE
> assignment was a consequence of our embargoed predisclosure to
> xen-security-issues.
> 
> The effect of this has been that we have had to end the embargo
> early. I think there is room for discussion here about whether we
> all did the right thing.  In particular:
> 
> * Should the Xen Project security te4am have treated this issue
> with an embargo at all, given that the flaw itself was public ?

I would say this depends on the level of public disclosure. For
example from "upstream" (AMD) there was a very limited disclosure (no
public announcement I'm aware of) and just some notes in a single PDF.
However this was also made public via the person who found it and then
picked up by ZDnet in an article, so I would personally count that as
quite public.

> * Should we have anticipated that other software would be in a 
> similar position and sent message(s) to some other suitable set of 
> vendor(s) ?  Which vendors, and how ?

Yes and no, with hardware obviously it's likely that other software
will leave the bug exposed, the problem is finding all of it and
notifying people is a very non trivial task.

> * Should MITRE have been asked /not/ to publicly disclose the 
> relationship between CVE-2013-6885 and AMD CPU erratum 793, until
> the embargo ended ?

That was my fault, I didn't think to ask them to handle this as a
private assignment since the issue was quite public/old (see above).

> * Were we right to treat MITRE's message as a trigger for
> disclosure ?

Don't know.

> Thanks, Ian.


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJSnM6LAAoJEBYNRVNeJnmTX+kQANqW6JvY/c9IYcuVel8DD5+S
5351tgVQkKfqVRqFT3R+azlTlk/Y2Kg/YTaqTSJmwQ/WtT61P3d8WKH2P9eD35OM
9CCnL+xc5r60zMcEokvdxBPYvtSkhDHvy2hp2RtFmnrMbIHrSO9cs1vvu+j9L480
ZR1rtrhNt7q/+I7Cpy++iOLtpARiBHDivKdpk47gsE3s/mVlhrAbQWA6Dl1TSJs2
/ByUdsBUhwiwvhEALZrH+/ovqX52RwvCqmFPYfgLo1y+I1uk536NnV3qlcvU3gxP
O4mtSQ6jGVzAnaiBHMYY6yVrPggB/WhxnWCmIaMQ3Taz/qYIyM5sGL2iljClvjsj
WlT2Ve3KCZ7sOsiIAgZS31XST/Ey70xacs2FzzF74UUFCPbint1bEC2adlRQlMQG
jBcVi9k+lFm/XUeRh8LorRyyMGutdnOMbsu3REjHRycjhc4U0hXunQLAJZbmqChY
9lkrbkm2K6J0mrTIXZy2Y+Wl+kaWzdSMtUyU5QHHyqv3OAQbODH7Li0vxjwDT7/K
iFQb4sPwUAUAWQTuZ/qloCJRTcFzVNIF97vPpOQVlGouTSTfUvQJ7NDY+Yta5RwM
PzkJjPHDZvGVrK07jw5w1kpjj4C/RcopvZaW0dxc62N8RPE60HsTZ/rSmT2IP9yQ
qPROKaphfmISa4AwZSTp
=r3rU
-----END PGP SIGNATURE-----

Re: [oss-security] Re: Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang

[Matthew Daley]

On Tue, Dec 3, 2013 at 7:16 AM, Kurt Seifried <kseifried@redhat.com> wrote:
> On 12/02/2013 10:22 AM, Ian Jackson wrote:
>> * Should the Xen Project security te4am have treated this issue
>> with an embargo at all, given that the flaw itself was public ?
>
> I would say this depends on the level of public disclosure. For
> example from "upstream" (AMD) there was a very limited disclosure (no
> public announcement I'm aware of) and just some notes in a single PDF.
> However this was also made public via the person who found it and then
> picked up by ZDnet in an article, so I would personally count that as
> quite public.

Can you post a link to this ZDnet article? I don't think it can be the
one linked in the CVE description itself, because that talks about a
different, earlier bug IIUC; I privately asked Matt Dillon, who
discovered Errata 721, and he agreed that this CVE talks about a
different (but maybe related) Errata, #793.

- Matthew

Re: Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang

[cve-assign]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> This was sent by MITRE as part of the CVE assignment. It seems likely
> to us (the Xen Project security team) that the CVE assignment was a
> consequence of our embargoed predisclosure to xen-security-issues.

MITRE typically does not know about multi-party embargo arrangements
affecting Linux vendors and various other vendors, and did not know
about any multi-party embargo arrangement in this case. If anyone who
is regularly involved in vulnerability remediation affecting the
open-source community asks MITRE to send an announcement of a CVE
assignment to oss-security, we send that announcement without any
investigation of disclosure restrictions. Although it is unfortunate
if such an announcement had an adverse effect on a planned disclosure
timeline, we feel that this is an isolated case and does not mean that
we need to reevaluate our approach. Also, once an issue is mentioned
on oss-security by anyone, we consider the issue fully public and we
sometimes proceed to publish a CVE immediately.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJSnRcQAAoJEKllVAevmvmshl8H/0d/jkBYZP11YbWOzTXQrKGj
exCXvUaC6BOukr1+u1eh7GR1W98NY5S7DT3oHDu0DzAfJ2iR4AAM0513V9mCUo/f
LBBGsw+pyzPKeI5UQdXJ8GQ0Ut/WlbMB4qj0+ZuwKjCKFCdir2Xx7H0H3Ptb3qik
38JgvO+bpMxDWnrF+Nh6SkuocB9jXuDCbCGO5Q4jaj1CcExmaRV9H8A0O4VbvtTj
VQa+eY48H7WpBqKUrKylo/zZT5pBs/3tH0FSymiGLP9aFCDAl5xazf9LWq3iow/D
AND3rDNlEzmDJ8zSHzx0wrvHTW8xMpj3KAk3z4D8G8XTmw7reltAVo1eGPmL6S0=
=ouMl
-----END PGP SIGNATURE-----

Re: [oss-security] Re: Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang

[Andrew Cooper]

On 02/12/2013 22:43, Matthew Daley wrote:
> On Tue, Dec 3, 2013 at 7:16 AM, Kurt Seifried <kseifried@redhat.com> wrote:
>> On 12/02/2013 10:22 AM, Ian Jackson wrote:
>>> * Should the Xen Project security te4am have treated this issue
>>> with an embargo at all, given that the flaw itself was public ?
>> I would say this depends on the level of public disclosure. For
>> example from "upstream" (AMD) there was a very limited disclosure (no
>> public announcement I'm aware of) and just some notes in a single PDF.
>> However this was also made public via the person who found it and then
>> picked up by ZDnet in an article, so I would personally count that as
>> quite public.
> Can you post a link to this ZDnet article? I don't think it can be the
> one linked in the CVE description itself, because that talks about a
> different, earlier bug IIUC; I privately asked Matt Dillon, who
> discovered Errata 721, and he agreed that this CVE talks about a
> different (but maybe related) Errata, #793.
>
> - Matthew

The email (ID 201311280223.rAS2NbPL019021@linus.mitre.org) has the
following links

http://lists.dragonflybsd.org/pipermail/kernel/2011-December/046594.html

http://www.zdnet.com/blog/hardware/amd-owns-up-to-cpu-bug/18924

And identifies them as related to CVE-2013-6885

Unless DragonflyBSD is giving Write Combining memory to its regular
userspace processes (which would frankly be crazy and cause abysmal
performance - uncacheable reads have a habit of slowing things down
somewhat), I cant see any similarity between the CVE and the problem
described by Matt Dillon in the links.

The zdnet article quotes a statement from AMD of:

Also, this marginal erratum impacts the previous four generations of AMD
Opteron processors which include the AMD Opteron 2300,8300
8300("Barcelona" and "Shanghai",) 2400, 8400 ("Istanbul",) and 4100,
6100 ("Lisbon" and "Magny-Cours") series processors.


None of these generations are the "Jaguar Architecture" Family 16h
identified in the erratum description from #793  Furthermore, Matt
Dillon appears to be under the impression that he found erratum #721.

It therefore appears that the original MITRE email was incorrect as
identifying the two links (refering to #721, and nearly 2 years old
judging by http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/14518)
as related to #793 (whos errata document's inital release was June of
this year).

Can anyone from AMD formally confirm or deny a link between errata #721
and #793 ?

~Andrew