Mailing List Archive: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)

Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)

Oct 17, 2016, 10:56 PM

Post #1 of 12 (6419 views)

Security Advisory: Quagga Buffer Overflow in IPv6 RA handling
=============================================================

A buffer overflow exists in the IPv6 (Router Advertisement) code in
Zebra. The issue can be triggered on an IPv6 address where the Quagga
daemon is reachable by a RA (Router Advertisement or IPv6 ICMP message.
The issue leads to a crash of the zebra daemon.

CVE:
CVE-2016-1245

Document Version:
1.0

Posting date:
Oct 18, 2016

Program Impacted:
Quagga (zebra) on Linux, with IPv6 AND IPv6 neighbor-discovery on any
interfaced enabled. Usage of Quagga without running the 'zebra' daemon, or no
IPv6 neighbor-discovery are not affected.

Versions affected:
- All Versions of Quagga running on Linux

Versions not affected:
- All Versions of Quagga on FreeBSD/NetBSD/OpenBSD/Solaris are not affected.
- Brocade 5400 vRouter - Not impacted.
- Brocade 5600 vRouter - Not impacted.
- BigSwitch Big Cloud Fabric code is not affected.

Severity:
High

Exploitable:
Remotely.

Description:
A buffer overflow exists in the IPv6 (Router Advertisement) code. The code
which handles IPv6 RA and IPv6 ICMP Router Solicitation advertisement
messages uses a wrong constant to limit its size. This does not affect *BSD
systems (FreeBSD/OpenBSD/NetBSD) or OpenSolaris, but at least all Linux
based systems.

For the exploit to work, the Quagga instance needs to be reachable over
IPv6. Any interface with IPv6 enabled can trivially allow the 'zebra'
daemon to be crashed (Denial-of-Service) via a buffer overflow. The issue
can be avoided by having the IPv6 Neighbor Discovery turned off (see
workaround), which is the default state.

Note: the neighbor discovery needs to be turned off on _ALL_ interfaces for
this to workaround to apply (not just the connected or active interfaces).

The bug is in the 'zebra' daemon (the main daemon). Deployments that do not
run the 'zebra' daemon (e.g. only running 'bgpd') are not affected.

On Linux distributions which compile Quagga with GCC -fstack-protector, the
impact may be limited to a DoS, as the GCC inserted stack-check function
epilogue should detect the overflow and safely abort the process if the bug
is exploited. Otherwise, the bug may allow arbitrary code execution by a
remote attacker.

Quagga supports running as a non-root user and with lowered privileges,
using capabilities on Linux, and this is highly encouraged. On Linux
distributions which configure Quagga to run this way, any exploit code will
be limited to a non-root environment, with 0 effective capabilities. The
acquirable capabilities are limited to CAP_NET_ADMIN, CAP_NET_RAW and
CAP_SYS_ADMIN.

CVSS v3 Base Score: 9.3

CVSS Equation:
For more information on the Common Vulnerability Scoring System and to
obtain your specific environmental score please visit:
https://nvd.nist.gov/cvss/v3-calculator?vector=3DAV:N/AC:L/PR:N/UI:N/S:U/
C:N/I:H/A:H/E:F/RL:X/RC:C

Workarounds:
Disable IPv6 neighbor discovery announcements on all interfaces ("ipv6 nd
suppress-ra" configured under all interfaces). Make sure to have it
disabled on ALL interfaces.

Active exploits:
None known in the public at this time. Internal Proof-of-Concept code
exists.

Fixed Versions:
TBD

Solution:
Upgrade to Quagga 1.0.20161017 or upgrade to latest GIT Master version or
apply patches located at the URL below to your source code.

Quagga can be downloaded from the following location:
http://www.nongnu.org/quagga/ or https://github.com/Quagga/quagga

Patch (Commit) for security fix is at
https://github.com/Quagga/quagga/commit/cfb1fae25f8c092e0d17073eaf7bd428ce1cd546

Document Revision History:
1.0 22 September 2016 - Initial (internal) draft
1.1 18 October 2016 - CVE release version

Acknowledgments:
The issue was uncovered by David Lamparter at OpenSourceRouting.org

References:
* Do you have Questions? Questions regarding this advisory should go to
security@quagga.net or security@opensourcerouting.org

Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

fw at deneb

Oct 18, 2016, 1:09 AM

Post #2 of 12 (6407 views)

Permalink

* Martin Winter:

> Document Revision History:
> 1.0 22 September 2016 - Initial (internal) draft
> 1.1 18 October 2016 - CVE release version

Why didn't you coordinate the disclosure with distributions?

Debian assigned a CVE ID to you in good faith, but the promised
coordination never happened. We never received the details of the
vulnerability, nor the planned disclosure date.

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

quagga-users at alexis

Oct 18, 2016, 1:59 AM

Post #3 of 12 (6405 views)

Permalink

On Oct 18, 2016, at 4:09 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Martin Winter:
>
>> Document Revision History:
>> 1.0 22 September 2016 - Initial (internal) draft
>> 1.1 18 October 2016 - CVE release version
>
> Why didn't you coordinate the disclosure with distributions?
>
> Debian assigned a CVE ID to you in good faith, but the promised
> coordination never happened. We never received the details of the
> vulnerability, nor the planned disclosure date.

For that matter, why didn't VyOS know about this? (They do now.)

Does Ubiquiti?

/a

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: [quagga-sec] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

paul at jakma

Oct 18, 2016, 3:33 AM

Post #4 of 12 (6407 views)

Permalink

On Tue, 18 Oct 2016, Florian Weimer wrote:

> Why didn't you coordinate the disclosure with distributions?

> Debian assigned a CVE ID to you in good faith, but the promised
> coordination never happened. We never received the details of the
> vulnerability, nor the planned disclosure date.

Not entirely Martin's fault. It wasn't entirely clear to the Quagga side
Martin was under obligations elsewhere on this.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Dr. Livingston?
Dr. Livingston I. Presume?

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: [quagga-sec] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

paul at jakma

Oct 18, 2016, 3:37 AM

Post #5 of 12 (6405 views)

Permalink

On Tue, 18 Oct 2016, Alexis Rosen wrote:

> For that matter, why didn't VyOS know about this? (They do now.)
>
> Does Ubiquiti?

Note: They may wish to subscribe to security@quagga.net if they're
Quagga distributors and have a reasonable interest in being involved in
or informed of security issues ahead of time:

https://lists.quagga.net/mailman/listinfo/security

Subscription is moderated, and subscribers MUST email an introduction to
security@quagga.net after subscribing, with details of their interest in
Quagga.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
QOTD:
"I drive my car quietly, for it goes without saying."

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: [quagga-sec] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

quagga-users at alexis

Oct 18, 2016, 4:03 AM

Post #6 of 12 (6406 views)

Permalink

On Oct 18, 2016, at 6:37 AM, Paul Jakma <paul@jakma.org> wrote:
> On Tue, 18 Oct 2016, Alexis Rosen wrote:
>> For that matter, why didn't VyOS know about this? (They do now.)
>>
>> Does Ubiquiti?
>
> Note: They may wish to subscribe to security@quagga.net if they're Quagga distributors[...]

I think this is a grave error. Not so much in terms of security (though it's not great), but in community-building. It's in Quagga's best interests to expand participation as much as possible. If that means seeking out forks/distros and opening communications with them, then that's worth doing, especially so with security patches. Start with those, you might get more code flowing up/downstream in general.

/a
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: [quagga-sec] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

paul at jakma

Oct 18, 2016, 4:18 AM

Post #7 of 12 (6406 views)

Permalink

On Tue, 18 Oct 2016, Alexis Rosen wrote:

> I think this is a grave error. Not so much in terms of security
> (though it's not great), but in community-building. It's in Quagga's
> best interests to expand participation as much as possible. If that
> means seeking out forks/distros and opening communications with them,
> then that's worth doing, especially so with security patches.

I'm not sure how inviting people to subscribe to a project security list
is mutually exclusive with communicating with other projects. And... the
other projects _were_ notified.

Also, how do you propose a project identifies those who may be
interested in security information, without inviting those who may be
interested to get in touch?

> Start with those, you might get more code flowing up/downstream in
> general.

You may wish to check commit stats.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Any sufficiently advanced technology is indistinguishable from a rigged demo.
- Andy Finkel, computer guy

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

mwinter at opensourcerouting

Oct 18, 2016, 7:10 AM

Post #8 of 12 (6400 views)

Permalink

So for the complains on not getting heads-up notification for some Distros:

Sorry.

We had some mis-communication on the Quagga-Security list on how to get
this released.
I wanted to give all the proper heads-up notifications.

This email is mainly a followup after Paul sent the release announcement
(on the quagga-devel list) with all the details visible in Git.
After this was out, I did not want to hold back the CVE as it was
now public visible.

Regards,
Martin Winter

On 17 Oct 2016, at 22:56, Martin Winter wrote:

> Security Advisory: Quagga Buffer Overflow in IPv6 RA handling
> =============================================================
>
> A buffer overflow exists in the IPv6 (Router Advertisement) code in
> Zebra. The issue can be triggered on an IPv6 address where the Quagga
> daemon is reachable by a RA (Router Advertisement or IPv6 ICMP message.
> The issue leads to a crash of the zebra daemon.
>
> CVE:
> CVE-2016-1245
>
> Document Version:
> 1.0
>
> Posting date:
> Oct 18, 2016
>
> Program Impacted:
> Quagga (zebra) on Linux, with IPv6 AND IPv6 neighbor-discovery on any
> interfaced enabled. Usage of Quagga without running the 'zebra' daemon, or no
> IPv6 neighbor-discovery are not affected.
>
> Versions affected:
> - All Versions of Quagga running on Linux
>
> Versions not affected:
> - All Versions of Quagga on FreeBSD/NetBSD/OpenBSD/Solaris are not affected.
> - Brocade 5400 vRouter - Not impacted.
> - Brocade 5600 vRouter - Not impacted.
> - BigSwitch Big Cloud Fabric code is not affected.
>
> Severity:
> High
>
> Exploitable:
> Remotely.
>
> Description:
> A buffer overflow exists in the IPv6 (Router Advertisement) code. The code
> which handles IPv6 RA and IPv6 ICMP Router Solicitation advertisement
> messages uses a wrong constant to limit its size. This does not affect *BSD
> systems (FreeBSD/OpenBSD/NetBSD) or OpenSolaris, but at least all Linux
> based systems.
>
> For the exploit to work, the Quagga instance needs to be reachable over
> IPv6. Any interface with IPv6 enabled can trivially allow the 'zebra'
> daemon to be crashed (Denial-of-Service) via a buffer overflow. The issue
> can be avoided by having the IPv6 Neighbor Discovery turned off (see
> workaround), which is the default state.
>
> Note: the neighbor discovery needs to be turned off on _ALL_ interfaces for
> this to workaround to apply (not just the connected or active interfaces).
>
> The bug is in the 'zebra' daemon (the main daemon). Deployments that do not
> run the 'zebra' daemon (e.g. only running 'bgpd') are not affected.
>
> On Linux distributions which compile Quagga with GCC -fstack-protector, the
> impact may be limited to a DoS, as the GCC inserted stack-check function
> epilogue should detect the overflow and safely abort the process if the bug
> is exploited. Otherwise, the bug may allow arbitrary code execution by a
> remote attacker.
>
> Quagga supports running as a non-root user and with lowered privileges,
> using capabilities on Linux, and this is highly encouraged. On Linux
> distributions which configure Quagga to run this way, any exploit code will
> be limited to a non-root environment, with 0 effective capabilities. The
> acquirable capabilities are limited to CAP_NET_ADMIN, CAP_NET_RAW and
> CAP_SYS_ADMIN.
>
> CVSS v3 Base Score: 9.3
>
> CVSS Equation:
> For more information on the Common Vulnerability Scoring System and to
> obtain your specific environmental score please visit:
> https://nvd.nist.gov/cvss/v3-calculator?vector=3DAV:N/AC:L/PR:N/UI:N/S:U/
> C:N/I:H/A:H/E:F/RL:X/RC:C
>
> Workarounds:
> Disable IPv6 neighbor discovery announcements on all interfaces ("ipv6 nd
> suppress-ra" configured under all interfaces). Make sure to have it
> disabled on ALL interfaces.
>
> Active exploits:
> None known in the public at this time. Internal Proof-of-Concept code
> exists.
>
> Fixed Versions:
> TBD
>
> Solution:
> Upgrade to Quagga 1.0.20161017 or upgrade to latest GIT Master version or
> apply patches located at the URL below to your source code.
>
> Quagga can be downloaded from the following location:
> http://www.nongnu.org/quagga/ or https://github.com/Quagga/quagga
>
> Patch (Commit) for security fix is at
> https://github.com/Quagga/quagga/commit/cfb1fae25f8c092e0d17073eaf7bd428ce1cd546
>
> Document Revision History:
> 1.0 22 September 2016 - Initial (internal) draft
> 1.1 18 October 2016 - CVE release version
>
> Acknowledgments:
> The issue was uncovered by David Lamparter at OpenSourceRouting.org
>
> References:
> * Do you have Questions? Questions regarding this advisory should go to
> security@quagga.net or security@opensourcerouting.org

Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

quagga-users at alexis

Nov 14, 2016, 9:20 PM

Post #9 of 12 (6285 views)

Permalink

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. 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.

Can someone who is certain please clarify? And maybe update the CVE so the sentence makes sense (and has balanced parentheses)?

Thanks.

/a
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

mwinter at opensourcerouting

Nov 15, 2016, 3:00 PM

Post #10 of 12 (6277 views)

Permalink

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.

> 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.

> 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.
>
> Can someone who is certain please clarify? And maybe update the CVE so
> the sentence makes sense (and has balanced parentheses)?

Iâ€™ll update if you can confirm that these 2 small rewrites clarify the
issue.

- Martin

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

quagga-users at alexis

Nov 16, 2016, 1:38 AM

Post #11 of 12 (6272 views)

Permalink

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-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) [ In reply to ]

quagga-users at alexis

Nov 17, 2016, 12:38 PM

Post #12 of 12 (6265 views)

Permalink

On Nov 16, 2016, at 10:05 AM, Paul Jakma <paul@jakma.org> 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-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Mailing List Archive

Attached Files:

Attached Files: