quagga/ospfd, branch master

ospfd: protect vs. VU#229804 (malformed Router-LSA)

2013-08-06T10:41:46+00:00

VU#229804 reports that, by injecting Router LSAs with the Advertising
Router ID different from the Link State ID, OSPF implementations can be
tricked into retaining and using invalid information.

Quagga is not vulnerable to this because it looks up Router LSAs by
(Router-ID, LS-ID) pair.  The relevant code is in ospf_lsa.c l.3140.
Note the double "id" parameter at the end.

Still, we can provide an improvement here by discarding such malformed
LSAs and providing a warning to the administrator.  While we cannot
prevent such malformed LSAs from entering the OSPF domain, we can
certainly try to limit their distribution.

cf. http://www.kb.cert.org/vuls/id/229804 for the vulnerability report.
This issue is a specification issue in the OSPF protocol that was
discovered by Dr. Gabi Nakibly.

Reported-by: CERT Coordination Center 
Signed-off-by: David Lamparter

ospfd: CVE-2013-2236, stack overrun in apiserver

2013-07-28T14:13:10+00:00

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

ospfd: fix flooding procedure

2013-04-20T04:14:27+00:00

An ospf router should accept a new maxage LSA into its lsdb if it has any
neighbors in state Exchange or Loading. ospfd would however only account
for neighbors on the same interface which does not seem to be a valid
optimization.

Signed-off-by: Christian Franke 
Signed-off-by: Joachim Nilsson 
Signed-off-by: David Lamparter

ospfd: make ospf_maxage_lsa_remover actually yield

2013-04-20T04:12:13+00:00

ospf_maxage_lsa_remover whould check whether to yield,
but run on anyway.

Signed-off-by: Christian Franke 
Signed-off-by: Joachim Nilsson 
Signed-off-by: David Lamparter

ospfd: restore nexthop IP for p2p interfaces

2013-04-09T20:38:04+00:00

commit c81ee5c... "ospfd: Optimize and improve SPF nexthop calculation"
subtly changed semantics of routes calculated over pointopoint links by
removing the nexthop IP address and instead using an ifindex route.

This breaks calculation of AS-Ext routes with a forwarding address since
in ospf_ase_complete_direct_routes() this will be hit:
    if (op->nexthop.s_addr == 0)
      op->nexthop.s_addr = nexthop.s_addr;
thus turning the route unusable by having an invalid nexthop.

Fix by restoring the nexthop IP on routes over PtP links.  This also
allows running multi-access (Ethernet) interfaces in PtP mode again.

This bug is a regression against 0.99.21 and only present in 0.99.22.

Signed-off-by: Christian Franke 
[patch description and code comments rewritten]
Acked-by: Joakim Tjernlund 
Acked-by: James Li 
Signed-off-by: David Lamparter

ospfd: fix LSA initialization for build without opaque LSA

2013-04-09T15:06:38+00:00

If configured without opaque LSA support, the old code would incorrectly
associate type 5 LSAs with an area.

Signed-off-by: Christian Franke 
Signed-off-by: David Lamparter

ospfd: Remove dup MaxAge LSA flood

2013-01-07T18:12:52+00:00

Stop additional, unnecessary flooding of MaxAge LSAs.

When a MaxAge LSA is installed, if the LSA is prematurely aged or the LSA is
not self-originated, the LSA is flushed. This results in a the LSA being
flooded a second time and in some cases flooded back to the receiver
(unless the receiver is also the advertising router). A MaxAge'd LSA has
already been flooded in ospf_flood() as part of the LSA receive processing
(ospf_ls_upd). A self-originated LSA will be flooded from the originate/refresh
routine. Thus, in the install routine, a MaxAge'd LSA only needs to be added
to the MaxAge LSA list.

Signed-off-by: Dinesh G Dutt 
Signed-off-by: Scott Feldman

ospfd: Corrected ospfd Type-4/Type-5 ls update handling

2013-01-07T18:00:00+00:00

This fix is for Type-4 LS updates handling at a ABR router where
ospf daemon is not distributing Type-4 LS updates with correct LS-Age
after learning about a ASBR router in a ospf network. Because of this
Type-5 LS updates are not learnt in ospf network.
Testing Scenario:
This can be re-produced by restarting the ospfd daemon on DUT
(mentioned in figure below)before the Hello time interval expires
for area 0.0.0.1.

 ____                       _______                       ____                    _________
|    |   area: 0.0.0.1     |       |   area: 0.0.0.0     |    |   area: 0.0.0.2  |         |
| R1 |---------------------|DUT/ABR|---------------------| R2 |------------------| R3/ASBR |
|____|     x.x.x.0/24      |_______|    y.y.y.0/64       |____|     z.z.z.0/24   |_________|

In the above setup when ospfd is restarted (imp:before the Hello interval
at R1 expires) and DUT learns about ASBR router R3 (Type-4) in the
network from R2, but this ls-update is not propagates in area
0.0.0.1. So R1 never comes to know about the ASBR router in the
network, so all the type-5 LS updates coming from R3 are not learnt
by R1. Further if we again restart ospfd daemon it starts working fine.
With the fix given this issue can be resolved.

More Discussion on this is available at:
http://www.gossamer-threads.com/lists/quagga/dev/23892

Signed-off-by: Scott Feldman

ospfd: compile warning cleanups

2013-01-07T17:59:59+00:00

A set of patches to clarify some comments as well as cleanup code that was
causing warnings.  After these patches, the code can be compiled with

-Wall -Wsign-compare -Wpointer-arith -Wbad-function-cast -Wwrite-strings
-Wmissing-prototypes -Wmissing-declarations -Wchar-subscripts -Wcast-qual
-Wextra -Wno-unused-parameter -Wno-missing-field-initializers

(what is current in trunk plus -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers).

Signed-off-by: Scott Feldman

ospfd: Update nsm_change_state to static scope, as it is not called from elsewhere

2013-01-07T17:59:57+00:00

Signed-off-by: Scott Feldman