Bug #5929
closedfast_pattern assignment of specific content in combination with urilen results in FN
Description
Consider the following rules and the attached pcap
alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; urilen:<70; http.uri; content:".php?"; content:"=01&"; distance:4; within:4; fast_pattern; sid:1;) alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; http.uri; bsize:<70; content:".php?"; content:"=01&"; distance:4; within:4; fast_pattern; sid:2;) alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; urilen:<70; http.uri; content:".php?"; content:"=01&"; distance:4; within:4; sid:3;) alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; http.uri; content:".php?"; content:"=01&"; distance:4; within:4; fast_pattern; sid:4;)
Only sid:2, sid:3 and sid:4 fire on git-master (Suricata 7.0.0-rc2-dev (416a780f6 2023-03-17)) and 6.0.10.
sid:2 is a good workaround, however, it lacks whatever optimization that urilen has to make it effect checks (see https://redmine.openinfosecfoundation.org/issues/4226#note-3)
see https://redmine.openinfosecfoundation.org/issues/5197 for a simliar issue
Files
Updated by Brandon Murphy almost 2 years ago
alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; urilen:<70; http.uri; content:".php?"; content:"=01&"; distance:4; within:4; fast_pattern; sid:1;) alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; http.uri; bsize:<70; content:".php?"; content:"=01&"; distance:4; within:4; fast_pattern; sid:2;) alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; urilen:<70; http.uri; content:".php?"; content:"=01&"; distance:4; within:4; sid:3;) alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; http.uri; content:".php?"; content:"=01&"; distance:4; within:4; fast_pattern; sid:4;)
i'm too dumb to figure out how to edit the description - here is a correctly formatted rules
Updated by Victor Julien almost 2 years ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Victor Julien
Updated by Victor Julien almost 2 years ago
Are you able to reproduce it with this exact pcap? That seems to work well for me on master and master6. However I did find that urilen
isn't supported on http2, which makes 1 and 3 not fire on http2.
I've added a test for both cases here https://github.com/OISF/suricata-verify/pull/1154
Urilen http/2 issue tracked in #5931
Updated by Victor Julien almost 2 years ago
Hmm the output of that SV PR seems to the show the issue as well, even if locally it passes. Will look into it.
Updated by Victor Julien almost 2 years ago
- Related to Bug #5931: http2: urilen not supported added
Updated by Brandon Murphy almost 2 years ago
Victor Julien wrote in #note-4:
Are you able to reproduce it with this exact pcap?
Yes Sir. Here is build info
Perhaps this is limited where hyperscan is not being used? (noticed the build info indicates no hyperscan support)
root@ba0ee603b295:/# suricata --build-info This is Suricata version 7.0.0-rc2-dev (416a780f6 2023-03-17) Features: PCAP_SET_BUFF AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HTTP2_DECOMPRESSION HAVE_LUA HAVE_LUAJIT HAVE_LIBJANSSON PROFILING TLS TLS_C11 MAGIC RUST SIMD support: SSE_4_2 SSE_4_1 SSE_3 Atomic intrinsics: 1 2 4 8 16 byte(s) 64-bits, Little-endian architecture GCC version 7.5.0, C version 201112 compiled with _FORTIFY_SOURCE=2 L1 cache line size (CLS)=64 thread local storage method: _Thread_local compiled with LibHTP v0.5.42, linked against LibHTP v0.5.42 Suricata Configuration: AF_PACKET support: yes AF_XDP support: no DPDK support: no eBPF support: no XDP support: no PF_RING support: no NFQueue support: no NFLOG support: no IPFW support: no Netmap support: no DAG enabled: no Napatech enabled: no WinDivert enabled: no Unix socket enabled: yes Detection enabled: yes Libmagic support: yes libjansson support: yes hiredis support: no hiredis async with libevent: no PCRE jit: yes LUA support: yes, through luajit libluajit: yes GeoIP2 support: no Non-bundled htp: no Hyperscan support: no Libnet support: yes liblz4 support: yes Landlock support: no Rust support: yes Rust strict mode: no Rust compiler path: /usr/bin/rustc Rust compiler version: rustc 1.65.0 Cargo path: /usr/bin/cargo Cargo version: cargo 1.65.0 Python support: no Python path: not set Install suricatactl: requires python Install suricatasc: requires python Install suricata-update: no, not bundled Profiling enabled: yes Profiling locks enabled: no Plugin support (experimental): yes Development settings: Coccinelle / spatch: no Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Fuzz targets enabled: no Generic build parameters: Installation prefix: /usr/local Configuration directory: /usr/local/etc/suricata/ Log directory: /usr/local/var/log/suricata/ --prefix /usr/local --sysconfdir /usr/local/etc --localstatedir /usr/local/var --datarootdir /usr/local/share Host: x86_64-pc-linux-gnu Compiler: gcc (exec name) / g++ (real) GCC Protect enabled: no GCC march native enabled: yes GCC Profile enabled: no Position Independent Executable enabled: no CFLAGS -g -O2 -fPIC -std=c11 -march=native -I${srcdir}/../rust/gen -I${srcdir}/../rust/dist PCAP_CFLAGS -I/usr/include SECCFLAGS
Updated by Victor Julien almost 2 years ago
Ok, it seems that with hyperscan enabled it does work, w/o hyperscan it does not work.
Updated by Victor Julien almost 2 years ago
- Status changed from Assigned to In Progress
- Target version changed from TBD to 7.0.0-rc2
- Label Needs backport to 6.0 added
Updated by Victor Julien almost 2 years ago
- Status changed from In Progress to Resolved
Updated by OISF Ticketbot over 1 year ago
- Label deleted (
Needs backport to 6.0)
Updated by Victor Julien over 1 year ago
- Status changed from Resolved to Closed