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

[Fernando Gont]

On 02/07/2012 02:47 PM, Iván Arce 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.

Tal cual. De hecho, el Frag ID que importa en un "idle scan" es el del
zombie. El del target es irrelevante.


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

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

Si quisiste decir lo que efectivamente dijiste, no se me ocurre como se
podría leakear esa info. Si lo que quisiste decir es lo otro (lo que
puse entre paréntesis), entonces estamos de acuerdo: "si tus incrementos
son predecibles, entonces podés ser utilizado como zombie en un ataque
de tipo idle scan".


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

Estamos de acuerdo. Pero el "modelo de ataque" es de proteger la
comunicación contra atacantes "off-path". -- Al fin y al cabo, para que
quiere B adivinar que Frag IDs va a usar A *con el mismo*, si al fin y
al cabo, de todos modos los va a ver?



> 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 tuvieras un contador por destino, se podria dar un escenario como el
sigiente:

Comunicacion     Destino        Frag ID
     #1             A             90837
     #2             B             BBBBB
     #3             C              C837
     #4             A             90838
     #5             A             90839
     #6             B             BBBBC
     #7             A             9083A
     #8             C              C838


Donde se supone que cada fila de "Comunicación" es un paquete distinto,
enviado por un host ("M", por ejemplo), al destino especificado.
Las primers tres lineas (#1, #2, #3) contienen los valores de
inicialización aleatorios, que luego simplemente se incrementan.

A modo de ejmplo, entonces, si yo soy "B", y ya recibí el paquete "#2",
obviamente *sé* que el proximo paquete que reciba va a tener el Frag ID
"BBBBC". Sin embargo, esto no me aporta nada para predecir los Frag IDs
utilizados con "A" o "C".



> Es un problema de seguridad informática recurrente en el 
> diseño e implementación de muchas cosas en todas las capas.

Decime si hay algo que me estoy pasando por algo en la explicación de
arriba....



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

Como que no? :-)

De pag 19 de RFC 2460:

---- cut here ----
                        Rather, it is assumed that the requirement can
        be met by maintaining the Identification value as a simple, 32-
        bit, "wrap-around" counter, incremented each time a packet must
        be fragmented.  It is an implementation choice whether to
        maintain a single counter for the node or multiple counters,
        e.g., one for each of the node's possible source addresses, or
        one for each active (source address, destination address)
        combination.
---- cut here ----

Mas alla de eso, un contador es la forma "trivial" de "minimizar" la
frecuencia de reuso de los Frag IDs. (aunque, obviamente, de acuerdo a
como uno implemente el contador, esto tiene sus implicancias de seguridad)


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

Exacto. Aunque, de algun modo, ya estabamos en dicha transición, ya que
algunos OSes (como Linux y Solaris) ya implementaban
"draft-ietf-6man-ipv6-atomic-fragments-00.txt" (esto lo encontré
empíricamente, al publicar la ultima revisión del I-D) -- ver la tablita
del apéndice en el draft en cuestión.


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

Con "fragmentadas de forma distinta" te referis a "con fragmentos
solapados" o a "una instancia con fragmentos atomicos y otra con
fragmentos comunes"?

En principio, todo depende de como generes el Frag ID. Si el Frag ID
esta mal generado (por ej., aleatorizado, y tuvuste tanta mala suerte de
reusar el mismo valor en un periodo corto de tiempo, entonces *si* se
puede dar un escenario como ese).

Dicho de otro modo, uno asume que "dos fragmentos correspondientes a *un
mismo* paquete no pueden estar solapados". Sin embargo, si el Frag ID se
reutiliza demasiado rápido (violando RFC 2460), entonces ya no son "dos
fragmentos correspondientes a *un mismo* paquete".


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

Si, aunque el "riesgo extra"/peligro implica que uno pueda "lograr algo
mas" por hacer que un extension header se procese como parte de un
fragmento aceptado, que como parte de un paquete cualquiera.

Al menos sin pensarlo demasiado, no se me ocurre un escenario en el cual
"puedas hacer algo mas" en un extension header que es parte de un
fragmento, que en un extension header que es parte de un paquete cualquiera.

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