[Bro-Dev] [Auto] Merge Status
Open Merge Requests === IDComponentReporter Assignee Updated For VersionPrioritySummary --- --- -- - -- -- BIT-1045 [1] Bro Vlad Grigorescu Robin Sommer 2013-10-10 - Normal Review usage of InternalError when parsing network traffic [1] BIT-1045 https://bro-tracker.atlassian.net/browse/BIT-1045 ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f)
On Thu, Oct 10, 2013 at 22:29 -0700, Daniel Thayer wrote: Add README files for most Bro frameworks I'm forgetting if it works to put these as comments into the __load__.bro files? If so, that would be an alternative as it avoids having a new file in each directory (the README's are easier to find though when looking at the scripts directly, so I'm a bit torn). Robin -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f)
On 10/11/2013 09:55 AM, Robin Sommer wrote: On Thu, Oct 10, 2013 at 22:29 -0700, Daniel Thayer wrote: Add README files for most Bro frameworks I'm forgetting if it works to put these as comments into the __load__.bro files? If so, that would be an alternative as it avoids having a new file in each directory (the README's are easier to find though when looking at the scripts directly, so I'm a bit torn). Robin I'm not aware of a way to do that from the __load__.bro file. ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f)
On Oct 11, 2013, at 10:55 AM, Robin Sommer ro...@icir.org wrote: I'm forgetting if it works to put these as comments into the __load__.bro files? I'm inclined to say having README files would be better since ultimately all of this is just leading toward creating a more formalized module style and having READMEs in the directory would probably be good form in general. .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro.org/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f)
On Fri, Oct 11, 2013 at 11:53 -0400, you wrote: ultimately all of this is just leading toward creating a more formalized module style and having READMEs in the directory would probably be good form in general. Ah, good point. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files
[ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14209#comment-14209 ] Jon Siwek commented on BIT-1089: Is it ok to always install a sample plus the real version (if it doesn't already exist) that's meant to be used/modified? Or do you need a mode where just the sample config file is the only thing that Bro can ever install? Please install sample/example broctl .cfg files --- Key: BIT-1089 URL: https://bro-tracker.atlassian.net/browse/BIT-1089 Project: Bro Issue Tracker Issue Type: Improvement Components: BroControl Reporter: leres Priority: Low -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files
[ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14210#comment-14210 ] leres commented on BIT-1089: The current behavior where it only installs a .cfg if none exist is totally fine. What I'm asking for is that either by default or by turning on a cmake argument it would install sample configs. Please install sample/example broctl .cfg files --- Key: BIT-1089 URL: https://bro-tracker.atlassian.net/browse/BIT-1089 Project: Bro Issue Tracker Issue Type: Improvement Components: BroControl Reporter: leres Priority: Low -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic
[ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211#comment-14211 ] Robin Sommer commented on BIT-1045: --- Going through, I see number of places where I'd argue it's actually a programming/logic error that's not something that can be directly/just triggered by crafted network traffic. Examples are the RefCnt() checks in ~ConnectionTimer() and the indent_level check in ODesc. I'm inclined to leave them as they were, with the argument being that those kinds of error actually *are* best to trigger an abort. E.g, if the reference counting goes awry, pretty much all bets are off anyways, and I'd rather have Bro terminate than trying to continue. So I think the guideline should be avoiding internal errors that happen *directly* because of broken network input; not because of (for lack of a better term) infrastructure problems in other parts of Bro. (Although I'm sure as I go further, I'll find more cases where that definition is ambiguous as well.) What's your opinion on cases like the above? What I could do is go through your diffs and adapt with the above in mind, and then we can do another iteration and see if/where we agree. 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 Assignee: Robin Sommer 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 was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files
On Fri, Oct 11, 2013 at 13:37 -0500, you wrote: The current behavior where it only installs a .cfg if none exist is totally fine. What I'm asking for is that either by default or by turning on a cmake argument it would install sample configs. I'm still not sure I'm really getting the issue but I have an idea: would a separate make target install-sample-configs work that unconditionally puts the samples in place? That's something we could still add to 2.2 even at this point as it doesn't interfere with anything else. Robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files
[ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212#comment-14212 ] Robin Sommer commented on BIT-1089: --- I'm still not sure I'm really getting the issue but I have an idea: would a separate make target install-sample-configs work that unconditionally puts the samples in place? That's something we could still add to 2.2 even at this point as it doesn't interfere with anything else. Robin Please install sample/example broctl .cfg files --- Key: BIT-1089 URL: https://bro-tracker.atlassian.net/browse/BIT-1089 Project: Bro Issue Tracker Issue Type: Improvement Components: BroControl Reporter: leres Priority: Low -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev