Activity log for bug #1365961

Date Who What changed Old value New value Message
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