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

[Bertrand Lallau]

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,

[Jeremy Stanley (fungi)]

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.

[Bertrand Lallau (bertrand-lallau)]

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

[Cedric Brandily (cbrandily)]

the bug concerns source-port

[Cedric Brandily (cbrandily)]

oups

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

[OpenStack Infra (hudson-openstack)]

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

[Thierry Carrez (ttx)]

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

[OpenStack Infra (hudson-openstack)]

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

[Thierry Carrez (ttx)]

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

[OpenStack Infra (hudson-openstack)]

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

[Nathan Kinder (nkinder)]

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

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

[OpenStack Infra (hudson-openstack)]

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)