Project

General

Profile

Actions

Bug #1209

closed

suricata 2.0.1 segfault on nmap scan

Added by Rogier Mars almost 10 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

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:
  1. 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]#
Actions #1

Updated by Rogier Mars almost 10 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]#

Actions #2

Updated by Victor Julien almost 10 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?

Actions #3

Updated by Rogier Mars almost 10 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.
  1. 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.

Actions #4

Updated by Rogier Mars almost 10 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
Actions #5

Updated by Rogier Mars almost 10 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.

Actions #6

Updated by Victor Julien almost 10 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.

Actions #7

Updated by Andreas Herz over 8 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF