Bugzilla – Bug 828117
VUL-0: CVE-2013-2236: quagga: local network stack overflow
Last modified: 2014-07-09 10:31:48 UTC
is public, via oss-sec CVE-2013-2236 From: David Lamparter <equinox@diac24.net> Date: Wed, 3 Jul 2013 23:14:11 +0200 Subject: [oss-security] CVE request: Quagga OSPF-API stack overrun Hi, I guess I need a CVE number for this, we've discovered a local network exploitable stack overrun in Quagga's ospfd. Reference: http://lists.quagga.net/pipermail/quagga-dev/2013-July/010621.html Cheers, -David (Quagga maintainer)
From: Charlet, Ricky Sent: Tuesday, July 02, 2013 11:09 AM To: quagga-dev at lists.quagga.net Subject: ospfd, new_msg_lsa_change_notify: looks like a buffer overflow Howdy, 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. <patch> 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); }</patch> 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.
bugbot adjusting priority
patch submitted to SUSE:SLE-9-SP3:Update:Teradata:Test, SUSE:SLE-10-SP3:Update:Test, SUSE:SLE-11-SP1:Update:Test. reassign to maintenance team.
Update released for: quagga Products: SUSE-CORE 9-SP3-TERADATA (x86_64)
Update released for: quagga, quagga-debuginfo, quagga-debugsource, quagga-devel Products: SLE-SERVER 11-SP1-TERADATA (x86_64)
Update released for: quagga, quagga-debuginfo, quagga-debugsource, quagga-devel Products: SLE-DEBUGINFO 11-SP3 (i386, ia64, ppc64, s390x, x86_64) SLE-SDK 11-SP3 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP3 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP3 (i386, x86_64)
Update released for: quagga, quagga-debuginfo, quagga-debugsource, quagga-devel Products: SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP2 (i386, x86_64)
Update released for: quagga, quagga-debuginfo, quagga-devel Products: SLE-SERVER 10-SP3-TERADATA (x86_64)
released
An update workflow for this issue was started. This issue was rated as moderate. Please submit fixed packages until 2014-07-04. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/57975
Update released for: quagga, quagga-debuginfo, quagga-devel Products: SLE-DEBUGINFO 10-SP3 (i386, s390x, x86_64) SLE-SERVER 10-SP3-LTSS (i386, s390x, x86_64)
Update released for: quagga, quagga-debuginfo, quagga-devel Products: SLE-DEBUGINFO 10-SP4 (i386, s390x, x86_64) SLE-SERVER 10-SP4-LTSS (i386, s390x, x86_64)
Update released for: quagga, quagga-debuginfo, quagga-debugsource, quagga-devel Products: SLE-DEBUGINFO 11-SP1 (i386, s390x, x86_64) SLE-SERVER 11-SP1-LTSS (i386, s390x, x86_64)
SUSE-SU-2014:0879-1: An update that fixes two vulnerabilities is now available. Category: security (moderate) Bug References: 822572,828117 CVE References: CVE-2013-0149,CVE-2013-2236 Sources used: SUSE Linux Enterprise Server 11 SP1 LTSS (src): quagga-0.99.15-0.14.11 SUSE Linux Enterprise Server 10 SP4 LTSS (src): quagga-0.99.9-14.17.12 SUSE Linux Enterprise Server 10 SP3 LTSS (src): quagga-0.99.9-14.17.12