[quagga-dev 10599] Re: [PATCH] ospfd: CVE-2013-2236, stack overrun in apiserver

Florian Weimer fweimer at redhat.com
Mon Jul 15 14:01:20 BST 2013


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.

> 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.

-- 
Florian Weimer / Red Hat Product Security Team




More information about the Quagga-dev mailing list