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

[Iván Arce]

On Mon Feb  6 19:37:21 2012, Fernando Gont wrote:
>
>> No lo sé pero a
>> priori parecería que si, cosa que no sucedería si el algoritmo
>> recomendado fuera de elegir un número pseudorandom por cada fragmento.
>
> Aca me perdí. Para evitar un idle scan, la cosa es simple: no debe haber
> un contador global. Eso se puede evitar, entonces, o bien teniendo un
> contador por cada destino (o un set de contadores mas o menos grande,
> como por ej 8K o mayor), o bien generando el Frag ID con un PRNG.

No, no es tan simple como parece.

Un contador por destino *no* evita un idle scan si la "maquina zombie" 
que se utiliza para hacerlo  no implementa lo mismo que la maquina 
destino del idle scan.
Mi punto es que la recomendación de tener un contador por destino no 
evita ataques *del tipo* del idle scan, ya que cada destino puede 
filtrar ("leakear") información
sobre el contador de la maquina con la que se esta comunicando. 

Es asi: A y B se comunican con datagramas fragmentados, A implemente la 
recomendacion (contador por destino, inicializado random), B no 
implementa la recomendación (contador global), ahora tenés que 
garantizar que B no filtre información a un tercero  ((M de Mallory, 
que puede comunicarse con ambos a su antojo) sobre el contador de A con 
B ...

Si la recomendación fuera de generar un Frag ID aleatoriamente tanto B 
como cualquier tercero tendrían casi la misma (baja) probabilidad de 
predecir el proximo frag ID que usará A. Digo "casi la misma 
probabilidad" porque en realidad B puede tener toda la sequencia de 
frag IDs usandos por A anteriorimente y un tercero no...

El problema subyacente con el contador por destino es que se esta 
trasfiriendo confianza sobre un secreto (el valor del proximo frag ID) 
a cada destino sin tener garantía de que el destino puede mantener el 
secreto. Es un problema de seguridad informática recurrente en el 
diseño e implementación de muchas cosas en todas las capas.

Si nos ponemos puristas tambien podríamos decir que hay un problema de 
confusión de tipos: El Frag ID tiene que ser un identificador unico 
pero eso no necesariamente implica que tenga que ser un contador (de 
hecho en el RFC no dice esto es un contador...)

>>
>> Otra alternativa es usar un PRNG global y para cada destino guardar los
>> últimos "n" frag IDs usados para asegurarse de no tener colisiones, con
>> 0  <= n <= K. El caso más simple es n := 0
>
> Claro, pero... si vas a guardar "info por destino", por que no,
> directamente, tener un contador por destino?

por lo que explico arriba :)

>
>>>> 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...
>>>
>>> Coincido. *En principio* ("en teoría"), al menos desde la parte
>>> fragmentada en adelante esto se evitaría gracias a lo especificado por
>>> RFC 5722. 
>>
>> Claro pero si se aplica tu recomendación para procesar fragmentos
>> atómicos como si fueran datagramas no fragmentados, el solapamiento
>> desde la parte fragmentada en adelante no se detectaría mas porque el
>> datagrama atómico nunca entra en la cola para el reensamblado.
>
> Correcto. Es cierto que, durante la "transición" hay (en principio) dos
> maneras de interpretar el tráfico, lo cual podría utilizarse para
> inserción/evasión.


No entendi lo de la "transición". Te referis al periodo entre que el 
primer vendor de stack IPv6 implementa tu recomendación y todos lo 
hacen?
O al periodo entre que el primero implementa RFC 5722 y todos los hacen?

>>
>> Esto no me queda claro, en principio se me ocurre que que entre A y B no
>> pueden existir 2 tipos de comunicaciones simultaneas, una con fragmentos
>> atómicos y otra con fragmentos "normales" 
>
> Si.
> Fijate el siguiente caso: Si por ejemplo estuvieras usando cualquier
> aplicación que utilice UDP, es muy probable que necesites fragmentar los
> paquetes (ya sea NFS sobre UDP, o lo que quieras).
>
> EL escenario de "atomic fragments" se da en aquellos casos en los que el
> protocolo de transporte puede "segmentar el data stream" en varios
> apquetes distintos, como es el caso de TCP (y de los protocolos
> "connection-oriented", en gral).
>
>

Claro pero lo que yo escribi es que  no pueden existir 

(dos comunicaciones simultaneas fragmentadas de forma distinta *Y* 
usando el mismo frag ID)

No solo la primera proposicion simple.

>>>
>>> Adivines o no el Frag ID, todo lo que se encuentra previo al Frag header
>>> va a ser procesado por el destinatario. 
>>
>> Claro, pero si el Frag Id es predecible y después encontrás fragmentos
>> solapados con Frag ID válido SABES que estas sufriendo un ataque y que
>> no deberías haber procesado headers que ya procesaste. 
>
> Hacer ésto implicaria cambiar otro aspecto de RFC 2260: lease, no
> requerir el proceso de los paquetes en orden.

no, yo no estoy proponiendo eso, simplemente estoy indicando que en 
presencia de fragmentación y con frag IDs predecibles
el requerimiento de procesar los header previos al  fragment header 
antes de hacer reassembly es peligroso.


-ivan