Jason Ish [Thu, 9 Apr 2020 21:59:23 +0000 (15:59 -0600)]
conf/yaml: limit recursion depth while paring YAML
A deeply nested YAML file can cause a stack-overflow while
reading in the configuration to do the recursive parser. Limit
the recursion level to something sane (128) to prevent this
from happening.
The default Suricata configuration has a recursion level of 128
so there is still lots of room to grow (not that we should).
Jason Ish [Wed, 1 Apr 2020 22:41:06 +0000 (16:41 -0600)]
dns: log addresses in flow direction, not packet (C)
Address issue with source and destination addresses be logged
in the wrong order. This was already addressed in the Rust code
with c2d833fcaf1b01fea8e7dfda71b2e965521c963d.
Giuseppe Longo [Mon, 28 Jan 2019 15:15:22 +0000 (16:15 +0100)]
app-layer-htp: use stream depth with filestore
This permits to use stream-depth value set for file-store.
Currently if a file is being stored and hits a limit,
such as request or response body, it will be truncated
although file-store.stream-depth is enabled but the file should be
closed and not truncated.
Two unit tests have been added to verify that:
- a file is stored correctly
- chunk's length computation doesn’t cause an underflow
Victor Julien [Fri, 28 Feb 2020 12:17:03 +0000 (13:17 +0100)]
pcap/file: improve time handling
This patch addresses two problems.
First, various parts of the engine, but most notably the flow manager (FM),
use a minimum of the time notion of the packet threads. This did not
however, take into account the scenario where one or more of these
threads would be inactive for prolonged times. This could lead to the
time used by the FM could get stale.
This is addressed by keeping track of the last time the per thread packet
timestamp was updated, and only considering it for the 'minimum' when it
is reasonably current.
Second, there was a minor race condition at start up, where the FM would
already inspect the hash table(s) while the packet threads weren't active
yet. Since FM gets the time from the packet threads, it would use a bogus
time of 0.
This is addressed by adding a wait loop to the start of the FM that waits
for 'time' to get ready.
Victor Julien [Thu, 27 Feb 2020 16:20:18 +0000 (17:20 +0100)]
pcap/file: fix race during pcap processing start
A race condition during the start of pcap file processing could cause
missed alerts and logged events. This race happens between the packet
threads and the flow manager. It was observed on slower hardware, but in
theory could happen on any machine. It required the 'autofp' runmode.
In commit 6f560144c1b9 ("time: improve offline time handling") the logic
was added to make the flow manager use a minimum of all the packet threads
perception of time.
The race condition was that the flow manager may become active _before_
all of the packet threads have started processing packets and thus setting
their timestamp. The threads that had not yet initialized their timestamp
would not be considered when calculating the minimum.
As a result of this, older packets timestamps would not yet be registered.
This would give the Flow Manager a timestamp too far in the future. While
the FM was running, the packet processing would start and a flow would
be created. This flow would then immediately be considered 'timed out' by
the FM, due to the timestamp too far in the future.
In the observed case, the thread processing packet 1 from the pcap had not
yet started processing while other threads had already started. The FM was
also already active. Due to the timestamps in the pcap this meant that the
time the FM used was about 500 seconds in the future compared to packet 1.
This patch fixes the issue by initializing all of the threads timestamps
with the timestamp value of the first packet. This way the minimum will
always consider this timestamp.
Jeff Lucovsky [Tue, 4 Feb 2020 15:13:49 +0000 (10:13 -0500)]
smtp/mime: Restrict file name lengths
This commit places restrictions on the length of the file name specified
in attachments (`name=` or `filename=`) to `NAME_MAX`. Names exceeding
these limits will be truncated and processing will continue with the
truncated name.
Victor Julien [Sat, 14 Dec 2019 19:20:45 +0000 (20:20 +0100)]
streaming/api: fix overlap check
In some cases a SBB could be seen as overlapping with the requested
offset, when it was in fact precisely before it. In some special cases
this could lead to the stream engine not progressing the 'raw' progress.
Victor Julien [Tue, 11 Feb 2020 10:55:18 +0000 (11:55 +0100)]
nfs: implement post-GAP transaction cleanup
Close all prior transactions in the direction of the GAP, except the
file xfers. Those use their own logic described below.
After a GAP all normal transactions are closed. File transactions
are left open as they can handle GAPs in principle. However, the
GAP might have contained the closing of a file and therefore it
may remain active until the end of the flow.
This patch introduces a time based heuristic for these transactions.
After the GAP all file transactions are stamped with the current
timestamp. If 60 seconds later a file has seen no update, its marked
as closed.
This is meant to fix resource starvation issues observed in long
running SMB sessions where packet loss was causing GAPs. Due to the
similarity of the NFS and SMB parsers, this issue is fixed for NFS
as well in this patch.
Timo Sigurdsson [Mon, 3 Feb 2020 22:17:17 +0000 (23:17 +0100)]
init: Fix dropping privileges in nflog runmode
Using the run-as configuration option with the nflog capture method
results in the following error during the startup of suricata:
[ERRCODE: SC_ERR_NFLOG_BIND(248)] - nflog_bind_pf() for AF_INET failed
This is because SCDropMainThreadCaps does not have any capabilities
defined for the nflog runmode (unlike other runmodes). Therefore, apply
the same capabilities to the nflog runmode that are already defined for
the nfqueue runmode. This has been confirmed to allow suricata start
and drop its privileges in the nflog runmode.
Better handle case where pcap file receive thread fails to initialize. Allow
initialize to complete, but terminate the thread quickly. Delay exiting
unix socket runmode as late as possible.
Victor Julien [Tue, 21 Jan 2020 11:20:40 +0000 (12:20 +0100)]
smb: handle file transactions post-GAP
After a GAP all normal transactions are closed. File transactions
are left open as they can handle GAPs in principle. However, the
GAP might have contained the closing of a file and therefore it
may remain active until the end of the flow.
This patch introduces a time based heuristic for these transactions.
After the GAP all file transactions are stamped with the current
timestamp. If 60 seconds later a file has seen no update, its marked
as closed.
This is meant to fix resource starvation issues observed in long
running SMB sessions where packet loss was causing GAPs.
Jason Ish [Fri, 13 Dec 2019 15:14:35 +0000 (09:14 -0600)]
github-ci: use container for 18.04 build
As the action runs natively on 18.04 we were not explicitly
setting a container, but this means we're using what GitHub
provides us as a default state which might be broken. Instead
use the standard Ubuntu 18.04 container.
Jeff Lucovsky [Tue, 26 Mar 2019 21:30:09 +0000 (14:30 -0700)]
decode: Change return type of IPv4 and TCP options decode
The return value from the options decoder in TCP and IPv4 is ignored.
This commit changes the return type of the function to `void` and
modifies existing return points to return without a value.
When an error occurs, the packet state is being set to indicate whether
it's valid or not and the existing return value is never used.
Victor Julien [Thu, 21 Nov 2019 13:47:04 +0000 (14:47 +0100)]
stream: fix SYN_SENT RST/FIN injection
RST injection during the SYN_SENT state could trick Suricata into marking
a session as CLOSED. The way this was done is: using invalid TSECR value
in RST+ACK packet. The ACK was needed to force Linux into considering the
TSECR value and compare it to the TSVAL from the SYN packet.
The second works only against Windows. The client would not use a TSVAL
but the RST packet would. Windows will reject this, but Suricata considered
the RST valid and triggered the CLOSED logic.
This patch addresses both. When the SYN packet used timestamp support
the timestamp of incoming packet is validated. Otherwise, packet responding
should not have a timestamp.
Victor Julien [Fri, 8 Nov 2019 11:09:24 +0000 (12:09 +0100)]
threading: fix shutdown race condition
A BUG_ON statement would seemingly randomly trigger during the threading
shutdown logic. After a packet thread reached the THV_RUNNING_DONE state,
it would sometimes still receive flow timeout packets which would then
remain unprocessed.
1 main: TmThreadDisableReceiveThreads(); <- stop capturing packets
2 worker: -> TmThreadTimeoutLoop (THV_FLOW_LOOP) phase starts
3 main: FlowForceReassembly(); <- inject packets from flow engine
4 main: TmThreadDisablePacketThreads(); <- then disable packet threads
5 main: -> checks if 'worker' is ready processing packets
6 main: -> sends THV_KILL to worker
7 worker: breaks out of TmThreadTimeoutLoop and changes to THV_RUNNING_DONE.
Part of the problem was with (5) above. When checking if the worker was
already done with its work, TmThreadDisablePacketThreads would not consider
the injected flow timeout packets. The second part of the problem was with (7),
where the worker checked if it was ready with the TmThreadTimeoutLoop in a
thread unsafe way.
As a result TmThreadDisablePacketThreads would not wait long enough for the
worker(s) to finish its work and move the threads to the THV_RUNNING_DONE
phase by issuing the THV_KILL command.
When waiting for packet processing threads to process all in-flight packets,
also consider the 'stream_pq'. This will have received the flow timeout
packets.