[Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic

Vern Paxson (JIRA) jira at bro-tracker.atlassian.net
Mon Jul 29 20:10:06 PDT 2013

    [ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401#comment-13401 ] 

Vern Paxson commented on BIT-1045:

In line with what you frame, the history behind these is that they're meant
to reflect should-never-happen situations; not "weird" activity, but apparent
internal inconsistencies in Bro's processing/execution.  So they don't really
fit with the notion of "weird".  (Of course it's definitely possible there's
some mission-creep and InternalError is misused when Weird really is the
right notion.)

That said, for sure I agree that we don't want to give adversaries a way
to tickle a Bro crash.  So ideally the solution here would be to come up
with something similar to the weird/notice framework, but that expicitly
captures the notion that Bro-is-confused rather than


> Review usage of InternalError when parsing network traffic
> ----------------------------------------------------------
>                 Key: BIT-1045
>                 URL: https://bro-tracker.atlassian.net/browse/BIT-1045
>             Project: Bro Issue Tracker
>          Issue Type: Task
>          Components: Bro
>    Affects Versions: git/master, 2.1
>            Reporter: Vlad Grigorescu
> Creating issue for tracking purposes.
> Reporter->InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a "packet of death," which could stop Bro.
> I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError:
> src/Sessions.cc:		reporter->InternalError("Bad IP protocol version in DoNextInnerPacket");
> src/Sessions.cc:		reporter->InternalError("fragment block not in dictionary");
> src/Sessions.cc:		reporter->InternalError("fragment block missing");
> src/Sessions.cc:			reporter->InternalError("unknown transport protocol");
> src/Frag.cc:		reporter->InternalError("bad IP version in fragment reassembly");
> src/IP.cc:		reporter->InternalError("IPv6_HdrChain::Init with truncated IP header");
> src/IP.cc:			reporter->InternalError("IPv6_Hdr_Chain bad header %d", type);
> src/IP.h:			reporter->InternalError("bad IP version in IP_Hdr ctor");
> src/RSH.cc:		reporter->InternalError("multiple rsh client names");
> src/RSH.cc:		reporter->InternalError("multiple rsh initial client names");
> src/POP3.cc:		reporter->InternalError("command not known");
> src/Rlogin.cc:		reporter->InternalError("multiple rlogin client names");
> src/ICMP.cc:			reporter->InternalError("unexpected IP proto in ICMP analyzer: %d",
> src/ICMP.cc:		reporter->InternalError("unexpected next protocol in ICMP::DeliverPacket()");
> src/SMB.cc:		reporter->InternalError("command mismatch for ParseTransaction");
> src/HTTP.cc:		reporter->InternalError("unrecognized HTTP message event");
> src/HTTP.cc:		reporter->InternalError("HTTP ParseRequest failed");
> src/DPM.cc:		reporter->InternalError("unknown protocol");
> src/RPC.cc:		reporter->InternalError("RPC underflow");
> src/RPC.cc:			reporter->InternalError("RPC resync: skipping over data failed");
> src/RPC.cc:					reporter->InternalError("inconsistent RPC record marker extraction");

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

More information about the bro-dev mailing list