[LACNIC/Seguridad] Processing of IPv6 "atomic" fragments (Fwd: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-00.ext)

[Fernando Gont]

On 02/12/2012 11:38 PM, Iván Arce wrote:

> Si, ese es el tipo de escenario al que hago referencia y creo que
> estamos progresando en el analisis pero falta atribuirle un poco mas de
> malicia a M... Por ejemplo, Que pasa si M tambien spoofea el datagrama
> #4 con un Frag Id de su elección?
> 
> Esta este caso:
> 
>      A                         B                                M
> #4  ---- SYN/ACK, FID=9000 --->
> #4'				<---- SYN/ACK, FID=42 src = A---
> #5  <---- RST, FID= 5001 -----
> #5' <---- RST, FID= 5002 -----
> #6                             <-------- Echo Req #2 ----------
> #7                             ---- Echo Resp #2, FID= 5003 -->
> 
> 
> Y también este:
> 
>      A                         B                                M
> #4  ---- SYN/ACK, FID=9000 --->
> #4'				<---- SYN/ACK, FID=9000 src = A---
> ... (RFC5722)
> #6                             <-------- Echo Req #2 ----------
> #7                             ---- Echo Resp #2, FID= 5001 -->
> 
> Con lo cual podemos afirmar que existe al menos una manera para M de
> determinar no solo si el contador de A se incrementa o no, sino tambien
> el valor exacto de ese contador.

Realmente es algo ingenioso -- no hay objecicón al respecto.

Sin embargo, mas alla de los "pequeños detalles" (los fragmentos serían
atómicos, y por ende ningún fragmento sería descartado, entonces el
ataque no funcionaría), la cuestión acá es que para adivinar el Frag ID
potencialmente tendrías que "muestrear" el espacio del Frag ID completo
(en cuyo punto, casí-casi uno argumentaria: por que no trashear todo el
Frag ID space, y listo?).

Ajeno a eso, en el escenario que descibís, "B" es quien tiene una
implementación defectuosa, y es una comunicacion de "B" quien termina
pagando por ello (lease, quien tiene la implementación pobre paga el
precio). (si si, estrictamente hablando, los paquetes vienen de A...
pero se entiende).

Aclaro, por si ahce falta, que esto *no* es un argumento para no
utilizar algun algoritmo alternativo.



>>>>> Lo que estoy diciendo es que la recomendacion solo atiende parcialmente
>>>>> el modelo de ataque que describis. B no quiere adivinar nada porque ya
>>>>> sabe pero tampoco quiere que  M lo use para adivinar que Frag ID le va
>>>>> a mandar A, porque eso le daría a M, un atacante off-path, la
>>>>> posibilidad de interferir en las comunicacioens entre A y B.
>>>>
>>>> Por lo que veo de tu ejemplo, lo unico que puede hacer M es detectar
>>>> incrementos en los Frag ID de A a B... pero *no* adivinar el valor en si.
>>>
>>> Bueno, yo no me animaría a afirmar de manera tan tajante
>>
>> Bueno, "por lo que veo de tu ejemplo" no es tajante. :-) 
> 
> Mi ejemplo no necesita ser tajante. 

No fue eso lo que quise decir. Lo que quise decir es que en ningun
momento yo fui tajante. Y mencione que nunca dije "es imposible tal
cosa", sino, mas bien "por lo que veo de tu ejemplo"... y que esa
expresión no es una expresion tajante.


> Esa es la diferencia entre señalar
> un falla de diseño que debilita la seguridad de un sistema y afirmar que
> la falla de diseño no es relevante porque no hay forma conocida (por
> quien hace la afirmación) de explotarla.

Coincido.

Tal como te dije, simplemente quise ver tu planteo, ya que en este caso
optar directamente por "random()" tiene sus implicancias. Nada mas.



> Los que se preocupan por la seguridad lo suficiente como para aceptar
> una degradación en performance a cambio de cerrar una *potencial* vía de
> ataque ya tienen suficiente información como para tomar una decision.
> 
> Algunos ya la tenían hace tiempo... OpenBSD por ejemplo decidio general
> los frag ID usando una *sequencia* pseudoaleatoria hace 3 años y 8 meses:
> 
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/ip6_id.c?rev=1.7;content-type=text%2Fx-cvsweb-markup

Nota: La implementación de algo no es necesariamente de buena elección
(pese a la reputación del OS en cuestión). Por ej., FreeBSD implementó
en algun momento el mismo (?) algoritmo de randomización de puertos que
OpenBSD, y tuvieron que hacer una tramoya porque los usuarios empezaron
a reportar colisiones (ver la referencia al trabajo de Silbersack en
reciente RFC sobre "Defending Against...").

Asismismo, OpenBSD randomiza los puertos, y utiliza un rango
ridiculamente pequeño.



> a ese procesamiento habria que agregarle una
>> comparación byte-a-byte entre los ext headers del primer fragmento, y
>> los ext headers del resto de los fragmentos.
> 
> uh?? En ningun momento propuse que se verifique que todos los extension
> headers del primer fragmento esten presentes y sean iguales que los de
> todos los demas fragmentos.

Yo habia entendido que habias propuesto eso -- de ahi mi comentario.



>>> Me parece que estás pensando en alguna solución que yo no propuse :)
>>> como por ejemplo encolar todos los datagramas fragmentados y procesar
>>> los headers antes y después de la parte fragmentada recién después de
>>> hacer el reensamblado (esto si crearía el potencial de degradación de
>>> performance por consumo de memoria).
>>
>> -- Esto, en principio, no lo veo como tan problematico. 
> 
> No? Yo si veo potenciales problemas y no tengo suficientes conocimientos
> de IPv6 como para evaluar el efecto sobre el protocolo (mas alla del
> impacto en performance) de procesar extension headers despues reensamblado.

La fragmentación en si es una m* (en materia de performance, de implicar
estado en el receptor, etc., etc.). Si realmente tenes que caer en
fragmentación, ya estas bastante jodido -- yo soy de la idea de evitarla
(de ahi por ej lo de los "atomic fragments").

Lo que digo es que no veo, en este caso particular, nada mas jodido al
uso de fragmentación en sí. Se me ocurre que la única diferencia es que
en este caso se podría consumir mucho CPU "de golpe", ya que "dejar todo
para después" termina teniendo como un "efecto capacitivo". -- Pero esto
mismo podrías lograrlo incluyendo todos los headers en la parte
fragmentada, de modo que se procesen todos los headers cuando los
fragmentos se reensamblan.

Es decir, no pareciera que esto agregue un nuevo tipo de ataque.

Dicho eso, personalmente no me convence mucho el hecho de implementar
esto. Y el motivo es que básicamente que se está cambiando la semantica
de los headers. Es decir, lo que viene pervio al Frag Header entra en
juego antes de la Fragmentación, y su validez no depende de lo que viene
despues. Sino, con ese criterio en algun momento alguien va a querer por
ej. chequear los numeros de secuencia TCP antes de procesar otras
opciones del Protocolo IPv6, o cosas similares. (si, está claro que esto
ultimo es mas dificil que alguien lo pronponga, ya que se estarían
mezclando dos protocolos.... pero creo que ilustra mi "punto").

P.S.: En vistas de una próxima revisión de
draft-gont-6man-predictable-id
(http://tools.ietf.org/html/draft-gont-6man-predictable-fragment-id-00)...
que sugerís?

Saludos, y gracias!
-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492