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 <mwinter@opensourcerouting.org> wrote:
> On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
>> On Oct 18, 2016, at 1:56 AM, Martin Winter <mwinter@opensourcerouting.org> 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
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
On Nov 15, 2016, at 6:00 PM, Martin Winter <mwinter@opensourcerouting.org> wrote:
> On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
>> On Oct 18, 2016, at 1:56 AM, Martin Winter <mwinter@opensourcerouting.org> 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
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev