[LACNIC/Seguridad] Processing of IPv6 "atomic" fragments (Fwd: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-00.ext)
Iván Arce
ivan.w.arce en gmail.com
Dom Feb 12 23:38:50 BRST 2012
On 2/11/12 5:28 PM, Fernando Gont wrote:
> Tu argumento, de acuerdo a mi entender, es que se podría dar una
> situación como la siguiente:
>
>
> A B M
> #1 <------ Echo Req #1 ----------
> #2 --- Echo Resp #1, FID= 5000 -->
> #3 <------------------- SYN #1, src= B -----------------------
> #4 ---- SYN/ACK, FID=9000 --->
> #5 <---- RST, FID= 5001 -----
> #6 <-------- Echo Req #2 ----------
> #7 ---- Echo Resp #2, FID= 5002 -->
>
> En este caso, M obtuvo dos informaciones distintas:
>
> 1) Que el port correspondiente de A estaba abierto -- esto es un idle
> scan, y fue posible porque B utiliza un contador global
> 2) Que el contador de "A" hacia "B" se incrementó en 1 -- esto es
> posible ya que "B" termina leakeando información del contador de
> "A" a "B".
>
> Creo que no hay discusión algunta sobre el item "#1". Respecto al item
> "2)", mi argumento es que si bien "M" sabe que el contador de "A" a "B"
> se incrementó, no sabe cual es el valor actualmente utilizado. Es decir,
> lo unico que sabe es que si ese contador antes valia "X", ahora vale
> "X+1".
> Y mi argumento es que no encuentro modo en el cual dicha
> información pudiera ser aprovechada.
>
> Es este el escenario al que estas haciendo referencia, o te referis a
> otro escenario?
>
Si, ese es el tipo de escenario al que hago referencia y creo que
estamos progresando en el analisis pero falta atribuirle un poco mas de
malicia a M... Por ejemplo, Que pasa si M tambien spoofea el datagrama
#4 con un Frag Id de su elección?
Esta este caso:
A B M
#4 ---- SYN/ACK, FID=9000 --->
#4' <---- SYN/ACK, FID=42 src = A---
#5 <---- RST, FID= 5001 -----
#5' <---- RST, FID= 5002 -----
#6 <-------- Echo Req #2 ----------
#7 ---- Echo Resp #2, FID= 5003 -->
Y también este:
A B M
#4 ---- SYN/ACK, FID=9000 --->
#4' <---- SYN/ACK, FID=9000 src = A---
... (RFC5722)
#6 <-------- Echo Req #2 ----------
#7 ---- Echo Resp #2, FID= 5001 -->
Con lo cual podemos afirmar que existe al menos una manera para M de
determinar no solo si el contador de A se incrementa o no, sino tambien
el valor exacto de ese contador.
Por supuesto que hay una serie de detalles a considerar en el ataque que
describo y que también lo mas probable a partir de este punto es
enfrentar un contra argumento matemático basado en la eficiencia del
ataque vs. el ancho de banda necesario, etc. No me parece necesario
entrar en esa discución... Aclaro además que el ejemplo que doy arriba
es lo primero que se me viene a la cabeza, estoy seguro que hay cosas
mas sofisticadas para hacer.
>>>> 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
>
> Bueno, "por lo que veo de tu ejemplo" no es tajante. :-)
Mi ejemplo no necesita ser tajante. Esa es la diferencia entre señalar
un falla de diseño que debilita la seguridad de un sistema y afirmar que
la falla de diseño no es relevante porque no hay forma conocida (por
quien hace la afirmación) de explotarla.
Los que se preocupan por la seguridad lo suficiente como para aceptar
una degradación en performance a cambio de cerrar una *potencial* vía de
ataque ya tienen suficiente información como para tomar una decision.
Algunos ya la tenían hace tiempo... OpenBSD por ejemplo decidio general
los frag ID usando una *sequencia* pseudoaleatoria hace 3 años y 8 meses:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/ip6_id.c?rev=1.7;content-type=text%2Fx-cvsweb-markup
> Simplemente
> quise decir "no *encuentro* tal cosa" -- pero *no* "no *existe*" tal cosa.
>
entendido.
>>
>> 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.
>
> Claro, pero lo que hacen es parsear type y length, y procesar el
> contenido de aquellos headers/opciones que *entienden*. Para implementar
> lo que vos decis,
para implementar que cosa que yo dije? Yo no propuse nada...
a ese procesamiento habria que agregarle una
> comparación byte-a-byte entre los ext headers del primer fragmento, y
> los ext headers del resto de los fragmentos.
uh?? En ningun momento propuse que se verifique que todos los extension
headers del primer fragmento esten presentes y sean iguales que los de
todos los demas fragmentos. Incluso si tuviera una idea de esas
caracteristicas trataria de pensar en algo que no sea una comparación
byte a byte... (p.e. calcular y comparar hashes o alguna otra cosa de
esa naturaleza.. la verdad que no pense en nada de eso)
>> 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).
>
> -- Esto, en principio, no lo veo como tan problematico.
No? Yo si veo potenciales problemas y no tengo suficientes conocimientos
de IPv6 como para evaluar el efecto sobre el protocolo (mas alla del
impacto en performance) de procesar extension headers despues reensamblado.
>Lo que veo como
> mas problematico es chequear que todos los fragmentos tengan ext headers
> iguales.
>
Si, completamente de acuerdo, pero yo en ningun momento propuse o
siquiera pense en hacer tal cosa.
-ivan
Más información sobre la lista de distribución Seguridad