The RFB analyzer's state machine did not foresee that a server could
send two subsequent messages in one packet. This would result in the
error. Patch by Martin van Hensbergen.
BIT-1611 #merged
* origin/topic/seth/remove-unescaped_special_char-weird:
Add urldecoding for the unofficial %u00AE style of encoding.
Remove the unescaped_special_char HTTP weird.
Instead of creating the debug.log immediately when bro starts,
now it is created only after the debug streams are enabled.
This avoids having an empty log being created when it shouldn't be,
in usages such as "bro -h", "bro -v", or "bro -B help" (and also
when using broctl, which needs to run "bro -v").
The latter is thread-safe, but a GNU addition which does not exist on
OS-X. Since the function only is called in the main thread, it should
not matter if it is or is not threadsafe.
The link-layer addresses are now part of the connection endpoints
following the originator-responder-pattern. The addresses are printed
with leading zeros. Additionally link-layer addresses are also extracted
for 802.11 plus RadioTap.
The ascii reader now accepts \r\n newlines without complaining.
Furthermore, the reader was slightly rewritten in a more c++11-y way,
removing all raw pointers from the class.
Addresses BIT-1198
Intel notices are identified by a direction independent 3-tuple
(indicator, originator IP, responder IP). This allows notice
suppression. Additionally service and intel source are added to the
notice mail.
forgotten messages are only logged on the manager (or standalone host)
now. Logs are not written by default anymore when Bro encounters traffic
that should have been blocked.
This weird points out a lot of benign stuff and it would
be easily reimplemented in a Bro script. This commit
also makes the minor change to update the reserved and
unreserved characters from a newer from of the URI RFC.
This commit rewrites catch and release, fixing issues with it and making
it fully cluster capable. A dedicated netcontrol_catch_release.log is
also added.
This is not quite done yet; a few more log messages are missing. There
should hopefully not be many big issues left.
I was hoping to report this right at startup through a static check
but turns out we don't have the right machinery in place for that.
That would need to be done after the AST has been finalized, but our
AST traversal code can't iterate over types. So instead I've changed
this so that it's still being reported at runtime but at least
doesn't crash Bro anymore.
Closes BIT-1597.
This introduces two new events, NetControl::rule_new and
NetControl::rule_destroyed, which are raised when rules are first added
and then deleted from the internal state tracking.
* origin/topic/johanna/fix-analyzer-addition:
DTLS: Use magix constant from rfc5389 for stun detection.
DTLS: Fix binpac bug with DTLSv1.2 client hellos
Forgot to remove debug output.
DTLS: Fix interaction with STUN
Fix the way that child analyzers are added.
BIT-1604 #merged
Now the DTLS analyzer cleanly skips all STUN messages; no warnings
should be logged to dpd.log and parsing should work flawlessly with
intermixed STUN messages.
Bro contains functionality to add child analyzers delayed, so that an
just added analyzer does not influence the list of current analyzers
(which, in some combinations of mostly UDP and traffic replay by PIA can
lead to duplicate packets sent to the analyzer).
Sadly, this feature was broken sometime in the past, leading to the
aforementioned duplicate packets. Re-enabling this also necessitated
some changes in the analyzer manager, which immediately timed out all
connections when that feature was re-enabled.
There currently is no testcase (this is a bit hard to trigger); however,
I will add one with a later fix for DTLS.
Turns out the code implementing them went missing with the recent
merge of the stats changes.
For peer status, I removed most of the numbers that the code used to
return because (1) we don't have access to that data anymore, and (2)
even in 2.4 the numbers returned already didn't make sense (because
they were global values, not per peer). We could consider just
removing the peer_status command at all.
This seems to be a non-standardized microsoft extension that, besides
having a different name, works pretty much the same as StartTLS. We just
treat it as such.
I tested this against provided traffic and it works; I do not have
traffic I can share for a testcase.
