summaryrefslogtreecommitdiff
path: root/ospf6d/ospf6_top.c
diff options
context:
space:
mode:
authorDavid Lamparter <equinox@opensourcerouting.org>2013-07-08 23:05:28 +0200
committerDavid Lamparter <equinox@opensourcerouting.org>2013-07-28 16:13:10 +0200
commitc51443f4aa6b7f0b0d6ad5409ad7d4b215092443 (patch)
treeeffbe8695f7bfd0ed5261b08d5beddb66cceed64 /ospf6d/ospf6_top.c
parent78116ab6e1524815910658898620776ae5fd4d18 (diff)
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 <ricky.charlet@hp.com> Cc: Florian Weimer <fweimer@redhat.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Diffstat (limited to 'ospf6d/ospf6_top.c')
0 files changed, 0 insertions, 0 deletions