It was possibly never updated for newer Analyzer API changes, as simply
attaching the NCP analyzer to a connection would result in null pointer
derefernces and also support analyzers were not attached.
* origin/topic/jsiwek/binpac-fixes:
Update test baseline for binpac changes
Update test baseline for optimized binpac static-size array parsing
Fixes for MySQL and SMB protocol parsers
BIT-1829: add unit test for modbus parser issue
* MySQL: the parser for this was generally broken (not following
the specification well) and needed many changes. One addition is a
new "mysql_result_row" event that provides access to the results of
queries.
* SMB: the spec seems to explitly call out the omission of the
PrimaryDomain field on SMB_COM_SESSION_SETUP_ANDX responses (and I
don't see that field in pcaps either), so this may have just been a
typo that used to work fine in the past only due to faulty array
parsing behavior in binpac.
ARP_Analyzer::NextPacket() incorrectly assumed that the MAC source
address was at data+6 (which is fine for classical ARP over Ethernet
frames but incorrect for ARP over Wi-Fi for example) and the
destination was at data.
Use pkt->l2_src and pkt->l2_dst instead, set by Packet::ProcessLayer2().
This is a fairly straightforward change. Previously, users had no
control over whether this script was loaded. By relocating it to
policy, users can now choose whether or not this is necessary
functionality without modifying core Bro scripts.
Since the function was never used to check for anything other than
equality, I've changed it to return a bool, otherwise the changes to
its implementation are based on a patch submitted by Jeffrey Bencteux:
Function was comparing two strings based on the length of a user
provided string which could lead to evasions. Any prefix of the static
string could pass conditions where strcasecmp_n was used. Comparison
is now based on the static string length and lengths are checked
before calling strncasecmp.
According to RFC 7230, Transfer-Encoding was added in HTTP/1.1. Such a
header in a HTTP/1.0 message should be ignored. Interpreting it can be
harmful when sending a HTTP/1.0 message because the parser would
indefinitely wait for a chunk size instead of parsing the message's
body as non-chunked, leading to a HTTP content evasion.
In the case where no Content-Length header is seen, the content_length
value still should be set based upon the range (same as it would
have been before the patch).
Partial content bytes range length value and content length value
should not be stored in the same variable. An attacker could override
a given Content-Length or Content-Range with a smaller value to
evade HTTP content.
RFC 7230 section 4.2.3 states that:
"A recipient SHOULD consider 'x-gzip' to be equivalent to 'gzip'"
This could lead to evasions as an attacker could use:
Content-Encoding: x-gzip
To bypass Bro's decompression.
