special routers ports' ownership can be edited

[Armando Migliaccio]

This is basically a sister bug of bug #1243327, but applies to DVR and, possibly, HA routers. This affects plugins that support DVR/HA, which right now is just ML2/OVS.

In a nutshell what happens is that check _enforce_device_owner_not_router_intf_or_device_id in [1] is skipped, instead of being forbidden.

From a data plane standpoint, since these routers work a bit differently from centralized routers, there is no actual cross plugging. In fact, since DVR routers will do the interface plugging only after a network has been attached to the router, this makes the exploit a lot more difficult to achieve, but the fix provided at least prevents malicious attempts from creative people.

[1] https://github.com/openstack/neutron/blob/stable/juno/neutron/db/db_base_plugin_v2.py#L1493 (stable/juno)

Patch applies for master attached, which applies cleanly to Juno.

[Tristan Cacqueray (tristan-cacqueray)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Salvatore Orlando (salvatore-orlando)]

This is not a sister of bug #1243327

It is exactly the same bug. DVR and HA routers added new types of router interfaces for which an ownership check should be explicitly requested. I would then confirm the vulnerability.

[Salvatore Orlando (salvatore-orlando)]

Whether we should embargo or not this bug depends, as often, on whether we consider a valid attack scenario the fact that an attacker can obtain (or guess) another tenant's UUID. While the latter is not practical, the former seem to be a valid scenario.

[Jeremy Stanley (fungi)]

For tracking purposes I think we have to consider this not _actually_ the same bug (as in it's not a duplicate bug report), and so worthy of a separate CVE/advisory.

However the earlier advisory's impact description does not mention UUID guessing as necessary for exploitation, and we've generally not considered that realistic unless the UUIDs are generated in a guessable order or are otherwise leaked beyond the controlling tenant.

[Armando Migliaccio (armando-migliaccio)]

The reason why I said that this bug is a sister of bug #1243327, rather than a 'regression' or duplication is because the potential attack surface is a lot different. The L3 agents for the DVR (and HA) routers are drastically different, and therefore the same failure mode couldn't be observed (i.e. the cross-plugging), at least during my initial analysis.

[Jeremy Stanley (fungi)]

For past bug reports, we've not knowingly issued advisories when guessing another tenant's resource UUID is a required component of the exploit. On the other hand, a bug which leaks information about such UUIDs or otherwise makes them easier for an attacker to guess would require an advisory.

It sounds like this bug does not actually make it easier for an attacker to guess/obtain a relevant UUID for exploiting the missing enforcement. Unless anyone disagrees or has new details to provide about this issue, I propose we treat it as class C1 https://wiki.openstack.org/wiki/Vulnerability_Management#Incident_report_taxonomy and switch the report to public on Thursday, January 29.

[Jeremy Stanley (fungi)]

Armando, before I switch this to public I just want to clarify your comment #4 above... were you implying this bug makes enumerating or obtaining other tenants' resource UUIDs easier? If so, I'm having trouble seeing it, but am holding off making it public until I get clarification on that point. Thanks!

[Jeremy Stanley (fungi)]

Oh, I guess that was Salvatore's comment. Anyway, caught up with Armando in IRC and it sounds like even if the attacker _does_ guess another tenant's resource UUID (which this bug doesn't enable or simplify in any way), there was still no clear indication that it would allow a data plane breach.

Given that I'm switching this to a regular bug now.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/153452

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/153452
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=89025a8dd93918ac2967726ec7bb8ee5aa22d924
Submitter: Jenkins
Branch: master

commit 89025a8dd93918ac2967726ec7bb8ee5aa22d924
Author: armando-migliaccio <email address hidden>
Date: Thu Feb 5 16:27:52 2015 -0800

    Fix lack of device ownership enforcement for DVR routers

    The enforcement rule was applied to centralized router interfaces, to avoid
    a potential security vulnerabilty.

    Even though DVR routers are fundamentally different from centralized routers,
    there is no good reason as to why the rule should be skipped for DVR interfaces.

    This patch sanitizes the insanity a bit and closes this potential loophole by
    preventing the operation for DVR routers too.

    Related-bug: #1243327
    Closes-bug: #1410984

    Change-Id: I048e6e3926e1c74cf9ecb63cfb53a0b1afb3c579

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/154355

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/154355