[LACNIC/Seguridad] Processing of IPv6 "atomic" fragments (Fwd: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-00.txt)
Iván Arce
ivan.w.arce en gmail.com
Vie Feb 3 18:08:34 BRST 2012
Hola
Leí ambos documentos y me parece increíble que estas cosas sigan
sucediendo, particularmente porque dado que el problema de no validar
adecuadamente las diversas variantes de ICMPv4 "unreachable" es
ampliamente conocido como resultado del uso común de una serie de
herramientas de denegación de servicio durante los 90s. Hubiera esperado
que los requerimientos para el procesamiento de ICMPv6 de error fueran
mucho menos ambiguos y mas estrictos que lo que sucedió con v4 y que los
implementadores fueran menos chapuceros.
Con respecto a "draft-gont-6man-predictable-fragment-id", la descripción
del ataque me recordo algo que escribí hace mucho tiempo en relación a
los query IDs de DNS:
http://www.openbsd.org/advisories/res_random.txt
Estoy interesado en entender porque el algoritmo recomendado es de
mantener un contador por dirección de destino e inicializarlo con un
numero pseudo aleatorio y después incrementarlo de a uno en lugar de
mantener un LCG global que vaya generando Fragment IDs de manera pseudo
aleatoria. Creo que ambas soluciones serian viables pero que la
recomendada podría crear la dependencia de que otros hosts también la
implementen (y no tengan un contador global incrementado de a uno) para
evitar ataques similares al idles scan con fragmentos ipv6. Estoy seguro
que esto lo discutieron y analizaron bien antes de terminar con el
algoritmo recomendado, nos contás un poco como fue esa discusión?
Por otro lado, lei la parte correspondiente al Fragment Header del RFC
2460 (http://tools.ietf.org/html/rfc2460#section-4.5) y me llamo la
atención esto:
> The number and content of the headers preceding the Fragment
> header of different fragments of the same original packet may
> differ. Whatever headers are present, preceding the Fragment
> header in each fragment packet, are processed when the packets
> arrive, prior to queueing the fragments for reassembly. Only
> those headers in the Offset zero fragment packet are retained in
> the reassembled packet.
>
> The Next Header values in the Fragment headers of different
> fragments of the same original packet may differ. Only the value
> from the Offset zero fragment packet is used for reassembly.
Parecería que eso abre la puerta a la "inserción y/o solapamiento de
headers" que incluso se procesarían silenciosamente ?! No entiendo del
todo las implicancias de eso en un escenario en el que se usan Fragment
IDs predecibles pero sospecho que no son buenas...
por ejemplo, un datagrama con un routing header espurio y un fragment
header con un ID adivinado podría ser procesado antes del reemsamblado y
posteriormente al momento del reemsamblado darse cuenta que como hay
fragmentos solapados hay que descartar todos los fragmentos, y sin
embargo el routing header espurio ya se proceso...? Incluso creo que no
es estrictamente necesario que los fragmentos se solapen... se podría
mandar un routing header espurio con un fragment header con id
adivinado, MF=1 y un Fragment Offset >0. En este caso la recomendación
de tu draft no sería contraproducente?:
> Additionally, any fragments already queued with the
> same set {IPV6 Source Address, IPv6 Destination Address, Fragment
> Identification} should not be discarded upon receipt of the
> "colliding" IPv6 atomic fragment, since IPv6 atomic fragments do
> not really interfere with "normal" fragmented traffic.
Por otro lado, la seccion 4 del mismo RFC 2460 dice:
> The contents and semantics of each extension header determine whether or
> not to proceed to the next header. Therefore, extension headers must
> be processed strictly in the order they appear in the packet; a
> receiver must not, for example, scan through a packet looking for a
> particular kind of extension header and process that header prior to
> processing all preceding ones.
La posibilidad de adivinar un fragment ID y mandar un paquete spoofeado
con un header espurio invalida la presunción de que todos los headers se
procesan en orden no?
-ivan
On 2/2/12 8:33 PM, Fernando Gont wrote:
> Estimados,
>
> FYI -- recien publicado, luego de haber sido aceptado como elemento de
> trabajo del 6man wg. Disponible en
> <http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-atomic-fragments-00.txt>.
>
> OpenBSD aplicó un parche en respuesta a este I-D hace un par de
> semanas... y es esperable que suceda lo mismo con FreeBSD y otros.
>
> Lectura complementaria:
> <http://tools.ietf.org/html/draft-gont-6man-predictable-fragment-id>
>
> P.S.: Sin esto, es posible realizar ataques de DoS basados en
> fragmentacion contra tráfico que tipicamente no utiliza framentacion
> (como por ejemplo TCP).
>
> Saludos cordiales,
> Fernando
>
>
>
>
> -------- Original Message --------
> Subject: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-00.txt
> Date: Thu, 02 Feb 2012 14:07:13 -0800
> From: internet-drafts en ietf.org
> To: i-d-announce en ietf.org
> CC: ipv6 en ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the IPv6 Maintenance Working
> Group of the IETF.
>
> Title : Processing of IPv6 "atomic" fragments
> Author(s) : Fernando Gont
> Filename : draft-ietf-6man-ipv6-atomic-fragments-00.txt
> Pages : 14
> Date : 2012-02-01
>
> The IPv6 specification 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 some
> implementations as "fragmented traffic". Thus, by forging ICMPv6
> "Packet Too Big" error messages an attacker can cause hosts to employ
> "atomic fragments", and then 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
> fragmentation-based attack vectors against traffic employing "atomic
> fragments" are completely eliminated.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-atomic-fragments-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-ipv6-atomic-fragments-00.txt
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 en ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
Más información sobre la lista de distribución Seguridad