[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.