ghsa-59qg-grp7-5r73
Vulnerability from github
Published
2021-05-27 19:00
Modified
2021-05-24 21:05
Summary
Weave Net clusters susceptible to MitM attacks via IPv6 rogue router advertisements
Details

Impact

An attacker able to run a process as root in a container is able to respond to DNS requests from the host and thereby insert themselves as a fake service.

In a cluster with an IPv4 internal network, if IPv6 is not totally disabled on the host (via ipv6.disable=1 on the kernel cmdline), it will be either unconfigured or configured on some interfaces, but it’s pretty likely that ipv6 forwarding is disabled, ie /proc/sys/net/ipv6/conf//forwarding == 0. Also by default, /proc/sys/net/ipv6/conf//accept_ra == 1. The combination of these 2 sysctls means that the host accepts router advertisements and configure the IPv6 stack using them.

By sending “rogue” router advertisements, an attacker can reconfigure the host to redirect part or all of the IPv6 traffic of the host to the attacker controlled container. Even if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond. If by chance you also have on the host a vulnerability like last year’s RCE in apt (CVE-2019-3462), you can now escalate to the host.

Patches

Weave Net version 2.6.3 (to be released soon) will disable the accept_ra option on the veth devices that it creates.

Workarounds

Users should not run containers with CAP_NET_RAW capability. This has been the advice from Weave Net for years. https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#-securing-the-setup

For more information

If you have any questions or comments about this advisory: * Open an issue in the Weave Net repo * Join the Weave Users Slack.

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/weaveworks/weave"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-11091"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-24T21:05:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn attacker able to run a process as root in a container is able to respond to DNS requests from the host and thereby insert themselves as a fake service.\n\nIn a cluster with an IPv4 internal network, if IPv6 is not totally disabled on the host (via ipv6.disable=1 on the kernel cmdline), it will be either unconfigured or configured on some interfaces, but it\u2019s pretty likely that ipv6 forwarding is disabled, ie /proc/sys/net/ipv6/conf//forwarding == 0. Also by default, /proc/sys/net/ipv6/conf//accept_ra == 1. The combination of these 2 sysctls means that the host accepts router advertisements and configure the IPv6 stack using them.\n\nBy sending \u201crogue\u201d router advertisements, an attacker can reconfigure the host to redirect part or all of the IPv6 traffic of the host to the attacker controlled container.\nEven if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond.\nIf by chance you also have on the host a vulnerability like last year\u2019s RCE in apt (CVE-2019-3462), you can now escalate to the host.\n\n### Patches\nWeave Net version 2.6.3 (to be released soon) will disable the accept_ra option on the veth devices that it creates.\n\n### Workarounds\nUsers should not run containers with CAP_NET_RAW capability.  This has been the advice from Weave Net for years.\nhttps://www.weave.works/docs/net/latest/kubernetes/kube-addon/#-securing-the-setup\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the Weave Net repo](https://github.com/weaveworks/weave/issues/new)\n* Join the \u003ca href=\"https://slack.weave.works/\" target=\"_blank\"\u003eWeave Users Slack\u003c/a\u003e.",
  "id": "GHSA-59qg-grp7-5r73",
  "modified": "2021-05-24T21:05:31Z",
  "published": "2021-05-27T19:00:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/weaveworks/weave/security/advisories/GHSA-59qg-grp7-5r73"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11091"
    },
    {
      "type": "WEB",
      "url": "https://github.com/weaveworks/weave/commit/15f21f1899060f7716c70a8555a084e836f39a60"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Weave Net clusters susceptible to MitM attacks via IPv6 rogue router advertisements"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…