If a subsequent fragment has a lower offset than a previous
one and overlaps, trim off the beginning of the previous
fragment.
Based on an issue reported privately.
The IP protocol was not being used to match fragments with
their packets allowing a carefully constructed packet
with a different protocol to be matched, allowing re-assembly
to complete, creating a packet that would not be re-assembled
by the destination host.
The rules were using the wrong decoder event type, which was
only set in the unlikely event of a complete overlap, which
really had nothing to do with being too large.
Remove FRAG_TOO_LARGE as its no longer being used, an overlap
event is already set in the case where this event would be set.
When defrag creates a new reassembled IP packet, it then passes this
packet to the IP decoder. If this decoder returns an error the packet
is returned back to the packet pool with a call to TmqhOutputPacketpool
This lead to the first problem. The returned packet had it's p->root
pointer set, and it's PKT_TUNNEL flag set. This could cause problems
in TmqhOutputPacketpool, as this may reference the packet referenced
in p->root.
The second and more glaring problem is that the packet that was
returned to the packetpool, was still returned by the Defrag function
and processed further. It would then at the end of it's processing
be returned to the packet pool, which at this point already had a
reference to this packet.
This patch fixes both issues by unsetting the tunnel references and
returning NULL from Defrag in this case.
This fixes:
72 bytes in 3 blocks are definitely lost in loss record 153 of 316
at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x9AF041: SCRadixCreateRadixTree (util-radix-tree.c:430)
by 0x50FF5D: DefragPolicyLoadFromConfig (defrag-config.c:138)
by 0x5129F5: DefragInit (defrag.c:962)
by 0x87ECFD: UnixSocketPcapFilesCheck (runmode-unix-socket.c:386)
by 0x90FEC0: UnixCommandBackgroundTasks (unix-manager.c:430)
by 0x913C6D: UnixManager (unix-manager.c:980)
by 0x9072F3: TmThreadsManagement (tm-threads.c:602)
by 0x68DE283: start_thread (pthread_create.c:333)
by 0x80A6A4C: clone (in /lib/x86_64-linux-gnu/libc-2.21.so)
** CID 1257764: Dereference after null check (FORWARD_NULL)
/src/defrag.c: 291 in Defrag4Reassemble()
** CID 1257763: Dereference after null check (FORWARD_NULL)
/src/defrag.c: 409 in Defrag6Reassemble()
In the error case 'rp' can be both NULL or non-NULL.
To prevent accidental writes into the orignal packet buffer, use
const pointers for the extension header pointers used by IPv6. This
will cause compiler warnings in case of writes.
Until now the time out handling in defrag was done using a single
uint32_t that tracked seconds. This lead to corner cases, where
defrag trackers could be timed out a little too early.
Fix or rather implement handling of unfragmentable exthdrs in ipv6.
The exthdr(s) appearing before the frag header were copied into the
reassembled packet correctly, however the stripping of the frag header
did not work correctly.
Example:
The common case is a frag header directly after the ipv6 header:
[ipv6 header]->[frag header]->[icmpv6 (part1)]
[ipv6 header]->[frag header]->[icmpv6 (part2)]
This would result in:
[ipv6 header]->[icmpv6]
The ipv6 headers 'next header' setting would be updated to point to
whatever the frag header was pointing to.
This would also happen when is this case:
[ipv6 header]->[hop header]->[frag header]->[icmpv6 (part1)]
[ipv6 header]->[hop header]->[frag header]->[icmpv6 (part2)]
The result would be:
[ipv6 header]->[hop header]->[icmpv6]
However, here too the ipv6 header would have been updated to point
to what the frag header pointed at. So it would consider the hop header
as if it was an ICMPv6 header, or whatever the frag header pointed at.
The result is that packets would not be correctly parsed, and thus this
issue can lead to evasion.
This patch implements handling of the unfragmentable part. In the first
segment that is stored in the list for reassembly, this patch detects
unfragmentable headers and updates it to have the last unfragmentable
header point to the layer after the frag header.
Also, the ipv6 headers 'next hdr' is only updated if no unfragmentable
headers are used. If they are used, the original value is correct.
Reported-By: Rafael Schaefer <rschaefer@ernw.de>
Bug #1244.
This patch is fixing an issue in defragmentation code. The
insertion of a fragment in the list of fragments is done with
respect to the offset of the fragment. But the code was using
the original offset of the fragment and not the one of the
new reconstructed fragment (which can be different in the
case of overlapping segment where the left part is trimmed).
This case could lead to some evasion techniques by causing
Suricata to analyse a different payload.
Take VLAN IDs into account when re-assembling fragments.
Prevents fragments that would otherwise match, but on different
VLANs from being reassembled with each other.
When handling error case on SCMallog, SCCalloc or SCStrdup
we are in an unlikely case. This patch adds the unlikely()
expression to indicate this to gcc.
This patch has been obtained via coccinelle. The transformation
is the following:
@istested@
identifier x;
statement S1;
identifier func =~ "(SCMalloc|SCStrdup|SCCalloc)";
@@
x = func(...)
... when != x
- if (x == NULL) S1
+ if (unlikely(x == NULL)) S1
This patch changes the policy of the timeout function by cleaning
every timeouted trackers.
Previous code was only freeing the first tracker and this was resulting
in calling the timeout function continuously. One of my previous patch
has modified the function to avoid to run it more than twice a second.
But as it was not taken into account the fact only the first tracker was
freed, the result was that a lot of tracker could not be allocated.
When nothing can be fetch from the pool, this can repeat frequently.
Thus displaying a message in the log will not help. This patch
uses a counter instead of a log message. As this is a sort of memcap
this is conformed to what is done for other issues of the same type.
Coverity pointed out that PoolReturn is almost like free and detected
a use after free when accessing to tracker->af (issue 720339).
This patch fixes this by storing the value in a local variable.
This patch required a evolution of Pool API as it is needed to
proceed to alloc or init separetely. The PoolInit has been changed
with a new Init function parameter.
This patch fixes the collision issue observed on an intensive network
trafic. When there is fragmentation it is the case for all data
exchanged between two hosts. Thus using a hash func only involving
IP addresses (and protocol) was leading to a collision for all
exchanges between the hosts. At a larger scale, it was resulting in
a packet loss. By using the IP ID instead of the protocol family, we
introduce a real difference between the trackers.
This patch renames DECODER_SET_EVENT, DECODER_ISSET_EVENT and some
other structures to ENGINE equivalent to take into account the fact
the event list is now related to all engines and not only to decoder.
Hello Victor
This patch modifies error treatment following our discussion on IRC.
It tries to follow the error treatment guideline I've been able to
read in the different files.
I will merge this patch in the original commit if the error treatment
seems ok for you.
BR,
Eric
This patch implements the needed modification of payload access
in a Packet structure to support the abstraction introduced by
the extended data system.
- Update unit test to trigger the failure found in the issue 65 pcap.
- Increase pkt buffer to account for the IPv6 header, as a maximum
size IPv6 datagram is 40 + 0xffff.
- Account for IPv4 header when checking where end of fragment lies.
- Second sanity check during re-assembly to check for writing past
the end of the pkt buffer.
Hello,
This is all the rest of the memory leaks I found.
*In src/source-pcap-file.c at line 152, ptv is not being freed.
*In src/util-unittest-helper.c at line 152, p was not being freed.
*In src/log-httplog.c at line 195, aft was not being freed
*In src/counters.c at line 51, log_filename was not being freed. At line 1188
pctx is being tested to see if its NULL. However, at 1173 it exits the
function if it were NULL. This test is not needed and should be deleted.
*In src/defrag.c at line 351, tracker was not being freed. At line 390, dc is
being checked for NULL but this was already done at line 384. Probably what
was meant was checking the value of dc->frag_table which was just assigned.
The patch below makes the above described changes.
-Steve
- Increase the packet buffer so it can hold the link header when we
have maximum size IP datagrams.
- Fix ip header length and pkt length calculation for re-assembled
packets.
Jason Ish
Victor Julien
Eric Leblond
Ken Steele
Jason Ish
Giuseppe Longo
Anoop Saldanha
pilcrow
Gerardo Iglesias Galvan
Anoop Saldanha
William Metcalf
Jason Ish
Pablo Rincon
Steve Grubb