full-disclosure - New IETF I-Ds on Fragmentation-related security issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Thu, 15 Dec 2011 11:45:17 -0300
From: Fernando Gont <fgont@...networks.com>
To: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Cc: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: New IETF I-Ds on Fragmentation-related security
	issues

Folks,

We have published two new IETF I-Ds about fragmentation related security
issues. They mostly focus on the countermeasures/mitigations, but it
should be pretty obvious how you can exploit some of these vectors
against e.g. otherwise *unfragmented* traffic (i.e., you should at the
very least give this a thought, since it's likely to affect you).

The first I-D is entitled "Security Implications of Predictable Fragment
Identification Values"
(http://tools.ietf.org/id/draft-gont-6man-predictable-fragment-id-00.txt).
Its abstract is:

---- cut here ----
   IPv6 specifies the Fragment Header, which is employed for the
   fragmentation and reassembly mechanisms.  The Fragment Header
   contains an "Identification" field which, together with the IPv6
   Source Address and the IPv6 Destination Address of the packet,
   identifies fragments that correspond to the same original datagram,
   such that they can be reassembled together at the receiving host.
   The only requirement for setting the "Identification" value is that
   it must be different than that of any other fragmented packet sent
   recently with the same Source Address and Destination Address.  Some
   implementations simply use a global counter for setting the Fragment
   Identification field, thus leading to predictable values.  This
   document analyzes the security implications of predictable
   Identification values, and updates RFC 2460 specifying additional
   requirements for setting the Fragment Identification, such that the
   aforementioned security implications are mitigated.
---- cut here ----


The second I-D is entitled 'Processing of IPv6 "atomic" fragments'
(http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments-00.txt).
Its abstract is:

---- cut here ----
   IPv6 allows packets to contain a Fragment Header, without the packet
   being actually fragmented into multiple pieces.  Such packets
   typically result from hosts that have received an ICMPv6 "Packet Too
   Big" error message that advertises a "Next-Hop MTU" smaller than 1280
   bytes, and are currently processed by hosts as "fragmented traffic".
   By forging ICMPv6 "Packet Too Big" error messages an attacker can
   cause hosts to employ "atomic fragments", and the launch any
   fragmentation-based attacks against such traffic.  This document
   discusses the generation of the aforementioned "atomic fragments",
   the corresponding security implications, and formally updates RFC
   2460 and RFC 5722 such that the attack vector based on "atomic
   fragments" is completely eliminated.
---- cut here ----

Any feedback will be very appreciated.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@...networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/