When a specific component is requested through its tag or name, one
can now have the component manager transparently return a different
one that has been registered to replace the original one. We limit
this to disabled components to avoid unnecessary confusion. That also
means that remappings are currently only supported for analyzers
(because other types of components cannot be disabled for now, per the
previous change).
The different analyzers types all had their own methods for
enabling/disabling their availability. This change abstracts that into
a new API inside their base class (`plugin::Component`) so that they
can be toggled in a unified way.
In principle, other types of components could/should use this as well
now, so that, e.g., an input reader's availability could be toggled at
runtime. The code doesn't make that broader change for now because it
would requires a series of changes wherever these other component
types are being used. However, that means that one now could try
toggling some other component through the new API without that having
any effect. To catch that, there's a runtime check in place that turns
any such attempt into an internal error.
Relying only on the IP-header-provided length could violate buffer boundaries in
the endpoints' rule matching. This change mirrors what we do in UDP and TCP.
Resolves#3671
This is meant to be used for a new 'X' code in the history in scenarios when
packets are knowingly not processed or an unexpected unknown situation
is recognized.
Usually, these situations are currently reported via weirds or analyzer violations,
but being able to include it in the history field allows them to be more visible.
Will be used for exceeding tunnel depths first.
While it seems interesting functionality, this hasn't been documented,
maintained or knowingly leveraged for many years.
There are various other approaches today, too:
* We track the number of event handler invocations regardless of
profiling. It's possible to approximate a load_sample event by
comparing the result of two get_event_stats() calls. Or, visualize
the corresponding counters in a Prometheus setup to get an idea of
event/s broken down by event names.
* HookCallFunction() allows to intercept script execution, including
measuring the time execution takes.
* The global call_stack and g_frame_stack can be used from plugins
(and even external processes) to walk the Zeek script stack at certain
points to implement a sampling profiler.
* USDT probes or more plugin hooks will likely be preferred over Zeek
builtin functionality in the future.
Relates to #3458
These can be significant if a lot of new connections and or events
are created for which an existing conn val needs updating and otherwise
things are very fast.
Packet::Init() is not so cheap as one might think: It computes a
timestamp from { 0, 0 } using double division. Just avoid this
by not initializing an empty Packet.
For deeply encapsulated connections (think AWS traffic mirroring format
like IP,UDP,GENEVE,IP,UDP,VXLAN,ETH,IP,TCP), the Dispatcher::Lookup()
method is fairly visible in profiles when running in bare mode.
This changes the Analyzer::Lookup() and Dispatcher::Lookup() return value
breaking the API in favor of the performance improvement.
Relates to zeek/zeek#3379.
This largely copies over Spicy's `.clang-format` configuration file. The
one place where we deviate is header include order since Zeek depends on
headers being included in a certain order.
The fuzzer generated input where data length left was 14 and the amsdu_len
field set to 14. That caused buffer overread due not taking into account
the amsdu header length of 14.
Using pcaps from https://interop.seemann.io/ as samples for QUIC protocol
data didn't produce a conn.log for the contained data. `tcpdump -r`
and Wireshark do show the contained IP/UDP packets. Teach Zeek how
to handle link type DLT_PPP 0x09 using a new PPP analyzer based on the
PPPSerial analyzer code.
Usual update to files/x509 baseline after adding new analyzer due
to enum values changing.
This is similar to GH-3206. There do not seem to be practical
consequences - but we should still fix it.
This also includes the udp-testcase that was forgotten in GH-3206.
We should not be passing the untrusted TCP header length into
DeliverPacket(). Also, DeliverPacket() cap len parameter should
be the capture length of the packet, not remaining data.
With packet->len representing the wire length and other places
relying on it, ensure it's updated for fragments as well. This
assumes non-truncated fragments right now. Otherwise we'd need
to teach the FragmentReassembler to somehow track this independently
but it would be a mess.
The protocol analyzers are prepared to receive truncated data and
this way we give analyzers a chance to look at data. We previously
allowed empty data being passed: When len ended up 0 and remaining
was 0 too.
This may happen with truncated packets and will cause asan builds to bail out
before the packet can be forwarded along. The TCP analyzer already has this
check, but it's missing for UDP.
