Open Information Security Foundation: Issueshttps://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022024-03-19T18:29:22ZOpen Information Security Foundation
Redmine Suricata - Bug #6874 (Assigned): libhtp appears to stop parsing HTTP client requests mid-pcap - /...https://redmine.openinfosecfoundation.org/issues/68742024-03-19T18:29:22ZTony Robinson
<p>Hello!</p>
<p>My name is Tony, and I work with the Proofpoint Emerging Threats Team. I'd like to report a problem that I've across in Suricata 8.0.0-dev (3/13 build), 7.0.3, and 6.0.0.16. All builds are on x86-64, utilizing the test platform, Dalton (<a class="external" href="https://github.com/secureworks/dalton">https://github.com/secureworks/dalton</a>).</p>
<p>We got a report from a user for some new rules to cover "AsukaStealer". If you're interested, take a look at the forum post here:</p>
<p><a class="external" href="https://community.emergingthreats.net/t/asukastealer-observerstealer-gen/1470">https://community.emergingthreats.net/t/asukastealer-observerstealer-gen/1470</a></p>
<p>The bottom line is that towards the end of the post, the submitter claims that they had to do content matches that do not utilize the http buffers in order to get their rules to trigger. Here is a link to the any.run sandbox run (and the pcap): <a class="external" href="https://app.any.run/tasks/8b1ee45a-87de-4fc5-a755-84546a974a44">https://app.any.run/tasks/8b1ee45a-87de-4fc5-a755-84546a974a44</a></p>
<p>For those who don't have (or don't want) an any.run account, I've taken the liberty of attaching the pcap (in a dalton job zip file) associated with this issue.</p>
<p>So, to test the submitter's assertions that HTTP buffers weren't working, I took one of the rules they submitted to us, and transformed it a bit:</p>
<p><code>alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE [ANY.RUN] AsukaStealer SQLite Browser Data Exfiltration Attempt"; flow:established,to_server; http.method; content:"POST"; http.content_type; content:"multipart|2f|form-data|3b 20|boundary|3d|"; http.header; content:"X-Config|3a 20|"; fast_pattern; pcre:"/^(?:Google\x5f|Edge\x5f|Steam\x5f|Firefox\x5fF)/R"; content:"COK|0d 0a|"; within:20; http.header_names; content:"|0d 0a|X-Session|0d 0a|"; content:"|0d 0a|X-Info|0d 0a|"; content:"|0d 0a|X-Config|0d 0a|"; reference:md5,ae5537f1a506140ee101ffdf4605fdcc; reference:url,app.any.run/tasks/7a36fb55-3738-4f40-b760-b443689c9edd; reference:url,community.emergingthreats.net/t/asukastealer-observerstealer-gen; classtype:trojan-activity; sid:1; rev:1;)</code></p>
<p>For reference, here was the original rule (minus a very slight error that would cause it to not trigger):</p>
<p><code>alert http any any -> any any (msg:"ET MALWARE [ANY.RUN] AsukaStealer Exfiltrates SQLite Browsers Data"; flow:established,to_server; content:"POST"; startswith; content:"Content-Type|3a 20|multipart|2f|form-data|3b 20|boundary="; distance:0; content:"X-Session|3a| "; within:350; content:"X-Info|3a|"; within:45; content:"X-Config|3a| "; within:350; pcre:"/^(Google_COK|Firefox_COK|Edge_COK)\r/R"; content:"X-ID|3a| "; within:22; threshold:type limit, seconds 120, count 1, track by_src; classtype:credential-theft; reference:md5,ae5537f1a506140ee101ffdf4605fdcc; reference:url,app.any.run/tasks/7a36fb55-3738-4f40-b760-b443689c9edd; reference:url,community.emergingthreats.net/t/asukastealer-observerstealer-gen; metadata:malware_family asukastealer, created_at 2024_03_19; sid:1; rev:1;)</code></p>
<p>The rule I wrote will <em>not</em> trigger on the sandbox pcap. However, there are several existing ET rules that <em>will</em> trigger on that pcap that make use of HTTP buffers. I've noticed that after the HTTP client POST that sends a large PNG file, libhtp starts throwing errors. Here is the output from the Dalton job's HTTP log:</p>
<p><code>02/09/2024-05:46:12.189215 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:12.989933 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:13.756718 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:14.867041 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:15.067488 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:15.753600 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:16.471367 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:17.826489 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:18.248283 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:20.315563 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:24.411779 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:26.703613 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:26.928567 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:27.087962 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:27.306797 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:27.508658 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:27.678091 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:27.835970 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:28.044538 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:28.235679 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:28.395542 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:28.642545 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:28.904393 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:29.063432 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:29.264992 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:29.467883 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:46:29.725990 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br />02/09/2024-05:45:52.397646 <hostname unknown>[**]/libhtp::request_uri_not_seen[**]<useragent unknown>[**]192.168.100.185:49208 -> 5.42.66.25:3000<br /></code></p>
<p>I'm not sure why this is happening. The submitted rule <em>does</em> trigger, but it only appears to trigger on the packet thread. I've attached a screenshot the submitter supplied to show how/why they had to use content matches without sticky buffers to get the rule to work. Just as a sanity check I used flowsynth to create a packet capture that would trigger both of the rules above, and I've attached that. I can confirm that both rules will fire on that pcap.</p>
<p>I thought that maybe I was hitting an http client inspection depth configuration problem. The default for Dalton is 100kb for both client and server inspection depth. I upped this to 100mb just to rule it out, and have attached the job zip file for that as well. The rule I created still refuses to trigger. Near as I can tell the HTTP requests in the sandbox pcap are well-formed, there are no irregularities that I have noticed in the pcap, and copying one of the malicious POST requests and using it to create a new packet capture with flowsynth worked just fine. At this point, I'm at a loss.</p>
<p>If there is any other information I can supply to help in finding the root of this problem and/or correcting it, please let me know.</p> Suricata - Bug #6727 (Assigned): stream: stream.drop-invalid drops valid traffic (7.0.x backport)https://redmine.openinfosecfoundation.org/issues/67272024-01-31T08:44:35ZOISF TicketbotSuricata - Bug #6726 (New): stream: stream.drop-invalid drops valid traffichttps://redmine.openinfosecfoundation.org/issues/67262024-01-31T08:43:51ZVictor Julienvictor@inliniac.net
<p>In AF_PACKET IPS mode, so in bridge mode, traffic for a simple <code>ab</code> test against a simple webserver fails with a timeout.</p>
<p>6.0.x is not affected.</p> Suricata - Bug #6690 (Assigned): Ethernet src should match src ip (7.0.x backport)https://redmine.openinfosecfoundation.org/issues/66902024-01-18T08:22:04ZOISF TicketbotSuricata - Bug #6555 (Assigned): eve/alert: payload/payload_printable misrepresent data in case o...https://redmine.openinfosecfoundation.org/issues/65552023-11-20T08:55:22ZOISF TicketbotSuricata - Bug #6553 (Resolved): eve/alert: payload/payload_printable misrepresent data in case o...https://redmine.openinfosecfoundation.org/issues/65532023-11-20T08:55:09ZVictor Julienvictor@inliniac.net
<p>In certain TCP segment overlap scenarios the payload/payload_printable fields contain partly duplicate data essentially corrupting the data.</p> Suricata - Bug #6541 (Assigned): landlock: coverity warnings (7.0.x backport)https://redmine.openinfosecfoundation.org/issues/65412023-11-17T12:17:14ZOISF TicketbotSuricata - Bug #6520 (In Review): detect-engine/port: recursive DetectPortInsert calls are expens...https://redmine.openinfosecfoundation.org/issues/65202023-11-17T10:07:03ZOISF TicketbotSuricata - Bug #6414 (Resolved): detect-engine/port: recursive DetectPortInsert calls are expensivehttps://redmine.openinfosecfoundation.org/issues/64142023-10-19T16:11:37ZShivani Bhardwaj
<p><strong>Problem</strong><br />It seems that for certain kinds of rules, the recursive calls to <code>DetectPortInsert</code> can be very expensive.<br />There has been a todo to get rid of the recursive calls since a long time that needs to be addressed now.<br />The issue can be observed for large rulesets especially containing a mix of <code>drop tls</code> rules and others.<br />One noteworthy thing is that these rules loaded separately end up consuming much lesser time.</p>
<p><strong>Useful info</strong><br />Attached is one scenario where the flamegraph shows heavy frequenting of this fn.</p> Suricata - Bug #6405 (In Review): Ethernet src should match src iphttps://redmine.openinfosecfoundation.org/issues/64052023-10-13T19:33:12ZEric Leblonderic@regit.org
<p>The ethernet IP addresses should match the IP addresses so the user can attribute the IP to the mac address. By that, I mean the src_ip address should correspond to the ether.src_mac and reverse for destination.</p>
<p>I've studied the problem with the pcap from MTA: <a class="external" href="https://www.malware-traffic-analysis.net/2019/07/05/index.html">https://www.malware-traffic-analysis.net/2019/07/05/index.html</a> to try to collect information about the current status.</p>
<pre>
suricata -l /tmp/ip-ether/ -r ~/Downloads/2019-07-05-Ursnif-with-Trickbot-and-IcedID.pcap -c suricata.yaml
</pre>
<p>As we can see via the following jq commmand we have multiple association<br /><pre>
cat /tmp/ip-ether/eve.json | jq 'select(.ether.dest_mac)|{"ether_src_mac": .ether.src_mac, "src_ip": .src_ip}' -c|sort | uniq
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"104.24.105.145"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"10.7.5.101"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"144.217.50.240"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"144.217.50.243"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"170.238.117.187"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"181.129.140.140"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.117.73.76"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.175.156.13"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.193.141.176"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.248.87.88"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.251.38.235"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"198.12.71.157"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"23.63.254.169"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"46.17.46.97"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"5.188.168.49"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"66.70.218.60"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"94.140.125.34"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.101"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5"}
</pre></p>
<p>In particular for 10.7.5.101:<br /><pre>
cat /tmp/ip-ether/eve.json | jq 'select(.ether.dest_mac and .src_ip=="10.7.5.101")|{"ether_src_mac": .ether.src_mac, "src_ip": .src_ip}' -c|sort | uniq
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101"} # real mac address of host
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"10.7.5.101"} # mac address of gw
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.101"} # mac address of 10.7.5.5
</pre></p>
<p>If we add the application layer in the equation, we then can see that it is dependant of it:<br /><pre>
cat /tmp/ip-ether/eve.json | jq 'select(.ether.dest_mac)|{"ether_src_mac": .ether.src_mac, "src_ip": .src_ip, "event_type": .event_type}' -c|sort | uniq
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101","event_type":"alert"}
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101","event_type":"dns"}
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101","event_type":"fileinfo"}
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101","event_type":"http"}
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101","event_type":"krb5"}
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101","event_type":"smb"}
{"ether_src_mac":"00:08:02:1c:47:ae","src_ip":"10.7.5.101","event_type":"tls"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"104.24.105.145","event_type":"fileinfo"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"10.7.5.101","event_type":"dns"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"144.217.50.240","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"144.217.50.243","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"170.238.117.187","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"170.238.117.187","event_type":"fileinfo"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"181.129.140.140","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.117.73.76","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.175.156.13","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.193.141.176","event_type":"fileinfo"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.248.87.88","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"185.251.38.235","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"198.12.71.157","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"198.12.71.157","event_type":"fileinfo"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"23.63.254.169","event_type":"fileinfo"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"46.17.46.97","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"46.17.46.97","event_type":"fileinfo"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"5.188.168.49","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"5.188.168.49","event_type":"fileinfo"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"66.70.218.60","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"94.140.125.34","event_type":"alert"}
{"ether_src_mac":"20:e5:2a:b6:93:f1","src_ip":"94.140.125.34","event_type":"fileinfo"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.101","event_type":"dns"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.101","event_type":"smb"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5","event_type":"alert"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5","event_type":"anomaly"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5","event_type":"dhcp"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5","event_type":"fileinfo"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5","event_type":"http"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5","event_type":"krb5"}
{"ether_src_mac":"a4:1f:72:c2:09:6a","src_ip":"10.7.5.5","event_type":"tls"}
</pre></p> Suricata - Bug #6384 (New): Configure seems failed to persistently detect/remember cbindgen locationhttps://redmine.openinfosecfoundation.org/issues/63842023-10-04T15:55:07ZAditya Nugraha
<p>I am compiling suricata 7.0.2-DEV for OpenWrt x86-64, with 7.0.1 stable release my OpenWrt specific MakeFile for going well (compiled & run fine).</p>
<p>That's because the rust-bindings.h inside rust/dist dir is already on the stable release, but as per-git, I am getting the following :</p>
<pre>
make gen/rust-bindings.h
make[5]: Entering directory '/home/username/works/openwrt/build_dir/target-x86_64_glibc_custom/suricata-7.0.2/rust'
cbindgen --config /home/username/works/openwrt/build_dir/target-x86_64_glibc_custom/suricata-7.0.2/rust/cbindgen.toml \
--quiet --verify --output /home/username/works/openwrt/build_dir/target-x86_64_glibc_custom/suricata-7.0.2/rust/gen/rust-bindings.h || true
/bin/bash: line 1: cbindgen: command not found
make[5]: Leaving directory '/home/username/works/openwrt/build_dir/target-x86_64_glibc_custom/suricata-7.0.2/rust'
As in git/7.0.2-DEV we need to generate the rust-bindings.h, I've found that configure at the stage of "make gen/rust-bindings.h" seems failed to
"remember" the previously found/installed "cbindgen"
</pre>
<p>From Configuring :<br /><pre>
checking for cbindgen... /home/username/works/openwrt/staging_dir/target-x86_64_glibc_custom/host/cargo/bin/cbindgen
</pre></p>
<p>From config.log : <br /><pre>
ac_cv_path_CBINDGEN=/home/username/works/openwrt/staging_dir/target-x86_64_glibc_custom/host/cargo/bin/cbindgen
CBINDGEN='/home/username/works/openwrt/staging_dir/target-x86_64_glibc_custom/host/cargo/bin/cbindg
HAVE_CBINDGEN_FALSE='#'
HAVE_CBINDGEN_TRUE=''
configure:30078: checking for cbindgen
configure:30101: found /home/username/works/openwrt/staging_dir/target-x86_64_glibc_custom/host/cargo/bin/cbindgen
configure:30114: result: /home/username/works/openwrt/staging_dir/target-x86_64_glibc_custom/host/cargo/bin/cbindgen
</pre></p>
<p>Notable most important lines from Suricata OpenWrt package Makefile : <br /><pre>
define Build/Configure
( \
cd $(PKG_BUILD_DIR) ; \
git clone https://github.com/OISF/libhtp.git && \
git clone https://github.com/OISF/suricata-update.git ; \
$(CONFIGURE_VARS) cargo install --root $(CARGO_HOME) cbindgen ; \
cd $(PKG_BUILD_DIR) && $(CONFIGURE_VARS) ./autogen.sh && $(CONFIGURE_VARS) ./configure $(CONFIGURE_ARGS) ; \
)
$(call Build/Configure/Default)
endef
</pre></p> Suricata - Bug #6223 (New): HTTP/HTTP2 websites cannot be accessed; however HTTP3 canhttps://redmine.openinfosecfoundation.org/issues/62232023-07-20T14:06:54ZSamiux Arunnersam@gmail.com
<p>Suricata 7.0.0<br />AF-Packet IPS mode</p>
<p>HTTP/1, HTTP/2 websites cannot be accessed. However, HTTP/3 can.</p>
<p>HTTP/3 sites, e.g. youtube.com, thehackernews.com.</p> Suricata - Bug #6003 (Assigned): stream/reassembly: memcap exception policy incorrectly applied (...https://redmine.openinfosecfoundation.org/issues/60032023-04-18T11:00:18ZOISF TicketbotSuricata - Bug #5539 (In Review): landlock: coverity warningshttps://redmine.openinfosecfoundation.org/issues/55392022-09-13T17:55:17ZVictor Julienvictor@inliniac.net
<pre>
** CID 1514671: Error handling issues (CHECKED_RETURN)
/src/util-landlock.c: 181 in LandlockSandboxing()
________________________________________________________________________________________________________
*** CID 1514671: Error handling issues (CHECKED_RETURN)
/src/util-landlock.c: 181 in LandlockSandboxing()
175 }
176
177 void LandlockSandboxing(SCInstance *suri)
178 {
179 /* Read configuration variable and exit if no enforcement */
180 int conf_status;
>>> CID 1514671: Error handling issues (CHECKED_RETURN)
>>> Calling "ConfGetBool" without checking return value (as is done elsewhere 30 out of 31 times).
181 ConfGetBool("security.landlock.enabled", &conf_status);
182 if (!conf_status) {
183 SCLogConfig("Landlock is not enabled in configuration");
184 return;
185 }
186 struct landlock_ruleset *ruleset = LandlockCreateRuleset();
** CID 1514670: Security best practices violations (TOCTOU)
/src/util-landlock.c: 204 in LandlockSandboxing()
________________________________________________________________________________________________________
*** CID 1514670: Security best practices violations (TOCTOU)
/src/util-landlock.c: 204 in LandlockSandboxing()
198 if (suri->run_mode == RUNMODE_PCAP_FILE) {
199 const char *pcap_file;
200 ConfGet("pcap-file.file", &pcap_file);
201 char *file_name = SCStrdup(pcap_file);
202 if (file_name != NULL) {
203 struct stat statbuf;
>>> CID 1514670: Security best practices violations (TOCTOU)
>>> Calling function "stat" to perform check on "file_name".
204 if (stat(file_name, &statbuf) != -1) {
205 if (S_ISDIR(statbuf.st_mode)) {
206 LandlockSandboxingReadPath(ruleset, file_name);
207 } else {
208 LandlockSandboxingReadPath(ruleset, dirname(file_name));
209 }
** CID 1514669: (CHECKED_RETURN)
/src/util-landlock.c: 248 in LandlockSandboxing()
/src/util-landlock.c: 200 in LandlockSandboxing()
________________________________________________________________________________________________________
*** CID 1514669: (CHECKED_RETURN)
/src/util-landlock.c: 248 in LandlockSandboxing()
242 } else {
243 LandlockSandboxingWritePath(ruleset, LOCAL_STATE_DIR "/run/suricata/");
244 }
245 }
246 if (suri->sig_file_exclusive == FALSE) {
247 const char *rule_path;
>>> CID 1514669: (CHECKED_RETURN)
>>> Calling "ConfGet" without checking return value (as is done elsewhere 87 out of 89 times).
248 ConfGet("default-rule-path", &rule_path);
249 if (rule_path) {
250 LandlockSandboxingReadPath(ruleset, rule_path);
251 }
252 }
253
/src/util-landlock.c: 200 in LandlockSandboxing()
194 if (stat(ConfigGetDataDirectory(), &sb) == 0) {
195 LandlockSandboxingAddRule(ruleset, ConfigGetDataDirectory(),
196 _LANDLOCK_SURI_ACCESS_FS_WRITE | _LANDLOCK_ACCESS_FS_READ);
197 }
198 if (suri->run_mode == RUNMODE_PCAP_FILE) {
199 const char *pcap_file;
>>> CID 1514669: (CHECKED_RETURN)
>>> Calling "ConfGet" without checking return value (as is done elsewhere 87 out of 89 times).
200 ConfGet("pcap-file.file", &pcap_file);
201 char *file_name = SCStrdup(pcap_file);
202 if (file_name != NULL) {
203 struct stat statbuf;
204 if (stat(file_name, &statbuf) != -1) {
205 if (S_ISDIR(statbuf.st_mode)) {
</pre><br />The retval checking is pretty trivial. Not sure how the TOCTOU would be solved in this case. <a class="user active user-mention" href="https://redmine.openinfosecfoundation.org/users/1820">@Philippe Antoine</a> any thoughts? Suricata - Bug #4220 (Assigned): failed to hit a signature with option --simulate-ipshttps://redmine.openinfosecfoundation.org/issues/42202020-12-16T09:00:38ZLitmus Shi
<p>Hi,</p>
<p>I have a pcap trace which can hit my signature with the configurations in the attachment in IDS mode.<br />But the same trace failed to hit the same signature with the same configuration in IPS mode.</p>
<p>Is it by design or a bug?</p>
<p>How to reproduce:<br />1. uncompress the tar.gz to /home/inline-test, make sure all files are under /home/inline-test<br />2. cd /home/inline-test<br />3. ntd-ids -c ./suricata.yaml -r ./1flowB.pcap, and we can see eve logs.<br />4. ntd-ids -c ./suricata.yaml -r ./1flowB.pcap --simulate-ips, and we can't see any eve logs.</p>