[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55113561.3060305@redhat.com>
Date: Tue, 24 Mar 2015 20:58:57 +1100
From: Garth Mollett <gmollett@...hat.com>
To: cve-assign@...re.org
CC: oss-security@...ts.openwall.com
Subject: Re: CVE request for OpenStack Compute (nova)
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@...re.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?
>
>
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
