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

On Wed, 16 Nov 2016, Alexis Rosen wrote:

> 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:

>> 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).

Correct. Though, note that if the former is true, then the former is 
true. If I can send an any ICMP message, I can send the required RA 
packet to DoS (if the code was compiled with stack buffer overflow 
detection, as a number of distros do by default) or remote code 
execution (otherwise).

> Also, there is ambiguity as to whether RA-issuing or RA-receiving code 
> is the problem (see below).

In the receive path.

> 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.

> 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.
>

I don't object as such.

> 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?

Yes, receiving these messages is only done if zebra is configured to 
send RAs. There are messages, e.g. a deliberate solicitation message 
from a client, that need to be handled.

> 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.

By the kernel, for its own client side auto-configuration. Different 
thing. The code concerned is the router-side advertisement, in zebra.

Unless I'm mistaken, I don't think the above would stop zebra reading 
the messages.

regards,
-- 
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You are standing on my toes.