[OSSA 2013-030] xenapi: secgroups are not in place after live-migration (CVE-2013-4497)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
John Garbutt | ||
Grizzly |
Fix Released
|
High
|
John Garbutt | ||
OpenStack Security Advisory |
Fix Released
|
High
|
Jeremy Stanley |
Bug Description
Distributed Setup with:
2x Compute nodes with Debian Wheezy + XCP installed from repositories (Kronos). The VM controlling XCP is installed on Ubuntu Precise.
1x Controller node with Keystone and Nova (except Network and Compute) on Ubuntu Precise with OpenStack Grizzly installed from cloud archive.
1x Network node running Nova network with FlatDHCP (no quantum is used because it is not supported for XCP yet - I think it will starting with Havana release). The network node has 3 interfaces. 1x Public, 1x Management, 1x Tenant.
1x Storage node running Cinder, Glance and NFSv3 for shared storage to support live migration
I experiment with XCP and live migration these days so after I configured everything else, I tried to configure floating IP addresses as well. The configuration of the floating IP's was trivial but when I booted a VM, I instantly migrated it (that's what I am mostly testing) and then assigned a floating IP. Then I tried to ping it and connect to it using ssh and everything worked fine.
I boot a second VM and this time I do not migrate it. I assign a floating IP address and no ping or ssh connection is possible to be made on this one even though the iptables have been setup correctly (the SNAT and DNAT). I migrate the VM and then I can connect to it using SSH without any problems.
In the beginning I thought it is a bug and for some reason when you boot even though you should be able to connect, you cannot. After looking in the documentation I found this: http://
What I understood from this is that it is the other way around and I should NOT be able to ping or connect to the VMs using SSH by default if I don't explicitly add the secgroup rules to allow such actions.
After adding these two rules everything works fine (I can access any vm, migrated or non-migrated):
$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
$ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
After removing them again, I cannot access the non-migrated VM's (correct) but I can still access those that they were migrated once.
Even when I migrate them back to the hypervisor originally booted on, the secgroups still do not apply and I can access those VM's.
CVE References
tags: | added: xenserver |
Changed in nova: | |
importance: | Undecided → High |
status: | New → Confirmed |
summary: |
- Secgroups are not in place after migration! + xenapi: secgroups are not in place after live-migration |
Changed in nova: | |
milestone: | none → havana-rc1 |
Changed in ossa: | |
assignee: | nobody → Jeremy Stanley (fungi) |
Changed in nova: | |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | havana-rc1 → 2013.2 |
Changed in ossa: | |
status: | Confirmed → Triaged |
Changed in ossa: | |
status: | Triaged → In Progress |
summary: |
- xenapi: secgroups are not in place after live-migration + xenapi: secgroups are not in place after live-migration (CVE-2013-4497) |
no longer affects: | nova/folsom |
Changed in ossa: | |
status: | In Progress → Fix Committed |
tags: | removed: folsom-backport-potential grizzly-backport-potential |
Adding Nova PTL for sanity check