[quagga-dev 16413] Re: [quagga-users 14531] Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)
On Nov 16, 2016, at 10:14 AM, Paul Jakma wrote:
> On Wed, 16 Nov 2016, Alexis Rosen wrote:
>> On Nov 15, 2016, at 6:00 PM, Martin Winter
>> wrote:
>>> On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
On Oct 18, 2016, at 1:56 AM, Martin Winter
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
[quagga-dev 16412] Re: [quagga-users 14526] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)
On Nov 16, 2016, at 10:05 AM, Paul Jakma wrote: > On Tue, 15 Nov 2016, Alexis Rosen wrote: > >> 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. > > Ah, what's the basis for that? I looked at the code, and that security claim > seemed possible. ISTM that the bug is in code which allocates memory to hold contents of a received RA, so if you can't get RAs on the box, you'll never try to allocate a too-small amount of memory. RSes as well? However, given the difficulty/CPU cost of blocking obscured ICMPv6 packets (see for example RFC7113), maybe drawing the distinction between different types of ICMPs isn't all that useful in a practical security context. >> Later in the advisory, it says: > >>> Usage of Quagga without running the 'zebra' daemon, or no >>> IPv6 neighbor-discovery are not affected. >> >> A quick look at the code also suggests this is so, but my familiarity with >> this code is basically nil, and it would be very easy for me to get this >> wrong. > > The code concerned is all the zebra daemon, so that's correct. The code that > reads the message is only enabled if the zebra RA/ND feature is. > > Note, you could have the kernel IPv6 ND/SLAC enabled, and be fine - it's > about the zebra feature. That's also not 100% clear. Yes. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16411] Re: [quagga-users 14524] quagga 1.1 seems to have completely broken ospf6
Martin, all,
2016-11-17 12:28 GMT+01:00 Martin Winter :
> I’ve reproduced the issue and created a topology test for it.
>
> Thanks to Jan Hugo Prins for his time to help me debug this. Don’t know
> why this didn’t trigger an error in my RFC compliance tests)
>
> Test is requires a Ubuntu 16.04 with Mininet installed
>
> Python script for the test and documentation is in the git at
> https://git.netdef.org/scm/netdef/topotests.git
>
> I’m going to add this test to my CI system AFTER the code is fixed
> (otherwise every patch submission will be flagged as bad)
>
> Regards,
>Martin Winter
>
>
> PS: I have not spent time in any bisect or any search for the bad
> commit. I hope someone else here takes over…
After upgrading to Quagga 1.1.0, we also have problems with ospf6 on
Linux (routes are not calculated anymore).
Reverting this patch fixes the problem for us (but no idea why):
e509af86e357 ("opsf6d: Update router-LSA when nbr's interface-ID changes")
Regards,
Julien
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16410] Re: [quagga-users 14524] quagga 1.1 seems to have completely broken ospf6
I’ve reproduced the issue and created a topology test for it. Thanks to Jan Hugo Prins for his time to help me debug this. Don’t know why this didn’t trigger an error in my RFC compliance tests) Test is requires a Ubuntu 16.04 with Mininet installed Python script for the test and documentation is in the git at https://git.netdef.org/scm/netdef/topotests.git I’m going to add this test to my CI system AFTER the code is fixed (otherwise every patch submission will be flagged as bad) Regards, Martin Winter PS: I have not spent time in any bisect or any search for the bad commit. I hope someone else here takes over… PSS: I’m working on topology tests for some time and I’m planning to add more to the automated tests. Working on some BGP tests as well and want to add several tests with route-map and redistribution etc to it. Suggestions welcome… On 15 Nov 2016, at 23:51, Nicolas DEFFAYET wrote: > On Tue, 2016-11-15 at 15:12 -0800, Martin Winter wrote: > > Hello Martin, > >> Can you clarify on the “broken” in 1.1.0? > > https://bugzilla.quagga.net/show_bug.cgi?id=885 > https://bugzilla.quagga.net/show_bug.cgi?id=886 > >> - FreeBSD Version? > > FreeBSD 11.0 but it's not related to FreeBSD because users have reported > the same issue on Linux. > >> - Broken = no neighbors formed? No routes in routing table? > > Neighbors are formed but no routes in routing table. > > Between 1.0.20160315 and 1.1.0 the following commit have been done: > ospf6d: fix off-by-one on display of spf reasons > ospf6d: don't access nexthops out of bounds > ospf6d: Fix double increment of Sequence Number > ospf6d: Fix loss of hello's on interface > ospf6d: Adding the initialization check in ospfv3_clean() > ospf6d: Fixing a couple of issues with ospf6_route_remo... > ospf6d: LA (local-address) bit related inter-op fix. > ospf6d: We should accept long form of "no redistribute" > ospf6d: Add the missing ospf6 running check in show... > ospf6d: Support for 'clear ipv6 ospf6 interface [ifname] > opsf6d: Update router-LSA when nbr's interface-ID changes > ospf6d, ripd, vtysh: Fix "no set metric" for ospf6... > ospf6d: implement admin distance > > One of this commit break ospf6d. > > Thanks > > -- > Nicolas DEFFAYET > ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
