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.
Redmine ticket:
https://redmine.openinfosecfoundation.org/issues/1708
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.
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
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.
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.
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.
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.