[CVE-2016-9599] undercloud firewall opening all ports with ssl enabled

Bug #1651831 reported by Ben Nemec
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
Critical
Emilien Macchi
Newton
Fix Released
Critical
Emilien Macchi

Bug Description

Example of a simple telnet session to the undercloud on a port that should not be open:

[root@overcloud-novacompute-0 heat-admin]# telnet 9.1.1.1 12010
Trying 9.1.1.1...
Connected to 9.1.1.1.
Escape character is '^]'.
hello

[root@undercloud centos]# nc -k -l -p 12010
hello

The cause appears to be an error in the undercloud ssl puppet config where it is adding accept rules without a port specified, so it's allowing traffic on all ports. Ironically, an undercloud without ssl does not have this problem.

There are several incorrect rules, but here's one example:

-A INPUT -p tcp -m comment --comment "100 glance_registry_haproxy_ssl" -m state --state NEW -j ACCEPT

One more complication with this - right now our CI is relying on this bug to function. We'll need to figure out which port is being blocked and breaking our gearman communication as part of fixing this.

CVE References

Revision history for this message
Ben Nemec (bnemec) wrote :

This also appears to affect newton, but not mitaka because the changes that caused this weren't made yet in mitaka.

Revision history for this message
Emilien Macchi (emilienm) wrote :

This is my first attempt to fix the problem.

Changed in tripleo:
milestone: none → ocata-3
status: Triaged → In Progress
Revision history for this message
Juan Antonio Osorio Robles (juan-osorio-robles) wrote :

The diff seems wrong, it's
+ if $service_port {
+ $haproxy_ssl_firewall_rules = {
+ "100 ${name}_haproxy_ssl" => {
+ 'dport' => $public_ssl_port,
+ },
+ }
+ }

and it should be:

+ if $public_ssl_port {
+ $haproxy_ssl_firewall_rules = {
+ "100 ${name}_haproxy_ssl" => {
+ 'dport' => $public_ssl_port,
+ },
+ }
+ }

Revision history for this message
Emilien Macchi (emilienm) wrote :

Juan, yes you're right, I had issues with Launchpad to update the second patch I prepared. Please review it again. Thanks!

Revision history for this message
Emilien Macchi (emilienm) wrote :

Juan and I tested this new patch on the undercloud and it seems to work fine. We're now testing on the overcloud.

Changed in tripleo:
assignee: Ben Nemec (bnemec) → Emilien Macchi (emilienm)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to puppet-tripleo (master)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to puppet-tripleo (stable/newton)

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/414239

information type: Private Security → Public Security
summary: - undercloud firewall opening all ports with ssl enabled
+ [CVE-2016-9599] undercloud firewall opening all ports with ssl enabled
Changed in tripleo:
importance: High → Critical
Revision history for this message
Ben Nemec (bnemec) wrote :

Note that it appears our ci is not depending on this bug anymore, so we're free to fix it without blocking anything new.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to puppet-tripleo (master)

Reviewed: https://review.openstack.org/414238
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=70c9dca45335150daae65d0bbf44908711b0f1d2
Submitter: Jenkins
Branch: master

