neutron metadata agent is always binding to 0.0.0.0

Bug #1745618 reported by Andrey Arapov
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
networking-ovn
Fix Released
Low
Daniel Alvarez
neutron
Fix Released
Low
Bernard Cafarelli

Bug Description

Dear Devs,

while using kolla-ansible (5.0.1) to deploy Openstack Pike, I have spotted one potential security issue with the way Neutron metadata agent is listening.

Potential, because it all depends whether users are adding anything sensitive to their meta-data / user-data.

ns-metadata-proxy always binds to a 0.0.0.0 https://github.com/openstack/neutron/blob/703ff85b8262997f209e7666396c5d430d3baa34/neutron/agent/metadata/driver.py#L64

$ ip netns exec qdhcp-f2780ea0-8d83-4434-9d0f-914392d1c3b1 netstat -tulpan
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 22103/haproxy
tcp 0 0 10.0.0.2:53 0.0.0.0:* LISTEN 22446/dnsmasq
tcp 0 0 169.254.169.254:53 0.0.0.0:* LISTEN 22446/dnsmasq
...

My Openstack has a private subnet 10.0.0.0/24, where 10.0.0.1 is a gateway and 10.0.0.2-10.0.0.254 is the allocation pool.

$ ip netns exec qdhcp-f2780ea0-8d83-4434-9d0f-914392d1c3b1 ip a
2: ns-a1f7e93e-53@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP qlen 1000
    link/ether fa:16:3e:07:8a:c8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.0.2/24 brd 10.0.0.255 scope global ns-a1f7e93e-53
    inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-a1f7e93e-53

I am running Docker containers (via Kubernetes) in Openstack VM's.
What concerns me is that any container (with its namespaced container network) is able to access the Neutron metadata agent not only via http://169.254.169.254/, but also via http://10.0.0.2/ (since the latter is on the same private subnet).
Pretty much any IP address available on the namespaced network interface will return Metadata if accessed via HTTP port 80.

I am using this iptables rule so that no Docker container is able to access the 169.254.169.254 as they do not need to access it:

iptables -I DOCKER-USER -d 169.254.169.254/32 # where DOCKER-USER is the first subchain in the FORWARD chain

That works well for blocking random users accessing the 169.254.169.254.

(As a workaround) I am modifying the driver.py directly so that it will listen only over 169.254.169.254:

docker exec -u root -ti neutron_dhcp_agent bash -c "sed -i 's/bind 0.0.0.0/bind 169.254.169.254/' /usr/lib/python2.7/site-packages/neutron/agent/metadata/driver.py"

docker restart neutron_dhcp_agent

From your point of view, does it makes sense to change the default bind 0.0.0.0 to bind 169.254.169.254 ?

In meanwhile, I have prepared a little patch to neutron ns-metadata-proxy so that the listener binds to dhcp.METADATA_DEFAULT_IP which is 169.254.169.254. Please let me know if it makes sense to you so I will prepare a PR.

I have also attached a preliminary patch to this issue, but haven't tested it yet.

Kind regards,
Andrey Arapov

Revision history for this message
Andrey Arapov (andrey-arapov) wrote :
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
Revision history for this message
jython (jython) wrote :

Also affects me

Changed in neutron:
status: New → Confirmed
Changed in neutron:
importance: Undecided → Low
Revision history for this message
Bernard Cafarelli (bcafarel) wrote :

The patch idea makes sense, I will work on getting it up for review (getting additional feedback there if needed)

Changed in neutron:
status: Confirmed → In Progress
assignee: nobody → Bernard Cafarelli (bcafarel)
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/600421

Changed in neutron:
assignee: Bernard Cafarelli (bcafarel) → Brian Haley (brian-haley)
Changed in neutron:
assignee: Brian Haley (brian-haley) → Bernard Cafarelli (bcafarel)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/600421
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=6124f6029729c3c800287f3f02329901d93ea021
Submitter: Zuul
Branch: master

commit 6124f6029729c3c800287f3f02329901d93ea021
Author: Bernard Cafarelli <email address hidden>
Date: Thu Sep 6 10:48:13 2018 +0200

    Switch isolated metadata proxy to bind to 169.254.169.254

    Currently the metadata proxy binds to default 0.0.0.0, which does not
    add any advantage (metadata requests are not sent to random IP
    addresses), and may allow access to cloud information from
    third parties.

    This changes the generated configuration to bind to METADATA_DEFAULT_IP
    address instead.

    This is not enabled in other metadata proxy configuration (in the L3
    agent), as this would require net.ipv4.ip_nonlocal_bind everywhere
    (currently only enabled for DVR) or transparent mode in haproxy (which
    requires net.ipv4.ip_nonlocal_bind anyway)

    Changed set_ip_nonlocal_bind_for_namespace() to support setting the
    value in both the given and root namespace correctly, since it was
    only used from inside the neutron codebase according to codesearch.

    Change-Id: I388391cf697dade1a163d15ab568b33134f7b2d9
    Co-Authored-By: Andrey Arapov <email address hidden>
    Closes-Bug: #1745618

Changed in neutron:
status: In Progress → Fix Released
Changed in networking-ovn:
assignee: nobody → Daniel Alvarez (dalvarezs)
importance: Undecided → Low
Changed in networking-ovn:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to networking-ovn (master)

Reviewed: https://review.openstack.org/634947
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=78dcb186ef53f1ccdafcc0301aab51689eb7c7e8
Submitter: Zuul
Branch: master

