[LACNIC/Seguridad] Processing of IPv6 "atomic" fragments (Fwd: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-00.txt)
Iván Arce
ivan.w.arce en gmail.com
Mie Feb 8 13:51:41 BRST 2012
On 2/7/12 6:44 PM, Fernando Gont 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.
El contador de B con A para M es trivial de predecir porque B usa un
contador global, además fijate que esto implica que para M tambien es
trivial spoofearle a A datagramas fragmentados (atomicos o no) con IP
origen B que parezcan legítimos
Si B filtra información sobre el contador que usa A entonces es posible
que M ataque las comunicaciones entre A y B, que teoricamente segun la
recomendación ya no serían susceptibles de ataque porque A ya no genera
frag IDs predecibles por un tercero offpath.
Como habría de hacerlo? y... ya tenes todas las pistas:
Utilizando los frag ID que M recibe de B como un oraculo, se
incrementarán mas o menos dependiendo de si B generó frag IDs para otro
destino (p.e. para A en respuesta a comunicaciones fragmentadas
recibidas de A).
M tiene capacidad de spoofearle paquetes tanto a A como a B y de hacer
que cualquiera de los dos le fragmente paquetes al otro...
>
> 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?
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.
>
>
>
>> 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.
>
> 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.
Bueno, no entiendo tu ejemplo... la tabla solo incluye paquetes
originados por M (el atacante). Pensa un ejemplo en el que A y B se
comunican entre si y M quiere interferir esa comunicacion. Hay 6 tipos
de paquetes:
originado por IP origen IP destino
A A B
B B A
B B M
M M B
M A (spoof) B
M B (spoof) A
A genera Frag IDs segun la recomendacion (contador por destino
inicializado aleatoriamente)
B genera Frag IDs con un contador global con un incremento fijo por
paquete fragmentado a enviar
M genera Frag IDs como le plazca
Como haría M para interferir la comunicacion entre A y B ?
Como haría M para hacer un port scan usando datagramas IPv6
fragmentados? atomicos o no ?
>
> 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....
Trate de explicarlo mejor en este mail
>
>
>> 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 ----
uy, me perdi eso!
De todas formas no hace mas que exacerbar la confusion... porque en el
parrafo anterior a ese dice:
--- cut here ---
For every packet that is to be fragmented, the source node generates
an Identification value. The Identification must be different than
that of any other fragmented packet sent recently* with the same
Source Address and Destination Address.
--- cut here ---
El parrafo que yo cito dice "*must* be different"
El siguiente, que citas vos, "the requirement *can* be met"
Osea el Frag ID *tiene* que ser un ID unico por tupla (src,dst) y ese
requerimiento *se puede* satisfacer con un contador, pero nadie
*requiere* que se satisfaga asi...
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).
Pero despues de relear esa parte reitero, el RFC 2460 incluso con el
parrafo que citas *no dice* "este campo es un contador"
>> 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"?
fragmentos atomicos y fragmentos comunes con el mismo ID. En tu
recomendacion sobre como tratar fragmentos atomicos no haces
distinciones sobre solapamiento.
En el RFC 5722 que habla de que hacer con el reesamblado de fragmentos
solapados no se distinguen los atomicos de los no-atomicos.
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).
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.
> 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.
ok, pero entonces, por definicion, los problemas de generacion de Frag
IDs y de procesamiento de datagramas fragmentados (ya sean atomicos o
no) no son ortogonales...
>>> 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.
Si, salvo una pequeña correción: Como parte de un fragmento *rechazado*
Es decir, se procesa el extension header, se encola el fragmento que lo
traía y despues cuando llega otro fragmento (potencialmente con otro
extension header) del mismo datagama original (porque tiene el mismo
Frag ID) se detecta un error (solapamiento, atomicidad, etc) y se
descartan todos los fragmentos, pero los headers que traian
(potencialmente contradictorios entre si) ya fueron procesados...
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? No
se... me parece rarisimo y sin embargo es un condición aceptable por
todos los RFC.
>
> Al menos sin pensarlo demasiado, no se me ocurre un escenario en el cual
> "puedas hacer algo mas"
... famosas ultimas palabras... :)
>en un extension header que es parte de un
> fragmento, que en un extension header que es parte de un paquete cualquiera.
>
Bueno creo que ya aburrimos lo suficiente a los lectores de la lista asi
que a menos que a alguien mas le interese este asunto te propongo que si
hace falta sigamos por fuera de la lista.
saludos,
-ivan
Más información sobre la lista de distribución Seguridad