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

Iván Arce ivan.w.arce en gmail.com
Lun Feb 13 13:10:24 BRST 2012


On 2/13/12 12:52 AM, Fernando Gont wrote:
> 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.

Talvez era ingenioso hace 25 o 15 años, hoy es simplemente que uno de
los trucos conocidos para revelar un secreto usando un oráculo.


> 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)

NO

EL problema de generar Frag IDs y el problema de procesar fragmentos
atómicos ERAN ORTOGONALES NO? Entonces es falaz argumentar que
implementar la recomendación del draft sobre "atomic fragments" sea una
forma legítima de evitar un ataque contra la recomendación del draft de
"predictable fragment id".

El argumento es doblemente falaz porque además estás suponiendo que
quien implementa el draft sobre atomic fragments es el *host B*. Es
decir, el *host A* implementa la recomendación sobre generación de frag
IDs, el *host B* no implementa esa recomendación pero si la (ortogonal)
de atomic fragments y en ese escenario específico el ejemplo que yo dí
no funciona...

Mas allá de eso, existirá alguna forma de lograr lo mismo (conocer el
contador de A con B) aún en el caso en que el host B implementa la
recomendación sobre "atomic fragments" ? Hay apuestas al respecto?
cuanto paga un ataque en ese escenario?

>, 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?).

Hmm no se, se te ocurre porque no esta bueno hacer brute force de todo
el espacio de claves cuando tenes un oráculo que te puede ayudar a
adivinar no solo la clave actual sino también *la próxima*?

Además pensá, por ejemplo, que M tiene la capacidad de hacer que A
genere una cantidad arbitraria de Frag ID (incremente el contador tanto
como quiera M) y eso se podría combinar con la generación de datagramas
spoofeados para hacer un ataque tipo "birthday" o "meet-in-the-middle".


> 
> 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).
> 

Estrictamente hablando el host A implementa tu recomendación pero
depende de que B  (y cualquier otro host con el que se vaya a comunicar)
también la implemente para que su contador con ese host no sea revelado
a un tercero off-path.

Una mejor recomendación sería alguna en la que tanto el host B como
cualquier otro off-path tengan la misma probabilidad de conocer el
próximo frag ID a utilizar por A. Una solución de compromiso sería una
en la que la probabilidad de B de predecir el próximo Frag ID a utilizar
por A sea "casi la misma" o marginalmente mayor que la de M de hacerlo.

> 
>> 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)

Estoy de acuerdo, pero yo no dije que como lo implementa OpenBSD esta
bien.  Dije que para OpenBSD no hizo falta toda una discusión y perorata
sobre posibles ataques y que ellos directamente hace casi 4 años
decidieron atender el problema y hacerlo con una solución que a priori
no parece tener la misma debilidad de seguridad que la recomendación de
tu draft (puede que tenga otros problemas, pero hasta ahora no he leído
nada que los describa)

. 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...").

Hm interesante, busque "defending against silbersack " y me encontre con
el RFC 6528 del que sos co-autor con Bellovin. Estaría bueno que le
consultes a Bellovin su opinión sobre la recomendación para la
generación de Frag IDs (si querés que participe de la charlar no tengo
problema en hacerlo).

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

si pero ese no es el tema sobre el que estamos hablando.

Señale la implementación de OpenBSD porque el problema es similar al que
yo recuerdo haber discutido largamente con ellos en 1997 cuando
publicamos el security advisory sobre predictibilidad de query IDs de
DNS por un tercero offpath.

>>>> 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.


No, si los fragmentos se solapan después de que falle el reensamblado
los extension headers no se procesarían, en cambio en el caso actual los
extension headers ya se procesaron y recién cuando falla el
re-ensamblado te das cuenta que tal vez no deberías haberlos procesado...

> 
> 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. 

En un mail anterior explique porque si depende... no puede haber
extension headers distintos en fragmentos distintos del mismo datagrama
original si eso sucede es muy probable que estes en presencia de un
ataque y no deberías procesar ese tráfico pero ya es muy tarde para
tomar cualquier decisión.


Igual este es un tema separado (ortogonal) del de generación de frag IDs
así que habría que discutirlo en otro contexto.


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?

Evaluar si la solución actual de OpenBSD es peor o mejor en términos de
seguridad y performance que la que estás proponiendo actualmente. Yo
creo que es  mejor en ambos aspectos y solo tiene un efecto colateral en
términos de alguna probabilidad de colisiones (que hay que estimar pero
que es menor que la de elegir un frag ID random).

Si eso aún no te gusta, ver como funcionaría usar un LCG por destino
inicializado aleatoriamente... (guarda el mismo estado y sólo tiene un
impacto marginalmente superior en performace de CPU)

saludos,
-ivan



Más información sobre la lista de distribución Seguridad