x/vulndb: potential Go vuln in github.com/weaveworks/weave: GHSA-59qg-grp7-5r73

[GoVulnBot]

In GitHub Security Advisory GHSA-59qg-grp7-5r73, there is a vulnerability in the following Go packages or modules:

Unit	Fixed	Vulnerable Ranges
github.com/weaveworks/weave	2.6.3	< 2.6.3

Cross references:

• CVE-2020-11091 appears in issue x/vulndb: potential Go vuln in github.com/weaveworks/weave: GHSA-59qg-grp7-5r73 #794 NOT_IMPORTABLE
• GHSA-59qg-grp7-5r73 appears in issue x/vulndb: potential Go vuln in github.com/weaveworks/weave: GHSA-59qg-grp7-5r73 #794 NOT_IMPORTABLE

See doc/triage.md for instructions on how to triage this report.

modules:
  - module: TODO
    versions:
      - fixed: 2.6.3
    packages:
      - package: github.com/weaveworks/weave
description: |-
    ### 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](https://github.com/weaveworks/weave/issues/new)
    * Join the <a href="https://slack.weave.works/" target="_blank">Weave Users Slack</a>.
cves:
  - CVE-2020-11091
ghsas:
  - GHSA-59qg-grp7-5r73

[tatianab]

Duplicate of #794