[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen Security Advisory 82 (CVE-2013-6885) - Guest triggerable AMD CPU erratum may cause host hang
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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |