commit f1e604425fff959032cd4c47fe0493ac2ab2fb0f Author: David Lamparter Date: Tue Jul 30 16:47:01 2013 +0200 release: 0.99.22.3 0.99.22.2 broke build on FreeBSD. It'll be mostly obliterated from history and only remain in the git history. * configure.ac: Bump to 0.99.22.3 commit d8df0b1e2dadd7409cac011da5b182b092862d89 Author: David Lamparter Date: Tue Jul 30 15:36:26 2013 +0200 lib: unconditionally include stddef.h I've used offsetof() in the previous commit to paper over the security problems in ospf_api.c. This blows the build on FreeBSD 7.0, missing offsetof(). Let's add that to zebra's generally used includes. stddef.h (and offsetof) is defined in C89 section 4.1.5 (and not deprecated/removed by any later standard). If this causes problems, the bug report should go against the host OS/compiler... Signed-off-by: David Lamparter commit 908f412e5e959e23b229537fa6e00bbf95c36813 Author: David Lamparter Date: Sun Jul 28 16:06:28 2013 +0200 release: 0.99.22.2 This fixes a minor security issue in ospfd, affecting only users of the Opaque LSA / OSPF-API. * configure.ac: Bump to 0.99.22.2 commit 3f872fe60463a931c5c766dbf8c36870c0023e88 Author: David Lamparter Date: Mon Jul 8 23:05:28 2013 +0200 ospfd: CVE-2013-2236, stack overrun in apiserver the OSPF API-server (exporting the LSDB and allowing announcement of Opaque-LSAs) writes past the end of fixed on-stack buffers. This leads to an exploitable stack overflow. For this condition to occur, the following two conditions must be true: - Quagga is configured with --enable-opaque-lsa - ospfd is started with the "-a" command line option If either of these does not hold, the relevant code is not executed and the issue does not get triggered. Since the issue occurs on receiving large LSAs (larger than 1488 bytes), it is possible for this to happen during normal operation of a network. In particular, if there is an OSPF router with a large number of interfaces, the Router-LSA of that router may exceed 1488 bytes and trigger this, leading to an ospfd crash. For an attacker to exploit this, s/he must be able to inject valid LSAs into the OSPF domain. Any best-practice protection measure (using crypto authentication, restricting OSPF to internal interfaces, packet filtering protocol 89, etc.) will prevent exploitation. On top of that, remote (not on an OSPF-speaking network segment) attackers will have difficulties bringing up the adjacency needed to inject a LSA. This patch only performs minimal changes to remove the possibility of a stack overrun. The OSPF API in general is quite ugly and needs a rewrite. Reported-by: Ricky Charlet Cc: Florian Weimer Signed-off-by: David Lamparter