[quagga-dev 16405] Re: [quagga-users 14521] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)

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