Bug 981124 (CVE-2013-2236) - CVE-2013-2236 Quagga: OSPFD Potential remote code exec (stack based buffer overflow)
Summary: CVE-2013-2236 Quagga: OSPFD Potential remote code exec (stack based buffer ov...
Alias: CVE-2013-2236
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 981126 981127 981128 981129 981130 981131 1391918
Blocks: 981132 1386080
TreeView+ depends on / blocked
Reported: 2013-07-04 05:29 UTC by Garth Mollett
Modified: 2019-09-29 13:05 UTC (History)
6 users (show)

Fixed In Version: quagga
Doc Type: Bug Fix
Doc Text:
A stack-based buffer overflow flaw was found in the way the Quagga OSPFD daemon handled LSA (link-state advertisement) packets. A remote attacker could use this flaw to crash the ospfd daemon resulting in denial of service.
Clone Of:
Last Closed: 2017-03-21 12:42:12 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:0794 normal SHIPPED_LIVE Moderate: quagga security and bug fix update 2017-03-21 12:50:48 UTC

Description Garth Mollett 2013-07-04 05:29:36 UTC
Charlet, Ricky <ricky.charlet@hp.com> reports:


I'm gonna describe an ospfd bug that happened to me and a proposed patch. But at the top of this email, I want to say that I'm really not familiar enough with this code to suggest that this patch is "the right thing".  I'm looking for some double checking here. On the other hand, I think it is important. This is an on-stack, buffer overflow susceptible to input from the network in code that implements, what seems to me, to be a very minor feature.

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.

Index: ospfd/ospf_api.c
--- ospfd/ospf_api.c    (revision 10875)
+++ ospfd/ospf_api.c    (working copy)
@@ -639,7 +639,7 @@
   nmsg->area_id = area_id;
   nmsg->is_self_originated = is_self_originated;
   memset (&nmsg->pad, 0, sizeof (nmsg->pad));
-  memcpy (&nmsg->data, data, ntohs (data->length));
+  memcpy (&nmsg->data, data, sizeof(struct lsa_header));

   return msg_new (msgtype, nmsg, seqnum, len);

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?

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.

Comment 1 Garth Mollett 2013-07-04 05:36:12 UTC
Created quagga tracking bugs for this issue:

Affects: fedora-all [bug 981126]

Comment 3 Garth Mollett 2013-07-04 05:44:58 UTC
Please note: The above patch, while preventing the memcpy overflow may not be a complete fix as len may still be used from the wire in other places without sanity checking.

Comment 12 Florian Weimer 2013-07-04 13:19:45 UTC
I proposed another fix: <http://lists.quagga.net/pipermail/quagga-dev/2013-July/010625.html>

Comment 18 Huzaifa S. Sidhpurwala 2013-09-05 09:27:29 UTC


Comment 21 errata-xmlrpc 2017-03-21 11:58:16 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2017:0794 https://rhn.redhat.com/errata/RHSA-2017-0794.html

Note You need to log in before you can comment on or make changes to this bug.