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 <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:
>> 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 | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You are standing on my toes.
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users
> 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:
>> 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 | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You are standing on my toes.
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users