commit 78dcb186ef53f1ccdafcc0301aab51689eb7c7e8
Author: Daniel Alvarez <email address hidden>
Date: Tue Feb 5 15:36:02 2019 +0100

    ovn-metadata-agent: bind haproxy to 169.254.169.254

    Currently ovn-metadata-agent spawns haproxy to bind in 0.0.0.0 inside
    the ovnmeta namespace. This is not needed as we know that we'll always
    receive those in 169.254.169.254 and it can have security issues.

    Closes-Bug: #1745618
    Signed-off-by: Daniel Alvarez <email address hidden>
    Change-Id: I19ba651ad5b120ecb9859d9f7786b447f3218078

Changed in networking-ovn:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/rocky)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/queens)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/queens)

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

commit 13d23ba36340023bceaed46c5c13942b64f9e42f
Author: Bernard Cafarelli <email address hidden>
Date: Thu Sep 6 10:48:13 2018 +0200

    Switch isolated metadata proxy to bind to 169.254.169.254

    Currently the metadata proxy binds to default 0.0.0.0, which does not
    add any advantage (metadata requests are not sent to random IP
    addresses), and may allow access to cloud information from
    third parties.

    This changes the generated configuration to bind to METADATA_DEFAULT_IP
    address instead.

    This is not enabled in other metadata proxy configuration (in the L3
    agent), as this would require net.ipv4.ip_nonlocal_bind everywhere
    (currently only enabled for DVR) or transparent mode in haproxy (which
    requires net.ipv4.ip_nonlocal_bind anyway)

    Changed set_ip_nonlocal_bind_for_namespace() to support setting the
    value in both the given and root namespace correctly, since it was
    only used from inside the neutron codebase according to codesearch.

    Change-Id: I388391cf697dade1a163d15ab568b33134f7b2d9
    Co-Authored-By: Andrey Arapov <email address hidden>
    Closes-Bug: #1745618
    (cherry picked from commit 6124f6029729c3c800287f3f02329901d93ea021)

tags: added: in-stable-queens
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/rocky)

Reviewed: https://review.openstack.org/636298
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=964dd28a95347d22ddf647b56a1866a034b8de61
Submitter: Zuul
Branch: stable/rocky

commit 964dd28a95347d22ddf647b56a1866a034b8de61
Author: Bernard Cafarelli <email address hidden>
Date: Thu Sep 6 10:48:13 2018 +0200

    Switch isolated metadata proxy to bind to 169.254.169.254

    Currently the metadata proxy binds to default 0.0.0.0, which does not
    add any advantage (metadata requests are not sent to random IP
    addresses), and may allow access to cloud information from
    third parties.

    This changes the generated configuration to bind to METADATA_DEFAULT_IP
    address instead.

    This is not enabled in other metadata proxy configuration (in the L3
    agent), as this would require net.ipv4.ip_nonlocal_bind everywhere
    (currently only enabled for DVR) or transparent mode in haproxy (which
    requires net.ipv4.ip_nonlocal_bind anyway)

    Changed set_ip_nonlocal_bind_for_namespace() to support setting the
    value in both the given and root namespace correctly, since it was
    only used from inside the neutron codebase according to codesearch.

    Change-Id: I388391cf697dade1a163d15ab568b33134f7b2d9
    Co-Authored-By: Andrey Arapov <email address hidden>
    Closes-Bug: #1745618
    (cherry picked from commit 6124f6029729c3c800287f3f02329901d93ea021)

tags: added: in-stable-rocky
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 14.0.0.0b2

This issue was fixed in the openstack/neutron 14.0.0.0b2 development milestone.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/networking-ovn 6.0.0.0b1

This issue was fixed in the openstack/networking-ovn 6.0.0.0b1 development milestone.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 13.0.3

This issue was fixed in the openstack/neutron 13.0.3 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 12.0.6

This issue was fixed in the openstack/neutron 12.0.6 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/pike)

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/732712

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/pike)

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

commit ffe8080a91e27233299a38eb845a028682bde167
Author: Bernard Cafarelli <email address hidden>
Date: Thu Sep 6 10:48:13 2018 +0200

    Switch isolated metadata proxy to bind to 169.254.169.254

    Currently the metadata proxy binds to default 0.0.0.0, which does not
    add any advantage (metadata requests are not sent to random IP
    addresses), and may allow access to cloud information from
    third parties.

    This changes the generated configuration to bind to METADATA_DEFAULT_IP
    address instead.

    This is not enabled in other metadata proxy configuration (in the L3
    agent), as this would require net.ipv4.ip_nonlocal_bind everywhere
    (currently only enabled for DVR) or transparent mode in haproxy (which
    requires net.ipv4.ip_nonlocal_bind anyway)

    Changed set_ip_nonlocal_bind_for_namespace() to support setting the
    value in both the given and root namespace correctly, since it was
    only used from inside the neutron codebase according to codesearch.

    Conflicts:
            neutron/agent/linux/dhcp.py
            neutron/tests/unit/agent/linux/test_ip_lib.py

    Change-Id: I388391cf697dade1a163d15ab568b33134f7b2d9
    Co-Authored-By: Andrey Arapov <email address hidden>
    Closes-Bug: #1745618
    (cherry picked from commit 6124f6029729c3c800287f3f02329901d93ea021)
    (cherry picked from commit 13d23ba36340023bceaed46c5c13942b64f9e42f)

tags: added: in-stable-pike
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron pike-eol

This issue was fixed in the openstack/neutron pike-eol release.

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

Other bug subscribers

Remote bug watches

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