Eric Leblond [Tue, 1 Mar 2016 13:59:13 +0000 (14:59 +0100)]
app-layer-smtp: fix memory leak
This patch fixes the following leak:
Direct leak of 9982880 byte(s) in 2902 object(s) allocated from:
#0 0x4c253b in malloc ??:?
#1 0x10c39ac in MimeDecInitParser /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/util-decode-mime.c:2379
#2 0x6a0f91 in SMTPProcessRequest /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/app-layer-smtp.c:1085
#3 0x697658 in SMTPParse /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/app-layer-smtp.c:1185
#4 0x68fa7a in SMTPParseClientRecord /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/app-layer-smtp.c:1208
#5 0x6561c5 in AppLayerParserParse /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/app-layer-parser.c:908
#6 0x53dc2e in AppLayerHandleTCPData /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/app-layer.c:444
#7 0xf8e0af in DoReassemble /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp-reassemble.c:2635
#8 0xf8c3f8 in StreamTcpReassembleAppLayer /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp-reassemble.c:3028
#9 0xf94267 in StreamTcpReassembleHandleSegmentUpdateACK /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp-reassemble.c:3404
#10 0xf9643d in StreamTcpReassembleHandleSegment /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp-reassemble.c:3432
#11 0xf578b4 in HandleEstablishedPacketToClient /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp.c:2245
#12 0xeea3c7 in StreamTcpPacketStateEstablished /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp.c:2489
#13 0xec1d38 in StreamTcpPacket /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp.c:4568
#14 0xeb0e16 in StreamTcp /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/stream-tcp.c:5064
#15 0xff52a4 in TmThreadsSlotVarRun /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/tm-threads.c:130
#16 0xffdad1 in TmThreadsSlotVar /home/victor/qa/buildbot/donkey/z600fuzz/Private/src/tm-threads.c:474
#17 0x7f7cd678d181 in start_thread /build/buildd/eglibc-2.19/nptl/pthread_create.c:312 (discriminator 2)
We come to this case when a SMTP session contains at least 2 mails
and then the ending of the first is not correctly detected. In that
case, switching to a new tx seems a good solution. This way we still
have partial logging.
Eric Leblond [Tue, 1 Mar 2016 14:44:27 +0000 (15:44 +0100)]
app-layer-smtp: fix mem leak and add new alert
If SMTP session is weird then we may reach a state where a field
like MAIL FROM is seen as duplicated.
Valgrind output is:
30 bytes in 1 blocks are definitely lost in loss record 96 of 399
at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4A5803: SMTPParseCommandWithParam (app-layer-smtp.c:996)
by 0x4A4DCE: SMTPParseCommandMAILFROM (app-layer-smtp.c:1016)
by 0x4A3F55: SMTPProcessRequest (app-layer-smtp.c:1127)
by 0x4A1F8C: SMTPParse (app-layer-smtp.c:1191)
by 0x493AD7: SMTPParseClientRecord (app-layer-smtp.c:1214)
by 0x4878A6: AppLayerParserParse (app-layer-parser.c:908)
by 0x42384E: AppLayerHandleTCPData (app-layer.c:444)
by 0x8D7EAD: DoReassemble (stream-tcp-reassemble.c:2635)
by 0x8D795F: StreamTcpReassembleAppLayer (stream-tcp-reassemble.c:3028)
by 0x8D8BE0: StreamTcpReassembleHandleSegmentUpdateACK (stream-tcp-reassemble.c:3404)
by 0x8D8F6E: StreamTcpReassembleHandleSegment (stream-tcp-reassemble.c:3432)
Jason Ish [Tue, 1 Mar 2016 20:36:17 +0000 (14:36 -0600)]
dcerpc: fix memory leak when called from smb
When DCERPC was wrapped in SMB it wasn't being initialized or
cleaned up properly. To fix, expose DCERPC initialization and
cleanup functions for use by the SMB application layer.
Andreas Herz [Mon, 29 Feb 2016 21:37:24 +0000 (22:37 +0100)]
rule-parsing: quick fix for rules with wrong double quotes
The stripping of leading and trailing "s has issues with rules like the
ones described in issue 1638 thus resulted in crashing the rule parser.
So for now this is a quick fix which approaches this issue directly by
stripping those "s correctly and handling error cases. It also adds the
skip for leading spaces at the msg keyword and worksaround a possible
null pointer dereference (that should never occur though).
A more general approach should be done in the future.
Andreas Herz [Thu, 25 Feb 2016 20:33:36 +0000 (21:33 +0100)]
nfqueue: fix wrong return value check in error cases
The check for the return value was wrong, we have 0 for success and 1
(and 2) for the error cases like TM_ECODE_FAILED, so we should quit
unless TM_ECODE_OK (0) is returned for NFQInitThread. This fixes #1870
DIALLO David [Thu, 25 Feb 2016 09:37:52 +0000 (10:37 +0100)]
modbus: fix compiler uninitialized warnings with -Wmaybe-uninitialized
All variables are initialized thanks to ModbusExtractUint8 or ModbusExtractUint16
function that extracts 8bits or 16bits data from pointer the received input data.
In case of extracting error (because of length), ModbusExtractUint8 or
ModbusExtractUint16 returns an error that is managed by the caller function.
All variables are now initialized to zero when they are declared. It does not
change anything functionnally but it removes Modbus warnings.
Giuseppe Longo [Wed, 24 Feb 2016 08:28:41 +0000 (09:28 +0100)]
http: close file when http body limit is reached
In some conditions, if stream.reassembly.depth is greater than
request/response-body-limit size, the logging output is wrong
if filestore keyword is used with http.
For example, we get:
{... "app_proto":"http","fileinfo":{"filename":"\/file.pdf","state":"CLOSED","stored":false,"size":1049292,"tx_id":0}}
"state":"CLOSED","stored":false should be "state":"TRUNCATED","stored":true.
This happens because the file state and file flags,
which is the information that determine a correct output,
are not set properly since a file is logged before and then closed (HTPFileClose).
The logic of this patch is to close a file when we are above
the limits, such that the proper state and flags can be set
and the file will be logged correctly.
Andreas Herz [Tue, 23 Feb 2016 22:27:59 +0000 (23:27 +0100)]
build-info: workaround special _FORTIFY_SOURCE defines
On systems like Gentoo where _FORTIFY_SOURCE is already defined like
FORTIFY_SOURCE=((defined __OPTIMIZE && OPTIMIZE > 0) ? 2 : 0) the use
within the printf function (%d) won't result in the correct value and
we end up with 'defined' undeclared compile error. This workaround makes
sure that just the resolved value is checked and then printed.
Victor Julien [Thu, 18 Feb 2016 09:44:14 +0000 (10:44 +0100)]
unix-socket: optimize response sends
Instead of sending responses to clients in small chunks, send it in
one big chunk. For this the JSON message is first serialized into
a MemBuffer before sending.
Jason Ish [Thu, 11 Feb 2016 20:45:23 +0000 (14:45 -0600)]
json: use top-level sensor-name if provided.
Currently the default configuration file contains a "sensor-name"
at the root of the configuration file, however, eve-log will only
use it if its specified under eve-log.
Now we will look for it at the eve-log, if present we'll use it
but log a deprecation warning, if its not present we'll look
for sensor-name at the root of the configuration.
Victor Julien [Tue, 16 Feb 2016 15:50:48 +0000 (16:50 +0100)]
eve: fix mishandling of big messages
When the string representation of a JSON message grew bigger than
64k, the JSON record would just be truncated. This lead to errors
in the parser(s) of the JSON stream.
This patch changes the buffer logic to grow the buffer on demand.
Victor Julien [Fri, 12 Feb 2016 15:31:57 +0000 (16:31 +0100)]
http: fix multipart body tracking slowdown
Optimize HTTP multipart body parsing. Big records that were not files
could slow down Suricata. The reason was that the body tracker was not
moved forward. This lead to growing body buffers, which were expensive
wrt memory and inspection.
This patch add logic to move the tracker forward in this case.
Victor Julien [Fri, 12 Feb 2016 09:54:02 +0000 (10:54 +0100)]
tls-sni: fix uninitialized memory use
On bad traffic the parser could allocated memory that was not
intialized. This was later used in the JSON output logging as
a valid null terminated string.
Victor Julien [Sun, 31 Jan 2016 12:40:07 +0000 (13:40 +0100)]
eve: fix stream payload logging wrong direction
In the EVE stream payload logging the IPS path logged the wrong dir.
Both IDS and IPS can take the same path as the detection engine
inspects in the same direction in both cases, so the alert is also
generated in the same direction.
Maurizio Abba [Mon, 16 Nov 2015 12:21:27 +0000 (12:21 +0000)]
filestore-call: forcing a call to FileStore instead of manually updating
the relative flag in order to have a single point where we actually
touch the File structure