Open Information Security Foundation: Issueshttps://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022024-03-25T13:22:29ZOpen Information Security Foundation
Redmine Suricata - Bug #6897 (In Review): detect/port: upper boundary ports are not correctly handled (7....https://redmine.openinfosecfoundation.org/issues/68972024-03-25T13:22:29ZOISF TicketbotSuricata - Bug #6896 (Resolved): detect/port: upper boundary ports are not correctly handledhttps://redmine.openinfosecfoundation.org/issues/68962024-03-25T13:22:19ZShivani BhardwajSuricata - Bug #6895 (In Review): detect/port: port grouping does not happen correctly if gap bet...https://redmine.openinfosecfoundation.org/issues/68952024-03-25T04:51:58ZOISF TicketbotSuricata - Bug #6894 (New): bsize valdation FP on content negation with hex encoded 0d 0ahttps://redmine.openinfosecfoundation.org/issues/68942024-03-24T22:43:09ZBrandon Murphy
<p>consider the following rule, which contains</p>
<pre>
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TEST"; flow:established,to_server; http.header_names; bsize:10; content:!"|0d 0a|User-Agent|0d 0a|"; content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;)
</pre>
<pre>
[129 - Suricata-Main] 2024-03-24 22:40:11 Error: detect-bsize: signature can't match as required content length 14 exceeds bsize value: 10
[129 - Suricata-Main] 2024-03-24 22:40:11 Error: detect: error parsing signature "alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TEST"; flow:established,to_server; http.header_names; bsize:10; content:!"|0d 0a|User-Agent|0d 0a|"; content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;)" from file /tmp/49c7c31b54ecbe71_Mar-24-2024_22-40-11/dalton-custom.rules at line 1
</pre>
<p>I've been able to isolate the issue to the hex encoded values within the content negation.</p>
<p>if you remove one of the <code>|0d 0a|</code> within <code>content:!"|0d 0a|User-Agent|0d 0a|";</code> the error produced reports a required length of 12.</p> Suricata - Task #6888 (New): Remove obsolete items from contribhttps://redmine.openinfosecfoundation.org/issues/68882024-03-24T16:30:01ZJeff Lucovsky
<p>Remove obsolete items from the contrib directory including tile_pcie_logd and file_processor.</p> Suricata - Bug #6887 (In Progress): defrag/ipv6: reassembled packet can have wrong datatypehttps://redmine.openinfosecfoundation.org/issues/68872024-03-23T08:56:21ZVictor Julienvictor@inliniac.net
<p>The reassembled fragment will have DLT_RAW unconditionally, but if the real packets have DLT_ETHERNET the data of the packet will include the ethernet header. The IPv6 header is set up correctly using a hack, and so are the higher levels. However packet logging will report datalink 12 (DLT_RAW) but include the ethernet header in the output.</p>
<p>Not sure yet how to solve it. Might strip the ethernet header from the data, or could change the datalink of the pseudo packet to ethernet in this case.</p> Suricata - Bug #6886 (Assigned): HTTP Chunk Length Value disappearinghttps://redmine.openinfosecfoundation.org/issues/68862024-03-22T15:13:35ZTony Robinson
<p>Hey folks!</p>
<p>I'd like to report what I think is an issue with Currently supported (and developing) versions of suricata - 6.x, 7.x and 8.x.</p>
<p>Recently, I was working on providing coverage for cve-2024-21762. To summarize, its an issue with Fortinet FortiOS products and their handling of chunked HTTP requests.</p>
<p>Bishop Fox developed a python script that can be used to test whether fortinet products are vulnerable to exploitation of this CVE. The original code is here: <a class="external" href="https://github.com/BishopFox/cve-2024-21762-check">https://github.com/BishopFox/cve-2024-21762-check</a></p>
<p>I made some slight changes to the code in order for it to throw the vulnerability check over plain HTTP. I've taken the liberty of attaching my modified script to this request.</p>
<p>So I ran the exploit checker against python http.server listening on port 80 in order to just get the pcaps I needed. I wrote a relatively simple rule designed to capture vulnerability checks using this vulnerability scanning tool:</p>
<p><code>alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:0000000000000000FF|0d 0a 0d 0a|"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:1; rev:1;)</code></p>
<p>I tested this rule again using Dalton, and the rule didn't fire. In an effort to troubleshoot it, I used dalton's ability to dump the HTTP buffers and noticed that the http client request buffer just contains |0d 0a|. That the chunk size isn't included in the buffer. I've attached a screenshot to better illustrate what I'm experiencing.</p>
<p>However, with a slight edit to the original rule, looking for the chunk size value WITHOUT the http.request_body buffer:</p>
<p><code>alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; content:|0d 0a 0d 0a|0000000000000000FF|0d 0a 0d 0a|"; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:1; rev:1;)</code></p>
<p>...triggers alerts just fine.</p>
<p>For the sake of testing, I ran dalton with the full series of http-events.rules, plus the following set of rules:</p>
<pre>
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:"0000000000000000FF"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:1; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:"0000000000000000FF|0d 0a|"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:2; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:"0000000000000000FF|0d 0a 0d 0a|"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:3; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; content:"|0d 0a 0d 0a|0000000000000000FF|0d 0a 0d 0a|"; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:4; rev:1;)
</pre>
<p>The only rule that would fire (aside from an http-events.rule for an invalid host header) was sid number 4. I've tested this on the latest suri 8, 7, and 6 builds, and have attached the dalton job zip files (includes pcap, rules, and suricata.yaml) to this ticket.</p>
<p>Here is what I want to know: Is this expected behavior? Should I assume that the http.request_body buffer is normalizing out the chunk length value in the request body? The reason I enabled the http-events.rules was to see if there were any triggers for anomalous http chunk/chunk length values in the packet capture I generated, but nothing related to http chunk anomalies triggered.</p>
<p>So, is suricata normalizing out the chunk length and not logging any details relating to that? If this is expected behavior, at a minimum I would like to see this documented in all currently supported releases of Suricata -- more specifically, the documentation relating to http.request_body and http.response_body should have notes about this somewhere.</p>
<p>In an ideal world, I'd like to be able to alert on this unusual traffic without resorting to the work-around of creating an unbuffered content match, because according to our conversations, unbuffered content matches are very inefficient. I don't know if that means re-evaluating how Suricata analyzes chunk data, and/or chunk length values, or adding in a new keyword in a future release to be able to analyze raw, chunked data in the http.request_body http.response_body and/or file.data buffer (maybe a modifier like dotprefix --- e.g. --- <code>http.request_body; raw_chunks; content:"0000000000000000FF|0d 0a 0d 0a|";</code></p>
<p>Thank again for all you do to make Suricata better with every release. Please let me know if there are additional details I can provide.</p> Suricata - Feature #6885 (New): references: new "wayback" reference and update othershttps://redmine.openinfosecfoundation.org/issues/68852024-03-22T01:24:50ZBrandon Murphy
<p>I know this isn't the most interesting "issue" to solve, but is one that comes up from time to time.</p>
<p>As an ever increasing amount of URL references are lost, the internet archive's "wayback machine" provides a valuable resource to access to old references.</p>
<p>I'd like to propose that a new reference be introduced called "wayback" <br /><pre>
config reference: wayback https://web.archive.org/web/*/
</pre></p>
<p>This will allow an existing <code>url</code> references to be replaced with <code>wayback</code>, while keeping the reference value the same. It would be the intention to only use this reference when a copy of the reference URL is available via the wayback machine's archive.</p>
<hr />
<p>Additionally the current reference.config file has many non-functioning websites as well.</p>
<p>The current config is as follows (with notes added under each line)<br /><pre>
# config reference: system URL
config reference: bugtraq http://www.securityfocus.com/bid/
- domain doesn't resolve
config reference: bid http://www.securityfocus.com/bid/
- domain doesn't resolve
config reference: cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=
#config reference: cve http://cvedetails.com/cve/
config reference: secunia http://www.secunia.com/advisories/
- redirects to non-useful page
#whitehats is unfortunately gone
config reference: arachNIDS http://www.whitehats.com/info/IDS
- domain parked
config reference: McAfee http://vil.nai.com/vil/content/v_
- domain doesn't resolve
config reference: nessus http://cgi.nessus.org/plugins/dump.php3?id=
- 404s - might just need updated to https://www.tenable.com/plugins/nessus/
config reference: url http://
config reference: et http://doc.emergingthreats.net/
- redirects to non-useful page
config reference: etpro http://doc.emergingthreatspro.com/
- redirects to non-useful page
config reference: telus http://
config reference: osvdb http://osvdb.org/show/osvdb/
- domain doesn't resolve
config reference: threatexpert http://www.threatexpert.com/report.aspx?md5=
- domain doesn't resolve
config reference: md5 http://www.threatexpert.com/report.aspx?md5=
- domain doesn't resolve
config reference: exploitdb http://www.exploit-db.com/exploits/
- WORKS!
config reference: openpacket https://www.openpacket.org/capture/grab/
- Doesn't return a webpage
config reference: securitytracker http://securitytracker.com/id?
- Looks to be not functioning (sometime in 2022?)
config reference: secunia http://secunia.com/advisories/
- Redirects to a non-useful page
config reference: xforce http://xforce.iss.net/xforce/xfdb/
- domain doesn't resolve
config reference: msft http://technet.microsoft.com/security/bulletin/
</pre></p>
<p>I'd like to propose that some of these be replaced with references to the Internet Archives copy. <br />Using bid and bugtraq as an example, these could be updated as follows:<br /><pre>
config reference: bugtraq https://web.archive.org/web/*/http://www.securityfocus.com/bid/
config reference: bid https://web.archive.org/web/*/http://www.securityfocus.com/bid/
</pre></p>
<p>I've actually had great luck with using the wayback machine for securityfocus.com.</p> Suricata - Bug #6882 (Assigned): Detect: ipopts keyword misfires (7.0.x backport)https://redmine.openinfosecfoundation.org/issues/68822024-03-21T15:00:55ZOISF TicketbotSuricata - Bug #6881 (Resolved): detect/port: port grouping does not happen correctly if gap betw...https://redmine.openinfosecfoundation.org/issues/68812024-03-21T08:53:41ZShivani BhardwajSuricata - Bug #6877 (In Review): Suricata 8 general protection fault ip:698117 sp:7fd537b08090https://redmine.openinfosecfoundation.org/issues/68772024-03-20T10:45:18ZAndre ten Bohmer
<pre>
# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: RedHatEnterprise
Description: Red Hat Enterprise Linux release 8.9 (Ootpa)
Release: 8.9
Codename: Ootpa
</pre>
<pre>
$ uname -a
Linux server 4.18.0-513.18.1.el8_9.x86_64 #1 SMP Thu Feb 1 03:51:05 EST 2024 x86_64 x86_64 x86_64 GNU/Linux
</pre>
<p>- DPDK 23.07.0 (from git source)</p>
<pre>
$ libhtp]$ cat VERSION
# This file is intended to be sourced by sh
PKG_VERSION=0.5.47
</pre>
<p>Suricata:<br /><pre>
$ ./configure --enable-gccprotect --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/ --enable-geoip --with-libhs-includes=/usr/local/include/hs/ --with-libhs-libraries=/usr/local/lib64/ --enable-rust --enable-http2-decompression --enable-dpdk
</pre></p>
<p>- Running ok:
{"message": "8.0.0-dev (ece2029b0 2024-03-13)", "return": "OK"}</p>
<p>- Bug since : Suricata version 8.0.0-dev (bf5cfd6ab 2024-03-19)<br /><pre>
Mar 20 11:41:08 server suricata[1636293]: Invalid port_id=65535
Mar 20 11:41:08 server suricata[1636293]: Notice: threads: Threads created -> W: 102 FM: 5 FR: 5 Engine started. [TmThreadWaitOnThreadRunning:tm-threads.c:1899]
Mar 20 11:41:08 server suricata[1636293]: Invalid port_id=65535
Mar 20 11:41:08 server kernel: traps: W#04-84:00.1[1636703] general protection fault ip:698117 sp:7fd537b08090 error:0 in suricata[400000+a8c000]
Mar 20 11:41:08 server kernel: traps: W#13-84:00.1[1636712] general protection fault ip:698117 sp:7fd50bffd090 error:0
Mar 20 11:41:08 server suricata[1636293]: Invalid port_id=65535
Mar 20 11:41:09 server systemd[1]: suricata.service: Main process exited, code=killed, status=11/SEGV
Mar 20 11:41:09 server systemd[1]: suricata.service: Failed with result 'signal'.
</pre><br /><pre>
$ gdb --args /bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid --user root --dpdk -vvv
Info: unix-manager: unix socket '/var/run/suricata/suricata-command.socket' [UnixNew:unix-manager.c:136]
[New Thread 0x7ffd777fe700 (LWP 1603728)]
Perf: threads: Setting prio 0 for thread "US", thread id 1603728 [TmThreadSetupOptions:tm-threads.c:883]
Invalid port_id=65535
Notice: threads: Threads created -> W: 102 FM: 5 FR: 5 Engine started. [TmThreadWaitOnThreadRunning:tm-threads.c:1899]
Invalid port_id=65535
Perf: hugepages: 1048576kB hugepages on NUMA node 0 are unused and can be deallocated [SystemHugepageEvaluateHugepages:util-hugepages.c:392]
Perf: hugepages: 1048576kB hugepages on NUMA node 1 are unused and can be deallocated [SystemHugepageEvaluateHugepages:util-hugepages.c:392]
Invalid port_id=65535
Thread 216 "W#01-84:00.1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffe0591d700 (LWP 1603698)]
0x000000000062daba in rte_eth_rx_burst (nb_pkts=32, rx_pkts=0x7ffdf0520190, queue_id=0, port_id=65535) at /usr/local/include/rte_ethdev.h:5963
5963 nb_rx = p->rx_pkt_burst(qd, rx_pkts, nb_pkts);
Missing separate debuginfos, use: yum debuginfo-install libatomic-8.5.0-20.el8.x86_64
(gdb) bt
#0 0x000000000062daba in rte_eth_rx_burst (nb_pkts=32, rx_pkts=0x7ffdf0520190, queue_id=0, port_id=65535) at /usr/local/include/rte_ethdev.h:5963
#1 ReceiveDPDKLoop (slot=<optimized out>, data=<optimized out>, tv=<optimized out>) at source-dpdk.c:583
#2 ReceiveDPDKLoop (tv=0x1eb91e20, data=0x7ffdf0520120, slot=<optimized out>) at source-dpdk.c:567
#3 0x00000000005613d7 in TmThreadsSlotVarRun (tv=tv@entry=0x1eb91e20, p=p@entry=0x7ffdf0520120, slot=<optimized out>) at tm-threads.c:135
#4 0x000000000062dc84 in TmThreadsSlotProcessPkt (p=0x7ffdf0520120, s=<optimized out>, tv=0x1eb91e20) at tm-threads.h:200
#5 ReceiveDPDKLoop (slot=<optimized out>, data=<optimized out>, tv=<optimized out>) at source-dpdk.c:598
#6 ReceiveDPDKLoop (tv=0x1eb91e20, data=0x7ffdf0520b60, slot=<optimized out>) at source-dpdk.c:567
#7 0x0000000000562a6c in TmThreadsSlotPktAcqLoop (td=0x1eb91e20) at tm-threads.c:318
#8 0x00007ffff67921ca in start_thread () from /lib64/libpthread.so.0
#9 0x00007ffff4146e73 in clone () from /lib64/libc.so.6
</pre></p> 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 - Optimization #6873 (In Review): Convert byte_extract keyword/option parsing to Rusthttps://redmine.openinfosecfoundation.org/issues/68732024-03-19T14:11:22ZJeff Lucovsky
<p>Convert the option parsing for byte_extract to Rust to reduce LOC and improve processing time.</p> Suricata - Bug #6872 (Assigned): dpdk: fix compatibility issues for ice cards (7.0.x backport)https://redmine.openinfosecfoundation.org/issues/68722024-03-19T12:59:16ZOISF TicketbotSuricata - Bug #6871 (In Review): dpdk: fix compatibility issues for ice cardshttps://redmine.openinfosecfoundation.org/issues/68712024-03-19T12:58:32ZLukas Sismis
<p>Currently:<br />DPDK v23.11.0 doesn't startup on ice cards (tested on E810) - complains about invalid RSS hash key length settings - the length was changed to 52 bytes from 40 (similar as is in i40e).</p>
<p>DPDK v22.11.2 <br />closing the device ends with a segfault</p>
<p>DPDK v21.11.6<br />works fine</p>
<p>DPDK v20.11.10<br />works fine</p>
<p>DPDK v19.11.14<br />works fine</p>