Date: Mon, 02 Dec 2013 11:16:44 -0700 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com, xen-devel@...ts.xen.org CC: "Xen.org security team" <security@....org> Subject: Re: 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-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.