2014-09-05 11:30:22 |
Bertrand Lallau |
bug |
|
|
added bug |
2014-09-05 12:32:09 |
Bertrand Lallau |
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-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> there is no restriction on the protocol port, like we could expect it !!!
There is 2 solutions to handle this issue:
1) Doesn't allow a user to create a rule specifing protocol "any" AND a destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEP
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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 linving in the Openstack cloud... That's why I tagged it as "security vulnerability"
Regards, |
Icehouse 2014.1.2, FWaas using iptables driver
In order to allow DNS (TCP and UDP) request, the following rule was defined:
neutron firewall-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> there is no restriction on the protocol port, like we could expect it !!!
There is 2 solutions to handle this issue:
1) Doesn't allow a user to create a rule specifing protocol "any" AND a destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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 linving in the Openstack cloud... That's why I tagged it as "security vulnerability"
Regards, |
|
2014-09-05 14:07:46 |
Jeremy Stanley |
bug |
|
|
added subscriber Neutron Core Security reviewers |
2014-09-05 14:08:05 |
Jeremy Stanley |
bug task added |
|
ossa |
|
2014-09-05 14:08:16 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
2014-09-05 14:39:31 |
Bertrand Lallau |
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-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> there is no restriction on the protocol port, like we could expect it !!!
There is 2 solutions to handle this issue:
1) Doesn't allow a user to create a rule specifing protocol "any" AND a destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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 linving in the Openstack cloud... That's why I tagged it as "security vulnerability"
Regards, |
Icehouse 2014.1.2, FWaas using iptables driver
In order to allow DNS (TCP and UDP) request, the following rule was defined:
neutron firewall-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> there is no restriction on the protocol port, like we could expect it !!!
There is 2 solutions to handle this issue:
1) Doesn't allow a user to create a rule specifing protocol "any" AND a destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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, |
|
2014-09-05 18:10:14 |
Bertrand Lallau |
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-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> there is no restriction on the protocol port, like we could expect it !!!
There is 2 solutions to handle this issue:
1) Doesn't allow a user to create a rule specifing protocol "any" AND a destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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, |
Icehouse 2014.1.2, FWaas using iptables driver
In order to allow DNS (TCP and UDP) request, the following rule was defined:
neutron firewall-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> 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 destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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, |
|
2014-09-05 19:05:19 |
Bertrand Lallau |
information type |
Private Security |
Public Security |
|
2014-09-05 19:07:03 |
Bertrand Lallau |
neutron: assignee |
|
Bertrand Lallau (bertrand-lallau) |
|
2014-09-06 12:21:44 |
Cedric Brandily |
neutron: status |
New |
Confirmed |
|
2014-09-06 12:21:57 |
Cedric Brandily |
bug |
|
|
added subscriber Cedric Brandily |
2014-09-08 12:43:45 |
Bertrand Lallau |
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 |
|
2014-09-08 12:44:35 |
Bertrand Lallau |
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-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> 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 destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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, |
Icehouse 2014.1.2, FWaas using iptables driver
In order to allow DNS (TCP and UDP) request, the following rule was defined:
neutron firewall-rule-create --protocol any --destination-port 53 --action allow
On L3agent namespace this has been translated in the following iptables rules:
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -j ACCEPT
=> 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-port/destination-port.
2) Generating the following rules (like some firewalls do):
-A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT
-A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT
=> TCP and UDP have been completed.
The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268)
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, |
|
2014-09-08 12:44:47 |
Bertrand Lallau |
neutron: status |
Confirmed |
In Progress |
|
2014-09-11 13:54:15 |
Bertrand Lallau |
tags |
|
icehouse-backport-potential |
|
2014-09-12 13:27:51 |
Kyle Mestery |
neutron: milestone |
|
juno-rc1 |
|
2014-09-12 13:27:55 |
Kyle Mestery |
neutron: importance |
Undecided |
High |
|
2014-09-13 10:44:49 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Committed |
|
2014-09-15 14:43:12 |
Thierry Carrez |
ossa: status |
Incomplete |
Won't Fix |
|
2014-09-15 14:43:26 |
Thierry Carrez |
bug task added |
|
ossn |
|
2014-09-17 09:53:54 |
Tim Kelsey |
ossn: assignee |
|
Tim Kelsey (tim-kelsey) |
|
2014-09-17 11:24:57 |
Tim Kelsey |
ossn: status |
New |
In Progress |
|
2014-09-24 16:59:34 |
Nathan Kinder |
ossn: status |
In Progress |
Fix Released |
|
2014-09-25 00:19:26 |
OpenStack Infra |
tags |
icehouse-backport-potential |
icehouse-backport-potential in-stable-icehouse |
|
2014-09-29 19:50:50 |
Adam Gandelman |
nominated for series |
|
neutron/icehouse |
|
2014-09-29 19:50:51 |
Adam Gandelman |
bug task added |
|
neutron/icehouse |
|
2014-09-29 19:55:29 |
Adam Gandelman |
neutron/icehouse: importance |
Undecided |
High |
|
2014-09-29 19:55:29 |
Adam Gandelman |
neutron/icehouse: status |
New |
Fix Committed |
|
2014-09-29 19:55:29 |
Adam Gandelman |
neutron/icehouse: milestone |
|
2014.1.3 |
|
2014-09-30 14:59:43 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto MURATA |
2014-10-01 20:56:01 |
Adam Gandelman |
neutron/icehouse: assignee |
|
Bertrand Lallau (bertrand-lallau) |
|
2014-10-02 23:44:45 |
Adam Gandelman |
neutron/icehouse: status |
Fix Committed |
Fix Released |
|
2014-10-03 06:54:22 |
Thierry Carrez |
neutron: status |
Fix Committed |
Fix Released |
|
2014-10-16 09:21:57 |
Thierry Carrez |
neutron: milestone |
juno-rc1 |
2014.2 |
|