Bug #1694
closed
unix-socket reading 0 size pcap
Added by Peter Manev about 8 years ago.
Updated about 5 years ago.
Description
Reading feeding 0 size pcap with unix-socket the engine (3.0dev (rev 44a444b)) stalls and eventually after some time crashes out with -
[14779] 4/2/2016 -- 22:03:07 - (tm-threads.c:1493) <Error> (TmThreadDisableReceiveThreads) -- [ERRCODE: SC_ERR_FATAL(171)] - Engine unable to disable detect thread - "ReceivePcapFile". Killing engine
While there is no valid reason to read an empty.pcap (attached) there should be some controls implemented in order to avoid that.
- Assignee set to OISF Dev
- Target version set to 70
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Eric Leblond
- Priority changed from Normal to Low
Empty 'pcap' is nothing more than a 0 byte file. Probably libpcap blocks while reading the file, and we use no read 'time out' in offline mode. Guess we could have an explicit check for this. Might make sense to check for the file to be at least the size of a pcap header.
- Target version changed from 70 to TBD
- Assignee changed from Eric Leblond to Danny Browning
Related to other work I'm doing around hardening unix socket pcaps, so assigning to myself.
- Related to Bug #2795: asan leak: processing of empty pcap added
- Priority changed from Low to Normal
- Target version changed from TBD to 70
Hi Danny, have you looked further into this?
The error was originally reported in 3.0, however in 4.1 the engine correctly shuts down when using the -r option.
[4611] 18/2/2019 -- 08:26:13 - (source-pcap-file-helper.c:174) <Error> (InitPcapFile) -- [ERRCODE: SC_ERR_FOPEN(44)] - truncated dump file; tried to read 4 file header bytes, only got 0
[4611] 18/2/2019 -- 08:26:13 - (source-pcap-file.c:276) <Warning> (ReceivePcapFileThreadInit) -- [ERRCODE: SC_ERR_PCAP_DISPATCH(20)] - Failed to init pcap file empty.pcap, skipping
[775] 18/2/2019 -- 08:26:13 - (tm-threads.c:2127) <Error> (TmThreadWaitOnThreadInit) -- [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "RX#01" failed to initialize: flags 0145
[775] 18/2/2019 -- 08:26:13 - (suricata.c:3033) <Error> (main) -- [ERRCODE: SC_ERR_INITIALIZATION(45)] - Engine initialization failed, aborting...
source-pcap-file is returning an error since init failed, and then we get a thread init error message due to this.
[775] 18/2/2019 -- 08:26:13 - (tm-threads.c:2127) <Error> (TmThreadWaitOnThreadInit) -- [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "RX#01" failed to initialize: flags 0145
This behavior feels correct, but we could check the size of the file and produce a little clearer output.
- Status changed from Assigned to Closed
- Assignee deleted (
Danny Browning)
- Target version deleted (
70)
Thanks for checking Danny!
In unix socket mode, this produces a segfault in 4.1, since the thread errors.
So 2 options
- Check for 0 size files and don't fail the init, just report an error message and return ok
- Figure out why an init failure causes a segfault
- Status changed from Closed to Assigned
- Assignee set to Danny Browning
- Target version set to 70
Ah ok, reopening because of that.
I think there are more ways in which opening a pcap can fail, so we probably need a more generic way to handle it than just a 0 size check.
- Status changed from Assigned to Closed
- Target version changed from 70 to 5.0beta1
- Related to Bug #3448: Suricata 4.1 Seg Fault: Socket Control pcap-file and corrupt pcap added
Also available in: Atom
PDF