[OSSA-2019-001] It's possible to add a security group rule for VRRP with a dport (CVE-2019-9735)

[Erik Olof Gunnar Andersson]

This command should be invalid, but Neutron (Rocky) allows it to be created.
> openstack security group rule create xxx --protocol vrrp --ingress --remote-ip <ip> --dst-port 112

Since iptables does not allow dst-port being passed. It would trigger the following error on the compute and fail to apply any future iptable rules.
> unknown option "--dport"

[OpenStack Infra (hudson-openstack)]

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

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.openstack.org/640685

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/640702

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/640790

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/640791

[Jeremy Stanley (fungi)]

Just to confirm, any tenant can add such a malformed security group rule and block all future rules any other tenant tries to add for an instance on the same hypervisor host. Is this an accurate assessment? Just trying to get the details straight for triage of possible advisory and associated impact description. Thanks!

[Doug Wiegley (dougwig)]

A little bit worse than that, since we also use the rules for basic connectivity in some cases, so sometimes no new VMs would ever work, and the ones that do would be open. And if the hypervisor is rebooted or the neutron agent restarted, all rules would end up wiped.

Your iptables would effectively be frozen at the point of the bad rule being inserted, whatever that was.

Workarounds include the patch, or using the OVS security group driver.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the prompt feedback Doug. I'm triaging this as class A based on above comments.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Doug Wiegley (<email address hidden>) on branch: stable/ocata
Review: https://review.openstack.org/640791
Reason: Will re-spin when master merges, and check that UT failure there.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Doug Wiegley (<email address hidden>) on branch: stable/pike
Review: https://review.openstack.org/640790
Reason: Will re-spin when master merges, and check that UT failure there.

[OpenStack Infra (hudson-openstack)]

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

[Marcin Kosobucki (mkosobucki)]

It may be worth, to consider syntax validation using "iptables-restore --test" before actually trying to apply changes.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/640619
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8c213e45902e21d2fe00639ef7d92b35304bde82
Submitter: Zuul
Branch: master

commit 8c213e45902e21d2fe00639ef7d92b35304bde82
Author: Doug Wiegley <email address hidden>
Date: Sat Mar 2 22:35:52 2019 -0700

    When converting sg rules to iptables, do not emit dport if not supported

    Since iptables-restore doesn't support --dport with protocol vrrp,
    it errors out setting the security groups on the hypervisor.

    Marking this a partial fix, since we need a change to prevent
    adding those incompatible rules in the first place, but this
    patch will stop the bleeding.

    Change-Id: If5e557a8e61c3aa364ba1e2c60be4cbe74c1ec8f
    Partial-Bug: #1818385

[Jeremy Stanley (fungi)]

Given a hotfix for this has merged on master now, I'm proposing an impact description for use in an upcoming OpenStack Security Advisory and associated CVE request. Please suggest improvements...

Title: Unsupported dport option prevents applying security groups
Reporter: Erik Olof Gunnar Andersson (Blizzard Entertainment)
Products: Neutron
Affects: <10.0.8, >=11.0.0 <11.0.7, >=12.0.0 <12.0.6, >=13.0.0 <13.0.3

Description:
Erik Olof Gunnar Andersson with Blizzard Entertainment reported a vulnerability in Neutron's iptables firewall module. By setting a destination port in a security group rule along with a protocol which doesn't support that option (for example, VRRP), an authenticated user may block further application of security group rules for instances from any project/tenant on the compute hosts to which it's applied. Only deployments using the iptables security group driver are affected.

[Doug Wiegley (dougwig)]

I'll update the backports today.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks fungi, the impact description LGTM.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/640702
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b88ab58daf12337903f3fd8a4ab4c6add6f379cd
Submitter: Zuul
Branch: stable/queens

commit b88ab58daf12337903f3fd8a4ab4c6add6f379cd
Author: Doug Wiegley <email address hidden>
Date: Sat Mar 2 22:35:52 2019 -0700

    When converting sg rules to iptables, do not emit dport if not supported

    Since iptables-restore doesn't support --dport with protocol vrrp,
    it errors out setting the security groups on the hypervisor.

    Marking this a partial fix, since we need a change to prevent
    adding those incompatible rules in the first place, but this
    patch will stop the bleeding.

    Change-Id: If5e557a8e61c3aa364ba1e2c60be4cbe74c1ec8f
    Partial-Bug: #1818385
    (cherry picked from commit 8c213e45902e21d2fe00639ef7d92b35304bde82)

