On Nov 16, 2016, at 10:14 AM, Paul Jakma <paul@jakma.org> wrote:
> On Wed, 16 Nov 2016, Alexis Rosen wrote:
>> 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:
>> 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[...]
My point is that the earlier text can be read to say that any ICMP can trigger the issue, whereas in fact only certain ICMPs can.
>> Also, there is ambiguity as to whether RA-issuing or RA-receiving code is the problem (see below).
>
> In the receive path.
Right, but since the workaround is to turn off the RA-issuing feature, this needs more clarity.
Is it the case that only RS messages actually trigger the bug? Nothing in the advisory actually says that. In fact there seems to be a lot of confusion in the text between RAs, RSes, and ND in general (which is the source of my confusion here).
>> 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.
Martin, are you OK with those paragraphs? If I'm correct above (about RSes being the only problem) would you like me to do a quick edit on the rest of the text?
>> 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.
Got it, thanks.
/a
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
> On Wed, 16 Nov 2016, Alexis Rosen wrote:
>> 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:
>> 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[...]
My point is that the earlier text can be read to say that any ICMP can trigger the issue, whereas in fact only certain ICMPs can.
>> Also, there is ambiguity as to whether RA-issuing or RA-receiving code is the problem (see below).
>
> In the receive path.
Right, but since the workaround is to turn off the RA-issuing feature, this needs more clarity.
Is it the case that only RS messages actually trigger the bug? Nothing in the advisory actually says that. In fact there seems to be a lot of confusion in the text between RAs, RSes, and ND in general (which is the source of my confusion here).
>> 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.
Martin, are you OK with those paragraphs? If I'm correct above (about RSes being the only problem) would you like me to do a quick edit on the rest of the text?
>> 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.
Got it, thanks.
/a
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev