Dangerous iptables rule generated in case of protocol "any" and source-port/destination-port usage

Bug #1365961 reported by Bertrand Lallau
266
This bug affects 2 people
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-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,

description: updated
Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Changed in ossa:
status: New → Incomplete
description: updated
Revision history for this message
Bertrand Lallau (bertrand-lallau) wrote :

@Jeremy: I tend to agree with your reasoning here.
+1 to make it public

description: updated
information type: Private Security → Public Security
Changed in neutron:
assignee: nobody → Bertrand Lallau (bertrand-lallau)
Changed in neutron:
status: New → Confirmed
Revision history for this message
Cedric Brandily (cbrandily) wrote :

the bug concerns source-port

Revision history for this message
Cedric Brandily (cbrandily) wrote :

oups

The bug concerns also rules with protocol "any" and defined source-port

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
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/120076

Revision history for this message
Thierry Carrez (ttx) wrote :

Yes, I think we can skip the "advisory" step here. This may be of interest as a security note, though.

tags: added: icehouse-backport-potential
Kyle Mestery (mestery)
Changed in neutron:
milestone: none → juno-rc1
importance: Undecided → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/120076
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=6f3ae396ed9a9525d4ca77fb8e9b2857fe79b568
Submitter: Jenkins
Branch: master

commit 6f3ae396ed9a9525d4ca77fb8e9b2857fe79b568
Author: Bertrand Lallau <email address hidden>
Date: Tue Sep 9 14:56:59 2014 +0200

    Don't allow user to set firewall rule with port and no protocol

    Creating firewall rules specifying a destination port and/or a source
    port without a protocol, generates rules without src or dest port
    restriction. This was a real security issue for cloud users.

    This patch generates a 400 Bad request "Source/destination port
    requires a protocol" in case of creation/update of firewall rules
    specifying a destination port and/or a source port and without protocol.

    DocImpact
    Closes-Bug: #1365961

    Change-Id: I4a3a1d9ae7ec4b2a864b3edc83d65ef7f80cbba5

Changed in neutron:
status: In Progress → Fix Committed
Revision history for this message
Thierry Carrez (ttx) wrote :

Adding OSSN crew, that looks like something they might want to document.

Changed in ossa:
status: Incomplete → Won't Fix
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/icehouse)

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/121839

Tim Kelsey (tim-kelsey)
Changed in ossn:
assignee: nobody → Tim Kelsey (tim-kelsey)
Tim Kelsey (tim-kelsey)
Changed in ossn:
status: New → In Progress
Revision history for this message
Nathan Kinder (nkinder) wrote :

The security note for this issue has been published as OSSN-0029:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0029

Changed in ossn:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/icehouse)

Reviewed: https://review.openstack.org/121839
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=50e15341fef87058f6e5f79299c30ac6ee38ddf0
Submitter: Jenkins
Branch: stable/icehouse

commit 50e15341fef87058f6e5f79299c30ac6ee38ddf0
Author: Bertrand Lallau <email address hidden>
Date: Tue Sep 9 14:56:59 2014 +0200

    Don't allow user to set firewall rule with port and no protocol

    Creating firewall rules specifying a destination port and/or a source
    port without a protocol, generates rules without src or dest port
    restriction. This was a real security issue for cloud users.

    This patch generates a 400 Bad request "Source/destination port
    requires a protocol" in case of creation/update of firewall rules
    specifying a destination port and/or a source port and without protocol.

    DocImpact
    Closes-Bug: #1365961

    Change-Id: I4a3a1d9ae7ec4b2a864b3edc83d65ef7f80cbba5
    (cherry picked from commit 6f3ae396ed9a9525d4ca77fb8e9b2857fe79b568)

tags: added: in-stable-icehouse
Thierry Carrez (ttx)
Changed in neutron:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in neutron:
milestone: juno-rc1 → 2014.2
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers