Actions
Bug #1244
closedipv6 defrag issue
Affected Versions:
Effort:
Difficulty:
Label:
Description
Reported privately.
Updated by Victor Julien over 10 years ago
- Subject changed from ipv6 issue to ipv6 defrag issue
- Status changed from Assigned to Closed
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.
Addressed by https://github.com/inliniac/suricata/pull/1088
Actions