[quagga-dev 10601] Re: [PATCH] ospfd: CVE-2013-2236, stack overrun in apiserver
equinox at opensourcerouting.org
Mon Jul 15 14:23:03 BST 2013
On Mon, Jul 15, 2013 at 03:01:20PM +0200, Florian Weimer wrote:
> On 07/15/2013 02:45 PM, David Lamparter wrote:
> >> I'm worried that this leaves data->length inconsistent with the outer
> >> PDU length. This might confuse further processing.
> > Yes, I understand your concern. Let me explain why I don't believe this
> > is an issue.
> Thanks for your explanation.
> > Essentially, the OSPF API is a fringe feature to begin with. I'm not
> > acutely aware of _any_ currently-maintained client using the interface
> > at all. I checked Debian, Gentoo and FreeBSD - none of these enable the
> > OSPF API by default.
> We enable it in Fedora and downstream, perhaps even for the reason you
> mentioned. :-/
> I've filed bugs requesting that this feature will be disabled in future
> versions. I agree that with this background, your patch makes sense.
I don't see the "-a" command line option to ospfd anywhere in Fedora
build stuff... (apparently, the init scripts come from Quagga git's
Just to reiterate: these code fragments only get called when -a is
given on ospfd's command line. Without the option, there is no issue.
> > To make the OSPF API really usable, it needs to support 64k LSAs. The
> > simplest thing to do is probably using the stream_* functions. However,
> > due to the "fringeness" of the feature, I think this is a good place to
> > experiment with possible future new-IPC methods like protobuf.
> D-Bus (the wire format and perhaps even the entire stack) would be a
> candidate as well.
Not sure if D-Bus is suitable. For one thing, Quagga needs to run on
OpenWRT and the likes, with minimum possible footprint. Also, the
overhead incurred by D-Bus may be too large. A large deployment needs
to handle tens of thousands of LSAs, with full sync on client startup
and push on change. (Thinking of the entire stack here, AFAIK the wire
format itself is not split out for separate use?)
A netlink lookalike would be an alternate possibility, especially since
we need it for kernel comms anyway. But that doesn't have the advantage
of neat automatic glue code to other languages.
I actually considered SUNRPC as well, but integrating that into an
event loop is complicated and it doesn't map well to other languages
More information about the Quagga-dev