Project

General

Profile

Actions

Bug #1694

closed

unix-socket reading 0 size pcap

Added by Peter Manev over 8 years ago. Updated over 5 years ago.

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

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.


Related issues 2 (0 open2 closed)

Related to Suricata - Bug #2795: asan leak: processing of empty pcapClosedSumera PriyadarsiniActions
Related to Suricata - Bug #3448: Suricata 4.1 Seg Fault: Socket Control pcap-file and corrupt pcapClosedShivani BhardwajActions
Actions #1

Updated by Victor Julien over 8 years ago

  • Assignee set to OISF Dev
  • Target version set to 70
Actions #2

Updated by Peter Manev over 8 years ago

Empty pcap attached.

Actions #3

Updated by Victor Julien over 8 years ago

  • 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.

Actions #4

Updated by Victor Julien over 8 years ago

  • Target version changed from 70 to TBD
Actions #5

Updated by Danny Browning over 6 years ago

  • Assignee changed from Eric Leblond to Danny Browning

Related to other work I'm doing around hardening unix socket pcaps, so assigning to myself.

Actions #6

Updated by Victor Julien over 5 years ago

  • Related to Bug #2795: asan leak: processing of empty pcap added
Actions #7

Updated by Victor Julien over 5 years ago

  • Priority changed from Low to Normal
  • Target version changed from TBD to 70
Actions #8

Updated by Victor Julien over 5 years ago

Hi Danny, have you looked further into this?

Actions #9

Updated by Danny Browning over 5 years ago

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.

Actions #10

Updated by Victor Julien over 5 years ago

  • Status changed from Assigned to Closed
  • Assignee deleted (Danny Browning)
  • Target version deleted (70)

Thanks for checking Danny!

Actions #11

Updated by Danny Browning over 5 years ago

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
Actions #12

Updated by Victor Julien over 5 years ago

  • 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.

Actions #14

Updated by Victor Julien over 5 years ago

  • Status changed from Assigned to Closed
  • Target version changed from 70 to 5.0beta1
Actions #15

Updated by Victor Julien over 4 years ago

  • Related to Bug #3448: Suricata 4.1 Seg Fault: Socket Control pcap-file and corrupt pcap added
Actions

Also available in: Atom PDF