Bug #1209
closedsuricata 2.0.1 segfault on nmap scan
Description
Hi,
I've been testing with suricata on a VM environment to test if I can use it in a production environment. While testing the IPS features I can repeatedly crash suricata with a core dump by running the following command:
nmap -Pn -sS -A -f 192.168.183.10
my setup looks like this:
(kali ip: 192.168.1883.10) ------ (suricata ips centos6 with nfq running on bridge br0) ----- (webserver: 192.168.183.9)
Suricata is started with the following command:- suricata -q 0
iptables config:
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 0
Every time I run the nmap command (nmap -Pn -sS -A -f 192.168.183.10) suricata crashes with a segfault.
Below the error message and the build-info. If you need more info please let me know and I will provide it.
Kind regards,
Rogier
Jun 13 23:41:37 ids kernel: Detect610431: segfault at e ip 00000000004c6c97 sp 00007f29c75fd3e0 error 4 in suricata[400000+1d3000]
[root@ids rules]# suricata --build-info
This is Suricata version 2.0.1 RELEASE
Features: NFQ PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK HAVE_NSS HAVE_LIBJANSSON PROFILING
SIMD support: SSE_3
Atomic intrisics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 4.4.7 20120313 (Red Hat 4.4.7-4), C version 199901
L1 cache line size (CLS)=64
compiled with LibHTP v0.5.11, linked against LibHTP v0.5.11
Suricata Configuration:
AF_PACKET support: yes
PF_RING support: no
NFQueue support: yes
IPFW support: no
DAG enabled: no
Napatech enabled: no
Unix socket enabled: yes
Detection enabled: yes
libnss support: yes
libnspr support: yes
libjansson support: yes
Prelude support: no
PCRE jit: no
libluajit: no
libgeoip: yes
Non-bundled htp: no
Old barnyard2 support: no
CUDA enabled: no
Suricatasc install: yes
Unit tests enabled: no
Debug output enabled: no
Debug validation enabled: no
Profiling enabled: yes
Profiling locks enabled: no
Coccinelle / spatch: no
Generic build parameters:
Installation prefix (--prefix): /usr
Configuration directory (--sysconfdir): /etc/suricata/
Log directory (--localstatedir) : /var/log/suricata/
Host: x86_64-unknown-linux-gnu
GCC binary: gcc
GCC Protect enabled: no
GCC march native enabled: yes
GCC Profile enabled: no
[root@ids rules]#
Updated by Rogier Mars almost 11 years ago
When I run suricata on the bridge and not in ips mode I don't see the segfault when I run the nmap command. It seems to be related to the nfqueue.
suricata -i br0
[root@ids suricata]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@ids suricata]#
Updated by Victor Julien almost 11 years ago
We've been seeing more problems in nfqueue on a bridge, it's not a setup I'd recommend at this time.
Are you able to provide a backtrace for the crash?
Updated by Rogier Mars almost 11 years ago
Hi,
Below some output of gdb on the corefile that generated the error. As soon as I disable IPS mode the nmap command finishes fine. No segmentation fault when it just logs the packets.- enabled: yes
- drop:
enabled: no
Core was generated by `suricata -vv -c /etc/suricata/suricata.yaml -q 0'.
Program terminated with signal 11, Segmentation fault.
#0 LogDropLogNetFilter (tv=<value optimized out>, thread_data=0x7f2a749fcde0, p=0x271c020)
at log-droplog.c:221
221 TCP_GET_ACK(p), TCP_GET_WINDOW(p));
The coredump is ~40M zipped, so I can't attach it. If you would like to have it i'm happy to post it somewhere.
Updated by Rogier Mars almost 11 years ago
(gdb) backtrace #0 LogDropLogNetFilter (tv=<value optimized out>, thread_data=0x7f2a749fcde0, p=0x271c020) at log-droplog.c:221 #1 LogDropLogger (tv=<value optimized out>, thread_data=0x7f2a749fcde0, p=0x271c020) at log-droplog.c:309 #2 0x00000000004d95bc in OutputPacketLog (tv=0x6e3f970, p=0x271c020, thread_data=<value optimized out>, pq=<value optimized out>, postpq=<value optimized out>) at output-packet.c:102 #3 0x000000000051b278 in TmThreadsSlotVarRun (tv=0x6e3f970, p=0x271c020, slot=<value optimized out>) at tm-threads.c:559 #4 0x000000000051b52a in TmThreadsSlotVar (td=0x6e3f970) at tm-threads.c:814 #5 0x00007f2a90d609d1 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f2a908a9b5d in clone () from /lib64/libc.so.6
Updated by Rogier Mars almost 11 years ago
The bug is in the logging part. When I disable logging of dropped packets everything runs fine. I've done several more tests now and all is succesful with logging disabled.
Updated by Victor Julien almost 11 years ago
How did you set up the bridge? Have a test running here on a bridge, with that scan, but it's not crashing.