[quagga-users 12476] Re: Possible OSPF issue.
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
> 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