]> git.proxmox.com Git - mirror_frr.git/commit
ospfd: CVE-2013-2236, stack overrun in apiserver
authorDavid Lamparter <equinox@opensourcerouting.org>
Mon, 8 Jul 2013 21:05:28 +0000 (23:05 +0200)
committerDavid Lamparter <equinox@opensourcerouting.org>
Sun, 28 Jul 2013 14:13:10 +0000 (16:13 +0200)
commitc51443f4aa6b7f0b0d6ad5409ad7d4b215092443
treeeffbe8695f7bfd0ed5261b08d5beddb66cceed64
parent78116ab6e1524815910658898620776ae5fd4d18
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>
ospfd/ospf_api.c