Deallocation of fixed IP occurs before security group refresh – leading to potential security issue in error / race conditions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
David McNally | ||
Essex |
Fix Released
|
Medium
|
Unassigned | ||
nova (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
In network/
Moving the db call to after the call to trigger the security group refresh would avoid the issue when an error occurs (the fixed_ip should not be released in this case).
Slowness in updating security group rules is much harder to deal with without changing the calls to refresh rules into an rpc.call() – which would have performance impact. In the case where force_dhcp_release in not set then there is a reasonable delay before the address is reused. Maybe a mechanism is required for a generally less aggressive way of recycling fixed_IPs – for example selecting the address with the oldest updated_at timestamp rather than just picking the first free address in the table.
Related branches
- Chuck Short: Pending requested
-
Diff: 56 lines (+14/-4)3 files modifieddebian/changelog (+8/-0)
debian/control (+6/-3)
debian/nova-console.install (+0/-1)
tags: | added: network security-groups |
Changed in nova: | |
assignee: | nobody → David McNally (dave-mcnally) |
Changed in nova: | |
milestone: | none → folsom-3 |
status: | Fix Committed → Fix Released |
Changed in nova (Ubuntu): | |
status: | New → Fix Released |
Changed in nova (Ubuntu Precise): | |
status: | New → Confirmed |
Changed in nova: | |
milestone: | folsom-3 → 2012.2 |
This does appear to have some security implication. I would consider it a "Low" severity security vulnerability, since I'm not sure there is a way to do a targeted exploit with this. Even if it was exploited, it's a very small window of time if anything.