commit 70c9dca45335150daae65d0bbf44908711b0f1d2
Author: Emilien Macchi <email address hidden>
Date: Wed Dec 21 15:10:52 2016 -0500

    [CVE-2016-9599] Enforce Firewall TCP / UDP rules management

    This closes CVE-2016-9599.

    1) Sanitize dynamic HAproxy endpoints firewall rules

    Build the hash of firewall rules only when a port is specified. The
    HAproxy endpoints are using TCP protocol, which means we have to specify
    a port to the IPtables rules.
    Some services don't have public network exposure (e.g. Glance Registry),
    which means they don't need haproxy_ssl rule.
    The code prepare the hash depending on the service_port and
    public_ssl_port parameters and create the actual firewall rules only if
    one of those or both parameters are specified.
    It will prevent new services without public exposure to open all traffic
    because no port is specified.

    2) Secure Firewall rules creations

    The code won't allow to create TCP / UDP IPtables rules in INPUT
    or OUTPUT chains without port or sport or dport, because doing it would
    allow an IPtables rule opening all traffic for TCP or UDP.
    If we try to do that, Puppet catalog will fail with an error explaining
    why.
    Example of use-cases:
    - creating VRRP rules wouldn't require port parameters.
    - creating TCP or UDP rules would require port parameters.

    3) Allow to open all traffic for TCO / UDP (when desired)

    Some use-cases require to open all traffic for all ports on TCP / UDP.
    It will be possible if the user gives port = 'all' when creating the
    firewall rule.

    Backward compatibility:
    - if our users created custom TCP / UDP firewall rules without port
      parameters, it won't work anymore, for security purpose.
    - if you users want to open TCP / UDP for all ports, they need to pass
      port = 'all' and the rule will be created, though a warning will be
      displayed because this is insecure.
    - if our users created custom VRRP rules without port parameters, it
      will still work correctly and rules will be created.
    - TCP / UDP rules in FORWARD chain without port are still accepted.

    Change-Id: I19396c8ab06b91fee3253cdfcb834482f4040a59
    Closes-Bug: #1651831

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

Reviewed: https://review.openstack.org/414239
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=3be9575fb091582ec0666d57efc7e8158ae7c17e
Submitter: Jenkins
Branch: stable/newton

commit 3be9575fb091582ec0666d57efc7e8158ae7c17e
Author: Emilien Macchi <email address hidden>
Date: Wed Dec 21 15:10:52 2016 -0500

    [CVE-2016-9599] Enforce Firewall TCP / UDP rules management

    This closes CVE-2016-9599.

    1) Sanitize dynamic HAproxy endpoints firewall rules

    Build the hash of firewall rules only when a port is specified. The
    HAproxy endpoints are using TCP protocol, which means we have to specify
    a port to the IPtables rules.
    Some services don't have public network exposure (e.g. Glance Registry),
    which means they don't need haproxy_ssl rule.
    The code prepare the hash depending on the service_port and
    public_ssl_port parameters and create the actual firewall rules only if
    one of those or both parameters are specified.
    It will prevent new services without public exposure to open all traffic
    because no port is specified.

    2) Secure Firewall rules creations

    The code won't allow to create TCP / UDP IPtables rules in INPUT
    or OUTPUT chains without port or sport or dport, because doing it would
    allow an IPtables rule opening all traffic for TCP or UDP.
    If we try to do that, Puppet catalog will fail with an error explaining
    why.
    Example of use-cases:
    - creating VRRP rules wouldn't require port parameters.
    - creating TCP or UDP rules would require port parameters.

    3) Allow to open all traffic for TCO / UDP (when desired)

    Some use-cases require to open all traffic for all ports on TCP / UDP.
    It will be possible if the user gives port = 'all' when creating the
    firewall rule.

    Backward compatibility:
    - if our users created custom TCP / UDP firewall rules without port
      parameters, it won't work anymore, for security purpose.
    - if you users want to open TCP / UDP for all ports, they need to pass
      port = 'all' and the rule will be created, though a warning will be
      displayed because this is insecure.
    - if our users created custom VRRP rules without port parameters, it
      will still work correctly and rules will be created.
    - TCP / UDP rules in FORWARD chain without port are still accepted.

    Change-Id: I19396c8ab06b91fee3253cdfcb834482f4040a59
    Closes-Bug: #1651831
    (cherry picked from commit 2e0f82822942308594115c42fe82d078e5a4af45)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/puppet-tripleo 5.5.0

This issue was fixed in the openstack/puppet-tripleo 5.5.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/puppet-tripleo 6.2.0

This issue was fixed in the openstack/puppet-tripleo 6.2.0 release.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.