[Jeremy Stanley (fungi)]

As no edits have been recommended for the proposed impact description, I have now used it to submit a CVE request to MITRE and will update this report with the assigned CVE identifier once issued.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/643007

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/640685
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=558a977902c9e83aabaefe67333aee544aa86585
Submitter: Zuul
Branch: stable/rocky

commit 558a977902c9e83aabaefe67333aee544aa86585
Author: Doug Wiegley <email address hidden>
Date: Sat Mar 2 22:35:52 2019 -0700

    When converting sg rules to iptables, do not emit dport if not supported

    Since iptables-restore doesn't support --dport with protocol vrrp,
    it errors out setting the security groups on the hypervisor.

    Marking this a partial fix, since we need a change to prevent
    adding those incompatible rules in the first place, but this
    patch will stop the bleeding.

    Change-Id: If5e557a8e61c3aa364ba1e2c60be4cbe74c1ec8f
    Partial-Bug: #1818385
    (cherry picked from commit 8c213e45902e21d2fe00639ef7d92b35304bde82)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/640791
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f6be9d7ad9522b58b293494e2e9988ce19387273
Submitter: Zuul
Branch: stable/ocata

commit f6be9d7ad9522b58b293494e2e9988ce19387273
Author: Doug Wiegley <email address hidden>
Date: Sat Mar 2 22:35:52 2019 -0700

    When converting sg rules to iptables, do not emit dport if not supported

    Since iptables-restore doesn't support --dport with protocol vrrp,
    it errors out setting the security groups on the hypervisor.

    Marking this a partial fix, since we need a change to prevent
    adding those incompatible rules in the first place, but this
    patch will stop the bleeding.

    Change-Id: If5e557a8e61c3aa364ba1e2c60be4cbe74c1ec8f
    Partial-Bug: #1818385
    (cherry picked from commit 8c213e45902e21d2fe00639ef7d92b35304bde82)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/640790
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e53afe831abd651e318b5a56372a230ee5f49731
Submitter: Zuul
Branch: stable/pike

commit e53afe831abd651e318b5a56372a230ee5f49731
Author: Doug Wiegley <email address hidden>
Date: Sat Mar 2 22:35:52 2019 -0700

    When converting sg rules to iptables, do not emit dport if not supported

    Since iptables-restore doesn't support --dport with protocol vrrp,
    it errors out setting the security groups on the hypervisor.

    Marking this a partial fix, since we need a change to prevent
    adding those incompatible rules in the first place, but this
    patch will stop the bleeding.

    Change-Id: If5e557a8e61c3aa364ba1e2c60be4cbe74c1ec8f
    Partial-Bug: #1818385
    (cherry picked from commit 8c213e45902e21d2fe00639ef7d92b35304bde82)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/642145
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4350ed3c3556388eaa7f8623ed05b5adc86e9c16
Submitter: Zuul
Branch: master

commit 4350ed3c3556388eaa7f8623ed05b5adc86e9c16
Author: Brian Haley <email address hidden>
Date: Fri Mar 8 15:24:24 2019 -0500

    Better handle ports in security groups

    After taking a closer look at bug 1818385, I found a couple
    of follow-on things to fix in the security group code.

    First, there are very few protocols that accept ports,
    especially via iptables. For this reason I think it's
    acceptable that the API rejects them as invalid.

    Second, UDPlite has some interesting support in iptables. It
    does not support using --dport directly, but does using
    '-m multiport --dports 123', and also supports port ranges using
    '-m multiport --dports 123:124'. Added code for this special
    case.

    Change-Id: Ifb2e6bb6c7a2e2987ba95040ef5a98ed50aa36d4
    Closes-Bug: #1818385

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/643007
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=a8c4ab769b94fd8d8d0e849a5541beee47f0532a
Submitter: Zuul
Branch: master

commit a8c4ab769b94fd8d8d0e849a5541beee47f0532a
Author: Tristan Cacqueray <email address hidden>
Date: Wed Mar 13 11:17:15 2019 +0000

    Adds OSSA-2019-001 (CVE-2019-9735)

    Change-Id: I11ec9820642d1eca14517bd39e01b5e8581cda82
    Related-Bug: #1818385

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 14.0.0.0rc1 release candidate.