Dangerous iptables rule generated in case of protocol "any" and source-port/destination-port usage
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned | ||
OpenStack Security Notes |
Fix Released
|
Undecided
|
Tim Kelsey | ||
neutron |
Fix Released
|
High
|
Bertrand Lallau | ||
Icehouse |
Fix Released
|
High
|
Bertrand Lallau |
Bug Description
Icehouse 2014.1.2, FWaas using iptables driver
In order to allow DNS (TCP and UDP) request, the following rule was defined:
neutron firewall-
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-
-A neutron-
=> there is no restriction on the destination port(53), like we could expect it !!!
There is 2 solutions to handle this issue:
1) Doesn't allow user to create a rule specifing protocol "any" AND a source-
2) Generating the following rules (like some firewalls do):
-A neutron-
-A neutron-
-A neutron-
-A neutron-
=> TCP and UDP have been completed.
The source code affected is located in neutron/
def _port_arg(self, direction, protocol, port):
if not (protocol in ['udp', 'tcp'] and port):
return ''
return '--%s %s' % (direction, port)
=> trunk code is affected too.
Nota: This is not a real Neutron security vulnerability but it is a real security vulnerability for applications living in the Openstack cloud... That's why I tagged it as "security vulnerability"
Regards,
description: | updated |
description: | updated |
description: | updated |
information type: | Private Security → Public Security |
Changed in neutron: | |
assignee: | nobody → Bertrand Lallau (bertrand-lallau) |
Changed in neutron: | |
status: | New → Confirmed |
summary: |
- Dangerous iptables rule generated in case of protocol "any" and - destination-port usage + Dangerous iptables rule generated in case of protocol "any" and source- + port/destination-port usage |
description: | updated |
Changed in neutron: | |
status: | Confirmed → In Progress |
tags: | added: icehouse-backport-potential |
Changed in neutron: | |
milestone: | none → juno-rc1 |
importance: | Undecided → High |
Changed in ossn: | |
assignee: | nobody → Tim Kelsey (tim-kelsey) |
Changed in ossn: | |
status: | New → In Progress |
Changed in neutron: | |
status: | Fix Committed → Fix Released |
Changed in neutron: | |
milestone: | juno-rc1 → 2014.2 |
There is a possible argument that this violates the principle of least surprise, but I tend to agree that fixing it would be more a security-hardening measure and not something we would need kept under embargo.
If people have accidentally applied too-loose firewall rules through this mistake, making this bug public can only help them find out and clean it up sooner. Would-be attackers, on the other hand, are not going to find out about loose security rules on some victim's network simply due to disclosure of this bug (likely they will have already found out through arbitrary network scans). Thus, keeping this bug private under embargo would serve only to make the situation worse.