While I was at first concerned about wording, which I address first, I am also concerned about the substance of the CVE, which I'll address at the end.
On Nov 15, 2016, at 6:00 PM, Martin Winter <[email protected]> wrote: > On 14 Nov 2016, at 21:20, Alexis Rosen wrote: >> On Oct 18, 2016, at 1:56 AM, Martin Winter <[email protected]> >> wrote: >>> Security Advisory: Quagga Buffer Overflow in IPv6 RA handling >>> ============================================================= >>> >>> [...] The issue can be triggered on an IPv6 address where the Quagga >>> daemon is reachable by a RA (Router Advertisement or IPv6 ICMP message. >> >> So... Nearly a month later, I'm deleting old mail and noticed this. >> >> As far as I can tell, this is an editing error of some sort, and in fact you >> can NOT trigger the issue simply by having an IPv6 address reachable with an >> ICMP. > > How about this wording: > > A buffer overflow exists in the IPv6 (Router Advertisement) code in > Zebra. The issue can be triggered on any interface with a reachable > IPv6 address > by a RA (Router Advertisement) or IPv6 ICMP message. > The issue leads to a crash of the zebra daemon. Actually, this continues the confusion. The statement above is compatible with this interpretation: The issue can be triggered on any interface with a reachable IPv6 address by any IPv6 ICMP message ...but that's not true. I think what you're trying to say is this: The issue can be triggered on any interface that has a reachable IPv6 address by a Router Advertisement packet ("RA", or ICMPv6 type 134). Also, there is ambiguity as to whether RA-issuing or RA-receiving code is the problem (see below). If I am correct, then let me suggest the following as a complete replacement for the lead paragraph: A remotely exploitable buffer overflow exists in the IPv6 Router Advertisement reception code in Zebra. The issue can be triggered on any interface that has a reachable IPv6 address, by a Router Advertisement packet ("RA", or ICMPv6 type 134). To be vulnerable, the Zebra daemon must be running, and the non-default "no ipv6 nd suppress-ra" must be enabled an at least one interface. >> Later in the advisory, it says: >>> Usage of Quagga without running the 'zebra' daemon, or no >>> IPv6 neighbor-discovery are not affected. > > What this should say: > The issue is in Zebra daemon. So you are safe without Zebra daemon (i.e. some > users only using BGPd) > You are also safe if you have the IPv6 neighbor-discovery disabled. > > So maybe just a missing comma? > > Usage of Quagga without running the 'zebra' daemon, or no > IPv6 neighbor-discovery, are not affected. That's ambiguous because of the double-negative. Maybe this? Users of Quagga who do not use the Zebra daemon are NOT affected. Users of Zebra who have IPv6 neighbor-discovery disabled (the default) are NOT affected. Enabling IPv6 neighbor-discovery on ANY interface exposes users to this attack on EVERY IPv6 interface. However I am still puzzled by something. "ipv6 nd suppress-ra" prevents Quagga from *sending* RAs. But the bug described is in receiving RAs. Will "ipv6 nd suppress-ra" really prevent the bug? Since this bug only affects Linux, would it instead make more sense to do net.ipv6.conf.all.accept_ra=0 and maybe net.ipv6.conf.default.accept_ra=0 instead to work around the bug? That would prevent processing of all RA messages on every interface. Another approach would be to turn off autoconfig for all interfaces, but I am not 100% sure the vulnerable code path would be avoided then. Thanks, and sorry this is so late. /a _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
