Activity log for bug #1380669
| Date | Who | What changed | Old value | New value | Message |
|---|---|---|---|---|---|
| 2014-10-13 15:12:21 | Mark McClain | bug | added bug | ||
| 2014-10-13 15:32:00 | Mark McClain | description | R | 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. | |
| 2014-10-13 15:34:03 | Mark McClain | description | 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. | 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 | |
| 2014-10-13 15:37:50 | Thierry Carrez | bug task added | ossa | ||
| 2014-10-16 09:37:09 | Thierry Carrez | nominated for series | neutron/icehouse | ||
| 2014-10-16 09:37:09 | Thierry Carrez | bug task added | neutron/icehouse | ||
| 2014-10-16 09:37:18 | Thierry Carrez | neutron: milestone | 2014.2 | ||
| 2014-10-16 09:37:23 | Thierry Carrez | neutron: status | In Progress | Fix Released | |
| 2014-10-16 09:37:28 | Thierry Carrez | neutron/icehouse: importance | Undecided | Critical | |
| 2014-10-16 09:37:33 | Thierry Carrez | ossa: status | New | Confirmed | |
| 2014-10-16 09:37:37 | Thierry Carrez | ossa: importance | Undecided | High | |
| 2014-11-24 15:26:46 | Thierry Carrez | ossa: status | Confirmed | Incomplete | |
| 2014-11-24 15:27:09 | Thierry Carrez | ossa: importance | High | Undecided | |
| 2015-02-06 00:22:00 | Jeremy Stanley | information type | Private Security | Public | |
| 2015-02-06 00:22:07 | Jeremy Stanley | ossa: status | Incomplete | Won't Fix |
