[LACNIC/Seguridad] Generación de IPv6 Frag ID, etc.

[Iván Arce]

On 2/13/12 2:28 AM, Fernando Gont wrote:
> On 02/12/2012 11:50 PM, Iván Arce wrote:
>>> Pese a que el "Frag ID" de IPv6 es de 32 bits, si en el medio hubiera un
>>> traductor IPv6/IPv4, solo los low-order 16-bits son utilizados... lo
>>> cual ahce que, a la practica, uno probablemente tenga que considerar que
>>> el Frag ID tiene un largo efectivo de 16 bits.
>>>
>>> En tales escenarios, si uno simplemente random()iza el frag ID, las
>>> posibilidades de colision son bastante posibles.
>>
>> "bastante posibles" es una definición un tanto ambigua pero estoy de
>> acuerdo en general, por eso es que lo que yo pregunte originalmente es
>> porque no utilizaban un  Lineal Congruential Generator (LCG) para genera
>> una sequencia pseudoaleatoria global
> 
> Como te mencionaba, considerando Frag IDs de 32-bits (léase, salteando
> esto de arriba), mi propuesta era justamente hacer algo tipo rand(). (el
> resto de esta historia sobre como llegamos a donde llegamos, ya lo
> hablamos).

Precisamente, yo preguntaba porque no usar un LCG porque entendí que
usando random() la probabilidad de que colisiones podía no ser aceptable.

> 
> Respecto al LCG en particular, creo recordar alguna publicación respecto
> de problemas con los mismos (seguridad? frecuencia de valores?)

Si, claro que hay problemas.  Un LCG no es un PRNG  (y además un LCG
depende fuertemente de los parámetros que se usen) pero en el caso
particular que analizamos y que es muy parecido al que en su momento
analice con la gente de OpenBSD parece ser una solución de compromiso
mejor que la de un contador por destino que se inicializa con un valor
pseudoaleatorio y se incrementa en 1 por cada fragmento

> 
>> Fijate que eso es lo que utiliza OpenBSD:
>>
>> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/ip6_id.c?rev=1.7;content-type=text%2Fx-cvsweb-markup
>>
>> Y fijate que eso es "sospechosamente parecido" a la solución que
>> encontramos para generar query IDs de DNS hace 15 años:
>>
>> http://www.openbsd.org/advisories/res_random.txt
> 
> NO habia habido un problema con el algoritmo utilizado por OpenBSD? --
> Creo recordar una publicación de Amit Klein (?)... pero a esta altura no
> recuerdo los detalles.

Si, el paper al que te referís es este (lo cual introduce al debate la
perspectiva de viabilidad de un ataque desde el punto de vista
matemático y probabilístico):

http://www.trusteer.com/sites/default/files/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf

Y también hace referencia a ataques al IP ID (lee la seccion 3 del
paper) no se si como consecuencia de eso es que OpenBSD ahora genera los
IP ID usando esto:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/idgen.c

El LCG lo siguen usando para los flowlabels. Sería interesenta evaluar
las implicacias del use de un LCG global en el caso específico de Frag
Id de IPv6 (32bits) ya que aca si es legítimo asumir que el atacante M
puede samplear una sequencia de longitud arbitraria de frag IDs
generados por A para tratar de determinar los parámetros que se están
usando.

La forma actual en que se generan Frag IDs de IPv6 en OpenBSD es:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/ip6_output.c

ip6_fragment(struct mbuf *m0, int hlen, u_char nextproto, u_long mtu)
{
	struct mbuf	*m, **mnext, *m_frgpart;
	struct ip6_hdr	*mhip6;
	struct ip6_frag	*ip6f;
	u_int32_t	 id;
	int		 tlen, len, off;
	int		 error;

	id = htonl(ip6_randomid());
...


ip6_randomid(void)
{
	return idgen32(&ip6_id_ctx);
}

Lo cual me lleva a sospechar que posiblemente toda este mismo debate ya
existió en algún momento y por eso en OpenBSD se terminó usando la
implementación actual (SKIP32)

> 
> 
> 
>> De más esta aclarar que el query IDs de DNS es un campo de 16bits y que
>> las consideraciones sobre predictibilidad y probabilidad de colisiones
>> que señalás eran completamente aplicables en aquel caso.
> 
> Se me ocurre que en el caso del query ID, es *algo* menos problemático
> -- en el caso de fragmentación, los fragmentos se almacenan en el queue
> por hasta 60 segundos.
> 

Hmm por que sería menos problemático?


-ivan