Project

General

Profile

Actions

Bug #4664

closed

Bug #3323: tracking: ipv6 evasions

ipv6 evasions : fragmentation

Added by Philippe Antoine about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs backport to 5.0, Needs backport to 6.0

Related issues 2 (0 open2 closed)

Copied to Bug #4728: ipv6 evasions : fragmentationClosedShivani BhardwajActions
Copied to Bug #4729: ipv6 evasions : fragmentationClosedJeff LucovskyActions
Actions #1

Updated by Philippe Antoine about 1 year ago

frag-5 is not an evasion for me :
We have a valid reassembly of 3 fragments, for an ICMPV6 ping
then the reply
Then a replay of one of the fragments (but Suricata must have forgotten it and interprets it as a new reassembly to do)

Actions #2

Updated by Philippe Antoine about 1 year ago

frag-13 is not an evasion for me.
It is simply a big reassembly leading to a payload of 65494 bytes
RFC2460 states

If the length and offset of a fragment are such that the Payload

Length of the packet reassembled from that fragment would exceed
65,535 octets, then that fragment must be discarded and an ICMP
Parameter Problem, Code 0, message should be sent to the source of
the fragment, pointing to the Fragment Offset field of the
fragment packet.

The pcap is below that limit of 65535, which is implemented in Suricata cf IPV6_FRAG_PKT_TOO_LARGE

Zeek however uses 64000 cf https://github.com/zeek/zeek/blob/5d38bb029a45c28e01fe55c9734b7b58d3d0e1fa/src/Frag.cc#L14
And the name is misleading as all fragments have a size of 1232 bytes, it is their reassembly that exceeds 64000 bytes

Actions #3

Updated by Philippe Antoine about 1 year ago

frag-14 is the same as frag-13

frag-19 is simply a fragment without another to end reassembly...

Actions #4

Updated by Philippe Antoine about 1 year ago

  • Status changed from Assigned to In Review
Actions #5

Updated by Philippe Antoine about 1 year ago

The PR https://github.com/OISF/suricata/pull/6367 solves the case ipv6-malformed-fragments-8 where we have

mf true frag_offset 0 data_offset 62, data_len 408, frag_end 408, ip_hdr_offset 14, frag_hdr_offset 54
mf false frag_offset 808 data_offset 62, data_len 400, frag_end 1208, ip_hdr_offset 14, frag_hdr_offset 54
mf true frag_offset 408 data_offset 62, data_len 528, frag_end 936, ip_hdr_offset 14, frag_hdr_offset 54

and no overlap is given when last fragment [408:936] overlaps with previous one [808:1208]

Actions #6

Updated by Philippe Antoine about 1 year ago

  • Status changed from In Review to Closed
  • Target version changed from TBD to 7.0.0-beta1
  • Label Needs backport to 5.0, Needs backport to 6.0 added
Actions #7

Updated by Jeff Lucovsky about 1 year ago

  • Copied to Bug #4728: ipv6 evasions : fragmentation added
Actions #8

Updated by Jeff Lucovsky about 1 year ago

  • Copied to Bug #4729: ipv6 evasions : fragmentation added
Actions

Also available in: Atom PDF