Re: CVE request for OpenStack Compute (nova)

[Garth Mollett <gmollett () redhat com>]

I am not a member of OpenStack VMT, so this is just my opinion, but I
think the CVE should probably apply to all versions.

It's worth noting that the C1 rating mentioned in the launchpad bug is
referring to this:
https://wiki.openstack.org/wiki/Vulnerability_Management#Incident_report_taxonomy

Which is "Not considered a practical vulnerability (but some people
might assign a CVE for it)".

So it's not necessarily saying there is no vulnerability/CVE needed for
other versions. Just that it's not considered serious enough for an
OSSA, by my reading.



On 03/24/2015 06:36 PM, cve-assign () mitre org wrote:
> > https://bugs.launchpad.net/nova/+bug/1419577
>
> Use CVE-2015-2687 for this issue with an unintended loss of access
> control after a failed live migration.
>
> For purposes of CVE, we typically don't think of vulnerabilities in
> the way expressed in
> https://bugs.launchpad.net/nova/+bug/1419577/comments/4 "without a way
> to make the migration process fail, this is a bug with security
> consequence, but not a vulnerability." In other words, for a CVE, the
> attacker can be a person who wishes to have an unauthorized volume
> attachment after the bug is triggered. The attacker does not need to
> be a person who has determined a reproducible way to trigger the bug.
>
> > if live-migration is executed while process keep using big size of
> > memory by benchmark tool or something like that in VM instance and
> > then the waiting status of live-migration could be persisted,
> > eventually live-migration will be failed.
>
> We think that nobody commented on whether this is a feasible way to
> actively trigger the bug.
>
> > you're suggesting potential exploits involving
>
> > 1. disconnecting physical network interfaces
>
> We think the intended security property of this OpenStack product is:
> "if network connectivity is disrupted by anyone (authorized or not)
> during a live migration, then access control for volumes still must
> match users' expectations afterward."
>
> It is conceivable that the intended security property of this
> OpenStack product is instead "if network connectivity is disrupted
> during a live migration, then access control for volumes afterward is
> undefined." In this case, maybe you mean that the CVE should apply
> only to Havana, because the only relevant root cause is a Havana bug.
> The reasoning in that scenario would be:
>
>    1 - a Havana bug (e.g., 1362916 or possibly the combination of
>        1362916 and a second bug) makes it possible to force a failure
>        of a live migration
>
>    2 - this was not previously considered a vulnerability
>
>    3 - however, the relevant OpenStack product has a required security
>        property of "There must not be any software bugs that allow
>        live-migration failure attacks, because these attacks are
>        equivalent to attacks against volume access control."
>
>    4 - therefore, the bug in item 1 is promoted to a vulnerability,
>        and is the bug directly associated with CVE-2015-2687
>
>    5 - consequently, CVE-2015-2687 would not be used in an advisory
>        because Havana is unsupported by the OpenStack VMT
>
> So, does the OpenStack VMT have a position on whether to choose this
> latter scenario? In other words, if live migration fails because of a
> disconnected physical network interface, is access control for volumes
> intentionally undefined afterward?

Attachment: signature.asc
Description: OpenPGP digital signature