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

[Iván Arce]

On 2/9/12 12:56 AM, Fernando Gont wrote:
> On 02/08/2012 12:51 PM, Iván Arce wrote:
>>>> 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.
>>>
>>> Como habria de leakear la info del contador de *A con B*? (o es que te
>>> referias a "la info del contador de *B* con *A*?)
>>
>> No, me refería exactamente a lo que escribí, no querés que B filtre
>> información sobre el contador que tiene A para generarle frag IDs a B.
> 
> Este ataque no lo habia considerado, así que "buen punto" (valido).
> 
> Mas alla de eso, este caso particular es "cuestionable". 

Cuestionable en que sentido? A los atacantes no les interesa la
elegancia  o prolijidad de sus ataques, simplemente que sirvan para sus
propósitos, lo demás es accesorio.

> Lease: la
> gracia del idle scan es que al atacante (M) puede escanear un host A,
> sin siquiera enviar nada al mismo, utilizando un zombie (B) (lease, un
> scanneo "stealth").

No es exactamante así. En un Idle Scan, M (atacante) envia datagramas
spoofeados -segmentos TCP con SYN=1 para ser precisos- a A (blanco) con
la dirección origen de B (zombie), ese es el mismo tipo de escenario
sobre el que escribi en mi mail anterior.

>>
>> 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 que usando el
canal encubierto del contador de B no existe manera de determinar el
valor de los frag IDs que genera A.  Requerir un ejemplo concreto de
explotación para decidir atender el problema y cerrar el canal es una
respuesta clásica de muchos de los que vos y yo criticamos por su forma
de atender la temática de seguridad.

En todo caso, como hago en situaciones similares, te devuelvo la pelota
a vos: Demostrá que el canal encubierto no se puede usar para determinar
los Frag Id y yo me quedo tranquilo con la recomendación de un contador
por destino inicializado aleatoriamente.

>>>> 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. 
>>>
>>> No entiendo porqué decís esto. En el caso en cuestión, lo unico que se
>>> le transfiere a B es el valor del proximo Frag ID a ser utilizado *con B*
>>
>> Si, pero el hecho de que B use un contador global que se incrementa
>> predeciblemente crea un canal encubierto que le permitiria a un
>> tercero *off path* inferir ese valor sin necesidad de verlo.
> 
> Como mencionaba arriba, lo que pueda hacer un tercero off-path es
> inferir que (por ej.) A incremento su Frag ID enviado a B... pero *no*
> adivinar el valor en si.

Reitero, no hay que pensar en que no vale la pena tratar de resolver una
debilidad de diseño sólo porque no se nos ocurre una implementación
específica que la explota. Esa es una historia conocida incluso por
aquellos que escriben RFCs que vieron como años después de haber escrito
los RFCS algunos finalmente encontraron la forma de explotar las
debilidades de diseño introducidas décadas atrás (DNS poisoning y TCP
hijacking son los ejemplos canónicos)

> 
>> Igual lo que tenia en mente cuando cuanto escribi que "el RFC no dice
>> esto es un contador" es la definición similar y ahora creo que menos
>> confusa de IP ID en IPv4 (RFC791).
> 
> Vos decis? Yo acabo de pasar por encima de RFC791, y en tal sentido ni
> siquiera sugiera que el IP ID se pueda implementar como un contador....
> -- o sea, en tal sentido, RFC2460 creo que guia en peor direccion que
> RFC791 (que no guia demasiado en nngun sentido :-) ).

Si, eso es lo que escribí en el párrafo que citás, tal vez no me
explique bien. Aclaro entonces:

El RFC791 es menos confuso al respecto del IP ID que el RFC2460 al
respecto del Frag ID.

> 
>> De hecho, dos fragmentos con el mismo Frag ID y con Offset=0
>> calificarían como solapados en ese contexto (por mas que uno tenga MF=1
>> y otro MF=0).
> 
> Tal cual. Se supone que el I-D que yo escribi "actua primero" que RFC
> 5722. -- Lease, que si un fragmento es atomico, no lo consideras
> realmente un fragmento... y entonces simplemente removes el Frag Header,
> y listo..
> 
> 
> 
>> Por otro lado, el RFC 5722 tampoco habla de solapamiento de headers
>> antes de la parte fragmentada, algo que yo creo talvez tambíen debería
>> considerar como un problema.
> 
> Si, aunque... como habrías de chequear esto?
> 
> O sea, e el caso legitimo, cada uno de los fragmentos tiene todos los
> mismo ext headers. Si vos queres prevenir que distinos fragmentos puedan
> tener un set de fragmentos y opciones (pervio a la parte fragmentada),
> entonces no te quedaria otra que comparar byte-a-byte dicha parte de
> cada fragmento con el de los demas. -- y esto sería "overkill".

Uh? Como va a ser overkill si en la situación actual todos los extension
headers antes del fragmento YA se estan procesando.

> 
> O sea, comparto en principio tu planteo, pero... es "realizable"?

No veo porque no, es tan realizable como las otras cosas que ya se están
realizando. No hay un impedimento técnico que prevenga cambiar el
comportamiento de IPv6 en el caso de fragmentación, es simplemente
cuestión de evaluar técnicamente las diversas opciones y tomar una
decisión "política" al respecto. Yo no soy parte del IETF ni me muevo en
el mundo de la gente que escribe, revisa o aprueba RFCs así que
no puedo determinar que tan "realizable" es mi planteo.

Por otro lado yo no propuse ninguna solución concreta sino que señale un
problema en la especificación actual. Para proponer una solución hay que
tomarse el tiempo adecuado para diseñarla, analizarla y probarla cosa
que yo no hice.


>>
>> En que situación normal podría un host generar, a partir de un datagrama
>> original, dos datagramas fragmentados y con solapamiento cada uno de
>> ellos con extension headers distintos antes de la parte fragmentada? 
> 
> -- En ninguno.
> 
> 
> 
>> No
>> se... me parece rarisimo y sin embargo es un condición aceptable por
>> todos los RFC.
> 
> Coincido con vos. Ahora bien: existe alguna manera razonable de prevenirlo?
> 
> Porque en este caso no alcanza con chequear la existencia de
> determinados extension headers, sino tambieén su contenido. (COmo
> atacante, obviamente te enviaria fragmentos con toneladas de extension
> headers delante de la parte fragmentada).
> 
> Y si apra cada fragmento vas a hacer semejante procesamiento, la
> "solución" termina siendo peor que el problema.

Los stacks IPv6 actuales YA procesan todos los campos de todos los
extensión headers que vienen antes de la parte fragmentada así que no
veo de que manera se agravaría el problema ya existente.
Por otro lado, un atacante ya puede hacer lo que vos decís así que por
ahí tampoco veo un agravamiento del problema.

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). Habría que ver si eso es lo mejor o
lo único que se puede hacer para encarar el problema, cuales son los
potenciales efectos negativos y como mitigarlos.

-ivan