[quagga-dev 10569] Re: ospfd, new_msg_lsa_change_notify: looks like a buffer overflow

David Lamparter equinox at opensourcerouting.org
Wed Jul 3 14:22:08 BST 2013

Hi Ricky,

it indeed looks like you found a possibly exploitable buffer overflow.
I'm looking into it and there will probably be a out in a few
days (which needs to be done anyway due to VU#229804).

On Tue, Jul 02, 2013 at 06:10:31PM +0000, Charlet, Ricky wrote:
> [...]
> I setup a network that, upon a single network event, sent over router
> LSAs representing 150 networks. The actual traffic broke down into
> about 100 ls-update packets, many of which are len=1480, and some of
> which are ip-fragmented. The ls-updates tend to grow in size. The
> largest (re-assembled) one was the last one at 1840 bytes.
> While processing the received LSAs, we crash with  gdb backtrace
> points to memcpy called from new_msg_lsa_change_notify. By code
> review, I see that we memcpy into a buffer with a length we learned
> from the input, not governed by the length of the available buffer. In
> my patch, I suggest that we govern the memcpy by the length of the
> available buffer.

That would indeed address the issue, however I'd like to look into
dynamically allocating the buffer as an alternative.  Though for obvious
reasons, that's only useful if the remainder of the code handles large
packets well...

> <patch>
> +++ ospfd/ospf_api.c    (working copy)
> -  memcpy (&nmsg->data, data, ntohs (data->length));
> +  memcpy (&nmsg->data, data, sizeof(struct lsa_header));
> I tested the above, passing in the same large router-lsa's and it
> survives/passes.
> Sssooo.... I'm not one to pretend I understand what 'clients' might be
> interested in this lsa-update message. I looked at the ospfclient.c:
> lsa_update_callback() and it apparently does not care about anything
> beyond the header.  Certianly, in our implementation, we have no
> clients at all listening for these messages.   Is it apprpriate to
> trunkate this ls-update message to the header only, or should a
> solution be built for passing arbitrarily large messages to clients?

"Clients" in this case are things like traffic engineering protocols or
high availability stuff.  Quagga's OSPF API allows them to read the LSDB
and get notified on updates.

> Additionally, how about the code that is sending the ls-updates?  I
> did not look into it myself. But we may be a poor citizen if we are
> sending ls-updates which need to be reassembled into large buffers.

Well, OSPFv2 explicitly relies on IP fragmentation to carry large LSAs.
This happening as in your case was designed into the protocol...  for
reference, Cisco has some experiences with this too:
(Not directly related but explains OSPF packet sizing vs. MTU)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: Digital signature
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130703/b207d607/attachment-0001.sig>

More information about the Quagga-dev mailing list