Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 475706 (CVE-2013-2236) - <net-misc/quagga- OSPFD Potential remote code exec (stack based buffer overflow) (CVE-2013-2236)
Summary: <net-misc/quagga- OSPFD Potential remote code exec (stack based buf...
Alias: CVE-2013-2236
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: B2 [glsa]
Depends on:
Reported: 2013-07-04 08:27 UTC by Agostino Sarubbo
Modified: 2013-10-10 12:08 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2013-07-04 08:27:10 UTC
From ${URL} :

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?

@maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
Comment 1 Sergey Popov gentoo-dev 2013-09-24 11:30:11 UTC
This is fixed in, working on ebuild now...
Comment 2 Sergey Popov gentoo-dev 2013-09-24 11:55:14 UTC
Ok, is in tree and it is ready for stabilization

Arches, please test and mark stable =net-misc/quagga-

Target keywords: alpha amd64 arm hppa ppc sparc x86

@s390: since you are considered unstable only arch, please drop keywords to ~s390
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2013-09-24 14:32:06 UTC
Stable for HPPA.
Comment 4 Agostino Sarubbo gentoo-dev 2013-09-27 17:20:54 UTC
arm stable
Comment 5 Chema Alonso Josa (RETIRED) gentoo-dev 2013-09-28 16:31:16 UTC
amd64 stable
Comment 6 Agostino Sarubbo gentoo-dev 2013-09-28 20:49:03 UTC
S390 is not anymore a stable arch, removing it from the cc list
Comment 7 Agostino Sarubbo gentoo-dev 2013-10-06 07:52:09 UTC
x86 stable
Comment 8 Agostino Sarubbo gentoo-dev 2013-10-06 15:20:53 UTC
alpha stable
Comment 9 Agostino Sarubbo gentoo-dev 2013-10-07 19:31:04 UTC
ppc stable
Comment 10 Agostino Sarubbo gentoo-dev 2013-10-09 17:10:47 UTC
sparc stable
Comment 11 Chris Reffett (RETIRED) gentoo-dev Security 2013-10-10 03:10:19 UTC
GLSA request has been filed.
Comment 12 Chris Reffett (RETIRED) gentoo-dev Security 2013-10-10 03:11:25 UTC
Cleanup please.
Comment 13 Sergey Popov gentoo-dev 2013-10-10 06:30:47 UTC
+  10 Oct 2013; Sergey Popov <> -quagga-0.99.20.ebuild,
+  -quagga-0.99.20-r1.ebuild, -quagga-0.99.21.ebuild,
+  -files/quagga-0.99.21-fix-no-ipv6.patch, -quagga-0.99.22.ebuild,
+  -quagga-, -files/quagga-link-libcap.patch,
+  -files/quagga-services.init.2, -files/zebra.init.3:
+  Security cleanup wrt bug #475706
Comment 14 GLSAMaker/CVETool Bot gentoo-dev 2013-10-10 12:08:08 UTC
This issue was resolved and addressed in
 GLSA 201310-08 at
by GLSA coordinator Sean Amoss (ackle).