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

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

             Xen Security Advisory CVE-2013-6885 / XSA-82
                              version 3

          Guest triggerable AMD CPU erratum may cause host hang

UPDATES IN VERSION 3
===================
Early public release.

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.

Under the circumstances, and in accordance with the Xen Project
security vulnerability policy, it has been decided that it is no
longer appropriate to retain the embargo, as the key facts are now in
the open.

ISSUE DESCRIPTION
================
AMD CPU erratum 793 "Specific Combination of Writes to Write Combined
Memory Types and Locked Instructions May Cause Core Hang" describes a
situation under which a CPU core may hang.

IMPACT
=====
A malicious guest administrator can mount a denial of service attack
affecting the whole system.

VULNERABLE SYSTEMS
=================
The vulnerability is applicable only to family 16h model 00h-0fh AMD
CPUs.

Such CPUs running Xen versions 3.3 onwards are vulnerable.  We have
not checked earlier versions of Xen.

HVM guests can always exploit the vulnerability if it is present.
PV guests can exploit the vulnerability only if they have been granted
access to physical device(s).

Non-AMD CPUs are not vulnerable.

CREDITS
======
This issue''s security impact was discovered by Jan Beulich.

MITIGATION
=========
This issue can be avoided by neither running HVM guests, nor assigning
PCI devices to PV guests.

RESOLUTION
=========
The attached patch contains a software workaround which resolves this
issue.

Alternatively, the recommended workaround can be implemented in
firmware, so a suitable firmware update will resolve the issue.
If you require a firmware update please consult your vendor.

xsa82.patch             Xen 4.1.x, Xen 4.2.x, Xen 4.3.x, xen-unstable

$ sha256sum xsa82*.patch
0a58f3564ca91fd2668c202446c607fdb1ec8643e558a3921046d43675f58c08  xsa82.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJSnL+JAAoJEIP+FMlX6CvZw6gIAKqUkevFcn14iRT7g6iiTjbw
Fq9oiu/RtSmPDS/8FkAW6vdhYTe5cA6wCxUbErp/oZ6IwtlAmbZUQ2oVrfw8Tep/
G1hpLDkGLeRD4sqPB3Yj/RS8MUWlZhX3H9FwJLzhDqFaGiVAOHe3zl/OgwMFEnUx
PYSxdgPeiU3gavpJcDd5JamID+wLkihXMOHFKtdziOZsEAuv2lhIBSCamOVc638m
vRMtE4LbcUCv80EvvMxtrUDkt+M+TS2JfQK+09mr5/hFkyicoeEawYLgeWUbuNhj
CWbcKdyat6GauvhL46NE/aWlbUqSXHc8jcIdCDM2pRK1NR86qJiMC5av5EcPjOo=V/Az
-----END PGP SIGNATURE-----


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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.

-----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-----

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

-----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-----

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