precreated router ports can enable cross tenant plugging

[Mark McClain]

Previously we addressed the case where a tenant could attached a port to another tenant's router by knowing (or guessing) an existing router UUID [1]. The fix only prevents a tenant from attaching to existing routers, but does not defend against speculative router port creation. In systems where randomness is low, speculation of the result of uuid4() can allow a tenant to predict the ids of future routers enabling cross-tenant plugging since device_id is assumed to be trusted and queries are not scoped by tenant.

The vulnerability was closed in Juno by the work to prevent orphaned ports [2].

That fix for Icehouse cannot be back ported since it adds new models and requires a database migration. A separate fix will be proposed for Icehouse and regression tests will be proposed for Juno.

[1] https://bugs.launchpad.net/neutron/+bug/1243327
[2] https://bugs.launchpad.net/neutron/+bug/1378866

[Tristan Cacqueray (tristan-cacqueray)]

@Mark McClain So far we have not considered UUID guessing a valid attack vector as UUID is a sufficiently long and random number. Trusting UUID is an acceptable tradeoff as long as they are random.

From a vulnerability point of view, I don't think we are willing to support system with low entropy/randomness.

So the question is, what makes the described system vulnerable to UUID guessing...
  Is it OpenStack code that does not work as intended and lower system randomness ?
  Is it a third party system/drivers that does not provide enough entropy ?
  Or is it a bad configuration/faulty hardware ?

[Salvatore Orlando (salvatore-orlando)]

I think we should be waiting for Mark's comment here; I too tend to think no production system should match the low randomness criteria that would make uuid predictions possible to some extent. On the other hand this has happened in the past, and so it would be a good thing to defend against it.

The issue now exist only for stable/icehouse, and I am ok to move this issue to public security if Mark and the OSSA team agree.

[Mark McClain (markmcclain)]

@Tristan - Right predicting UUIDs is not easy, but real issue is that we're blindly trusting the weak association in the database without validating common tenant ownership.

I'll package up a fix for Icehouse and post it here shortly and then we can consider whether we should fix in the open or not.

[Jeremy Stanley (fungi)]

I'd still be curious to see any sort of proof-of-concept walkthrough for how an attacker would leverage this to some nefarious end. I don't question whether it needs prompt fixing, but if it's not directly exploitable then we shouldn't burn additional effort on embargoed security advisory processes.

[Salvatore Orlando (salvatore-orlando)]

An attacker would start creating port whose device_id value is any uuid (say "XXX") and use them as a 'bait' and deive_owner is set to network:router_interface

The attack will then be successful if eventually a router with uuid "XXX" is created. In that case the l3 agent will process the attacker's port as a valid interface for that router thus potentially giving the attacker connectivity to all the other networks attached to that router.

The chances of this happening are anyway very low, because the attacker to be successful should create a consistent number of ports, and this is very likely to be impossible because of quota limitations. (now you can argue that actually an attacker can use stolen credit cards to buy enough capacity, and I would agree with you).

For this reason let's consider a scenario in which in a rather busy cloud 10,000 routers per day are created (that is less than 1 every 10 seconds ).
Using the birthday's paradox to determine the number of days needed to get a 1% probability of guessing a UUID with a single port we get:

0.01 = 1 - e^(-(n^2/2^122))
e^-((n^2/2^122)) = 0.99
-n^2 = log(0.99) * 2^122

n = sqrt(-ln(0.99)) * 2^61

n = 2.31163905344368E17

This number is quite large... to achieve a 1% probability over a year one would need to create 633,325,768,066,763 ports

Summarizing I think we might want a backportable fix but probably this not enough of a critical vulnerability to grant an embargo

[Salvatore Orlando (salvatore-orlando)]

I hope I did get the math right in the previous comment ;)

[Thierry Carrez (ttx)]

If the math is right (and it feels consistent with my gut feeling) then you would fill the DB way before you would hit a collision.

[Salvatore Orlando (salvatore-orlando)]

the aspect that my analysis did not consider is that we're trusting the UUID generation process to be completely random.
If it is not, then an attacker might do an "informed guess" and increase his/her chances of guessing a UUID.

Still, this wont' grant enough criticality for an embargo IMHO.

[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.

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.