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 <mwin...@opensourcerouting.org>
wrote:
On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
On Oct 18, 2016, at 1:56 AM, Martin Winter <mwin...@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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You are standing on my toes.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
