[quagga-users 12476] Re: Possible OSPF issue.

mike mike-quagga at tiedyenetworks.com
Sat Sep 17 19:30:18 IST 2011

On 09/14/2011 05:35 AM, Paul Jakma wrote:
> On Tue, 13 Sep 2011, mike wrote:
>> throwing both structured and unstructured randomized noise at the 
>> deamons on their routing protocol ports in order to help shake out 
>> issues in error handling and boundary checking.
> Kunihiro (presumably) made the wise decision to implement a 
> bounds-checking stream buffer abstraction (lib/stream) and have 
> daemons do their I/O through that. Generally ospfd makes good use of 
> it (SNMP being a notable exception iirc), as does bgpd, somewhat. So 
> error-prone parsing code often is insulated somewhat from the network 
> by that separate bounds-checking layer.
> So when we have problems with network-triggered crashes, they're 
> usually because of deliberate asserts, which is still a DoS problem 
> but at least not usually a host-compromise security problem.
> There are bugs to be fixed in the current parsing code. Also, the 
> lib/stream also is actually /too/ eager to assert at the moment - 
> which needs to be fixed if parsing code is to do better at 
> error-recovery.
> In the longer-term, parsing code really needs to be regularised - get 
> away from hand-made parsers that always have errors, and instead 
> implement a suitable language and compiler.

Understood, but my suggestion was both structured and unstructured 
noise, because I have seen first hand (and reported) issues with 
corruption that wound up crashing ospfd or causing it to assume bad 
state/out of sync with neighbors. For example, I would hope ospfd drops 
at the earliest opportunity, any packet received on a segment with md5 
authentication that did not match as per your above. But if after 
validation of the hash, if that neighbor is handing out ls updates that 
are themselves complete nonsense or out of bounds or invalid in that 
area or too many or otherwise a complete lie (but syntatically correct), 
thats what the fuzzer would do and thats what I am less sure about if 
ospfd actually handles well. I am only asserting that you can still have 
that layer of bounds checking mentioned above, but still have an opening 
to feed nonsense to the deamons which cause them to go insane or 
malfunction in subtle ways.


More information about the Quagga-users mailing list