after upgrading from Zeek 6.0.1 to 6.0.3 on our test server last week, I also enabled some more spicy plugins with spicy_http being one of them. It turns out that this spicy_http plugin causes protocol violations on WinRM HTTP connections: no matches found (/usr/local/zeek/var/lib/zkg/clones/package/spicy-http/analyzer/analyzer.spicy:102:58-103:68).
I have a very small pcap to reproduce this, but I do not want to file this in github because of the IP-addresses and names in it.
Can we handle this another way? Anyone interested?
I have a very small pcap to reproduce this, but I do not want to file this in github because of the IP-addresses and names in it.
Can we handle this another way? Anyone interested?
We are definitely interested. If you can identify an offending package from which you could extract the HTTP payload with e.g., Wireshark you might be able to share that. Alternatively reach out to us on Zeek Slack in #spicy or send me a private message here.
I also enabled some more spicy plugins with spicy_http being one of them.
Do you know why you are replacing Zeek’s built-in HTTP analyzer? I am asking since it is battle tested both in terms of robustness and performance, and the same is probably not true for spicy-http.
thanks! I’ll contact you another way to give you the pcap.
As for the spicy-http plugin, I was (apparently wrong) under the impression that the spicy plugins were the way to go. I already turned it off because I had the impression that I had way more worker crashes than before (compared to the builtin HTTP analyzer).
That’s odd and definitely something we’d like to fix. Please feel free to open issues against the repo for spicy-http. One of the goals of Spicy is to make writing parser for untrustworthy data safer by e.g., eliminating incorrect memory management which is a common source of problems in C or C++ code.
We suggest defaulting to Spicy when implementing new custom parsers for above safety reasons. That safety however is not completely free in terms of runtime performance (part of this is intrinsic, and some of it could also come from not fully optimizing the custom parser). For many more specialized protocols this is often not critical since the custom protocol might only make up a fraction of the full traffic volume. HTTP traffic on the other hand typically makes up a big part of the traffic volume a site sees, so while Zeek’s builtin HTTP analyzer is written in intrinsically less safe binpac/C++ it is much more optimized and refined from years of experience in parsing production traffic. Currently Zeek still uses the binpac/C++ HTTP parser as a default, so this is what we suggest.