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

[Fernando Gont]

On 02/13/2012 01:10 PM, Iván Arce wrote:

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

Yo dije que la solución a ambos problemas es ortogonal.

Dicho de otro modo: son dos problemas diferentes, y personalmente creo
que hay que solucionar ambos. Y que la solución a uno no tiene que
depender de la solución al otro.

A modo de ejemplo, en el escenario que planteaste, si bien hay
interaccion entre el ataque y el procesamiento de fragmentos atomicos,
yo creo que los Frag ID deben ser lo suficientemente buenos,
independientemente de si el procesamiento de fragmentos atomicos como
tales impiden el ataque mencionado.



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

Yo no dije eso. De hecho, dije bien claro "no hay objeción al respecto"
cuando mencionaste el ataque.

De hecho, mis propuesta al tema de las Frag ID previsibles está en un
IETF I-D diferente al de los fragmentos atomicos.

Mi comentario sobre lo de "con la recomendacion de atomic fragments esto
no funcionaria" fue al margen -- tal vez no la tendria que haber hecho,
directamente.

*Si* comenté que creo que en el punto en el cual el ataque requiere
potencialmente muestrear todo el Frag ID space (en particular cuando
ésto va a afectar a un solo destinto (y vulnerable)), estás tecnicas de
randomizacion empiezan a ser una solución pobre. -- De hecho, vos
podrías estar utilizando *cualquier* algoritmo, pero si yo
puedo enviarte un paquete por cada Frag ID, tengo certeza de generar
colisiones, y de realizarte un ataque de DoS.



> 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" ?

Tal como mencioné arriba, lo de los Frag ID debe solucionarse
idependientemente de que uno implemente o no la recomendacion sobre
"atomic fragments".

Los Frag ID deben ser impredecibles (*). Punto.

(*) *Si* creo que no uno puede establecer limites entre que cosas
considera aceptables, y que cosas no. Por ejemplo, fijate que en
"Defending against..." nosotros recomendamos MD5, pese a los problemas
que se conocen sobre MD5.

Aca hay algo similar. Un puede/debe analizar si escenarios como el
discutido es algo que uno tiene intencion de mitigar. En el escenario en
cuestión, corre peligro una comunicacion con un sistema vulnerable, y la
divinacion del Frag ID solo afecta las comunicaciones con dicho sistema
(además de potencialmente requerir el muestreo de todo el Frag ID space).

Esto puede o no ser un "concern". Y de acuerdo a que lo sea o no puede
ayudar en la decisión de que algoritmo utilizar.



> Hay apuestas al respecto? cuanto paga un ataque en ese escenario?

Mi respuesta es "No lo sé. Yo no me puse a buscarlo. En cualquier caso,
no haberlo encontrado yo no quita que otro *si* pueda hacerlo".



>> , 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*?

En el escenario en cuestión, si B tiene una implementación de Frag ID
pobre (Frag ID globales) el escenario discutido seria mi ultimo concern.
De hecho, en gral las comunicaciones son bidireccionales, y en tal caso
como atacante yo no atacaría el flujo de A a B, sino el flujo de B a A.


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

De acuerdo con ello. Ahora bien, incluso en el caso que el contador es
revelado, solo afecta comunicaciones que involucran a un host vulnerable
(B)... En cuyo caso, en la mayoría de los casos uno puede lograr el
mismo objetivo (DoS) con mucho menos trabajo atacando directamente al
host vulnerable (B).



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

En tal caso, y sin pensarlo demasiado, no se me ocurre otra cosa que
randomizarlo.



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

El problema acá es que hay dos cuestiones: interoperabilidad, y seguridad.

Si uno mira simplemente el aspecto de seguridad, está mas que claro que
uno randomiza los Frag ID, y se acabo el problema.

Cuando uno pasa a considerar las cuestiones de interoperabilidad, la
cuestión cambia.

OpenBSD tiene varias cosas en las que pareciera ser que las decisiones
ponen en segundo lugar el aspecto de interoperabilidad (TCP ISNs, TCP
timestamps, TCP randomization, etc., etc.), en ocasiones innecesariamente.

Personalmente, creo que si uno pudiera considerar los 32 bits del Frag
ID como usables, entonces es "aceptable" randomizarlos... con el esquema
que sea. -- en el punto en el cual esto se hace un problema,
directamente no deberias estar utilizando fragmentación.

Ahora bien, cuando el largo efectivo del Frag ID es de 16 bits, ahi la
cosa se hace mas jodida, y las colisiones se hacen mucho mas probables.

Entonces uno pasa a tener requerimientos un tanto incompatibles: Frag ID
impredecibles (por seguridad), y predecibilidad en el sentido de que la
frecuencia de reuso de los Frag ID sea baja.

No digo que sea necesaria la "perorata" sobre tipos de ataques. Pero
*si* creo que es necesario tomar en cuenta otros factores aparte del de
seguridad.



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

Lo haré (nota: en base a experiencias pasadas, aclaro que pueden haber
RTTs elevados).

Por cierto, te referís a preguntar sobre la recomendación actual del ID,
sobre todas, o que?


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

Tal vez me haya perdido en la discusión, pero en el advisory del '97
Uds. recomendaban un LCG, pero eso fue luego cambiado en respuesta al
trabajo de Amit Klein? O es que dicho esquema se mantuvo incluso despues?



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

En realidad, el procesamiento dede acuerdo a la semantica actual, *si*
deberias haberlos procesado. Con el mismo criterio, también podrías
esperar por ej., a minimamente chequear los checksum de TCP o ICMPv6 (o
los numeros de secuencia) antes de procesar los extension headers.

Se supone que los headers que estan antes de la parte fragmentada son
validos independientemente del payload. Si uno no deseara esto, entonces
directamente deberia prohibir headers delante de la parte fragmentada --
especialmente el "Destination Options" header.



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

En ocasiones, el procesamiento actual puede ser deseable. Por ejemplo,
si el paquete incluyera un header u opcion no soportado, podría ser de
interes obtener una respuesta asap, en vez de esperar a que se procese
todo el paquete.

Asimismo, también está la cuestion de "donde uno dibuja la linea": SI
vos ya procesaste todos los headers, y luego encontras que el TCP SEQ es
incorrecto, en cierta medida tambien "no deberias haber procesado nada,
pero ya es demasiado tarde".



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

A menos como primera impresión, creo que la solucion de OpenBSD cae
dentro de la categoría "Frag ID generado con un PRNG".

En tal sentido, se me ocurre que uno podría plantear la generacion del
frag ID con un PRNG como una de las opciones posibles, indicando que en
la eleccion del PRNG seguramente habra un tradeoff de performance,
simplicidad, predictibilidad de los nros, etc.

Creo que elegir un algoritmo especifico seria tal vez sobreespecificar
esta cuestión, al mismo tiempo que realmente desconozco los detalles y
existencia de otros algoritmos que pudieran ser aceptables para este
caso -- y existiendo los mismos, sería algo complicado justificar
"porque uno, y no el otro". -- *Si* creo que uno pudiera mencionar que
algoritmos eligieron algunas implementaciones (como por ej OpenBSD), a
modo de guia.



> Si eso aún no te gusta,

Lo que a mi me gusta es llegar a la mejor solucion posible, considerando
todos los factores. No tengo problema alguno en cambiar todo el I-D, si
es que se hace necesario. -- de hecho, cuando he podido, siempre he
intentado que revisen mis trabajos quienes sabían que me iban a ser mas
críticos.

No me interesa que el resultado final sea distinto al original, si es
que la version final va a ser *mejor*.

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