* 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.
* 'patch-1' of https://github.com/assafmo/bro:
dump_packet & dump_current_packet better detect which file is being dumped to
Fix dump_packet & dump_current_packet ignores file_name
* origin/topic/dnthayer/test-improvements:
Fix the ip-broken-header.bro test on macOS
Improve reliability of the logging rotate.bro test
Improve reliability of missing-file-initially.bro test
BIT-1929 #merged
* origin/topic/seth/dhcp-update:
Rework to the DHCP analyzer.
First step of DHCP analyzer rearchitecture.
Add .btest scripts for dhck_ack and dhcp_discover messages verifying that new options are correctly reported in dhcp.log records.
Extend DHCP protocol analyzer with new options.
BIT-1924 #merged
Additional changes:
* Removed known-hosts.bro as the only thing populating its table was
the already-removed known-hosts-and-devices.bro. So a
known_devices.log will no longer be generated.
* In dhcp-options.pac, the process_relay_agent_inf_option had a memleak
and also process_auto_proxy_config_option looked like it accessed one
byte past the end of the available bytestring, so fixed those.
It turns out that --with-openssl does not currently work because even
when the correct library is chosen, the include path ordering will
(typically) cause the system OpenSSL to be included.
Push OpenSSL header directory as the highest priority one. This probably
also makes sense since OpenSSL is/will be one of the most common
libraries that needs specific include directories.
