Bug #5929
closed
fast_pattern assignment of specific content in combination with urilen results in FN
Added by Brandon Murphy almost 2 years ago.
Updated almost 2 years ago.
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
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
- Description updated (diff)
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Victor Julien
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
Hmm the output of that SV PR seems to the show the issue as well, even if locally it passes. Will look into it.
- Related to Bug #5931: http2: urilen not supported added
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
Ok, it seems that with hyperscan enabled it does work, w/o hyperscan it does not work.
- Status changed from Assigned to In Progress
- Target version changed from TBD to 7.0.0-rc2
- Label Needs backport to 6.0 added
- Status changed from In Progress to Resolved
- Label deleted (
Needs backport to 6.0)
- Status changed from Resolved to Closed
Also available in: Atom
PDF