[quagga-users 14443] Quagga 1.0.20161017 released: IPv6 ND RA / SLAC and BGP MRT security fixes

Paul Jakma paul at jakma.org
Mon Oct 17 17:39:07 BST 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Quagga 1.0.20161017 has been released. This is a security release for 
zebra IPv6 SLAC/router-advertisements and BGP MRT dumps, fixing:

* CVE-2016-1245: Stack buffer overflow in zebra on Linux, if IPv6  and 
IPv6 neighbour discovery router advertisements (SLAC) are enabled ("no 
ipv6 nd suppress-ra"). Thanks to David Lamparter for reporting and 
fixing this issue.

* CVE-2016-4049: A controlled crash, leading to a DoS, in the BGP MRT 
route dumping code, if a prefix had too many entries to write to one 
record. Thanks to Evgeny Uskov for reporting and fixing this issue.

Any users using these functionalities should upgrade. Note that a number 
of distributions have already issued updates for the BGP MRT issue 
(CVE-2016-4049) as updates to  the previous 1.0.2060315 release.

This 1.0.20161017 release is available at:

http://download.savannah.gnu.org/releases/quagga/

This release also includes 4 other fixes for undefined behaviour that 
may have security implications, for BGP, IS-IS and OSPFv3.

The full changelog is as follows:

commit ba3859c5121608437116bcc24d475bff95224aff
Author: Christian Franke <nobody at nowhere.ws>
Date:   Tue Jun 14 20:07:06 2016 +0200

     isisd: Fix size of malloc

     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Acked-by: Donald Sharp <sharpd at cumulusnetworks.com>

commit f7144b2d404476e294a61bfa5a364ab0581939f7
Author: Christian Franke <nobody at nowhere.ws>
Date:   Tue Jun 14 20:07:05 2016 +0200

     isisd: fix an error that was probably a result of copypasting

     The code should check for the existance of the correct list prior to
     accessing it.

     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Acked-by: Donald Sharp <sharpd at cumulusnetworks.com>

commit 21dd85d4db7ea4e9e716f0f662c35f0f5b745dc6
Author: Christian Franke <nobody at nowhere.ws>
Date:   Tue Jun 14 20:07:04 2016 +0200

     ospf6d: fix off-by-one on display of spf reasons

     The loop should only iterate to array_size - 1.

     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Acked-by: Donald Sharp <sharpd at cumulusnetworks.com>

commit 85e822164aeaffb9b102628c10996d776f97be80
Author: Christian Franke <nobody at nowhere.ws>
Date:   Tue Jun 14 20:07:03 2016 +0200

     ospf6d: don't access nexthops out of bounds

     Given that the && is evaluated lazily from left to right,
     i < OSPF6_MULTI_PATH_LIMIT should be checked prior to calling
     ospf6_nexthop_is_set on the array element, not the other way around.

     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Acked-by: Donald Sharp <sharpd at cumulusnetworks.com>

commit 7df96b19b976c99966f7f9669e09c2a240278b88
Author: Christian Franke <nobody at nowhere.ws>
Date:   Tue Jun 14 20:07:00 2016 +0200

     bgpd: fix off-by-one in attribute flags handling

     bgp_attr_flag_invalid can access beyond the last element of attr_flags_values.
     Fix this by initializing attr_flags_values_max to the correct value.

     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Signed-off-by: Christian Franke <chris at opensourcerouting.org>
     Acked-by: Donald Sharp <sharpd at cumulusnetworks.com>

commit 23ed2c2fb49b8a15ad125b16278e535719d64e7d
Author: David Lamparter <equinox at opensourcerouting.org>
Date:   Wed Aug 31 13:31:16 2016 +0200

     zebra: stack overrun in IPv6 RA receive code (CVE-2016-1245)

     The IPv6 RA code also receives ICMPv6 RS and RA messages.
     Unfortunately, by bad coding practice, the buffer size specified on
     receiving such messages mixed up 2 constants that in fact have
     different values.

     The code itself has:
      #define RTADV_MSG_SIZE 4096
     While BUFSIZ is system-dependent, in my case (x86_64 glibc):
      /usr/include/_G_config.h:#define _G_BUFSIZ 8192
      /usr/include/libio.h:#define _IO_BUFSIZ _G_BUFSIZ
      /usr/include/stdio.h:# define BUFSIZ _IO_BUFSIZ

     FreeBSD, OpenBSD, NetBSD and Illumos are not affected, since all of them
     have BUFSIZ == 1024.

     As the latter is passed to the kernel on recvmsg(), it's possible to
     overwrite 4kB of stack -- with ICMPv6 packets that can be globally sent
     to any of the system's addresses (using fragmentation to get to 8k).

     (The socket has filters installed limiting this to RS and RA packets,
     but does not have a filter for source address or TTL.)

     Issue discovered by trying to test other stuff, which randomly caused
     the stack to be smaller than 8kB in that code location, which then
     causes the kernel to report EFAULT (Bad address).

     Signed-off-by: David Lamparter <equinox at opensourcerouting.org>
     Reviewed-by: Donald Sharp <sharpd at cumulusnetworks.com>

commit 7da28be5bafb31af75f796abb04aa1d09276d66d
Author: Evgeny Uskov <eu at qrator.net>
Date:   Wed Jan 13 13:58:00 2016 +0300

     bgpd: Fix buffer overflow error in bgp_dump_routes_func

     Now if the number of entries for some prefix is too large, multiple
     TABLE_DUMP_V2 records are created.  In the previous version in such
     situation bgpd crashed with SIGABRT.

regards,
- -- 
Paul Jakma | paul at jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJMBAEBCAA2BQJYBP6rLxpodHRwczovL3d3dy5qYWttYS5vcmcvfnBhdWwvcGdw
X3BvbGljeS0xLjEudHh0AAoJEOFGbL/NtBuaDRoP+wc4841jmEm1SNNLCVnDeWJd
TQRaei/eazd1kIVwPHv71wdXxn1jHf17px98+6Cf2XzegGnrS+KM6J4koww9+g49
XhpJ6+SVGfuWCNeWVx9vf9cNiTPiILk71ko3kF6nJ3EQOd7D284XaxjbpfPabX33
1+QC/qM/U2J3r0Y0aenm1nENyscmJ+303IW9wGj3/gQCU6LE4NFQiON6m+cGm2sE
CiV4YzUKjGYkR3oDG+PEvNVT+jnkzW7DVwFcYs1iNTvrbmBITpuOiWUla+xmLzTN
xwWYdw/4V0nD0OReHjnlH5GnCTJgos7Je4v+Dj6NAMOWX8JHrpYTgPpJtF8tJ/kP
4Y9xi5fga/GeTrx19z+Lc1D89E7qAitgjfsTYogCwn5KgZ6anx11CZXRJFX+JcAK
gZ7Edj5Z6G1d6VYZGJjtDir8rNavrnsRoe1XLjrNLSFDSomItxK5YsrqDWlH3/KC
fnZ1jHIjbS3VZZ2Wd0kVethUMwd118373KUiELj8HJwMDBB0Kf1TtOtRFmtWIsEs
em+C2jmWmk/tsy/MJWUMuLZAtLosAN8cE5QkR6XSL7Co33ycpRqXOi21DdbS+KeE
P+SHxDRIo2g0Zve2uScpPJuNIm015/FBXgEEPbR/Fkm5rXBbsMj9uHO5ZiCIzMJi
OAoXIXoDBtOx0Ll3RQDD
=xL0M
-----END PGP SIGNATURE-----



More information about the Quagga-users mailing list