[LACNIC/Seguridad] Nuevo I-D sobre seguridad TCP (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt)

Fernando Gont fgont en si6networks.com
Mie Feb 20 21:16:33 BRT 2013


On 02/19/2013 05:50 PM, Iván Arce wrote:
> Ahh muy interesante, lo voy a leer en detalle, pero a simple vista me
> recuerda a algo que (creo) OpenBSD corrigió hace varios años. 

Seguramente te referís a esto: RFC 5961
(http://www.rfc-editor.org/rfc/rfc5961.txt)

Ese tema lo corrigió en su momento casi todo el mundo (*BSD, Cisco,
etc.), y la discusión habia sido generada por una presentación de Paul
Watson en CansecWest 2004



> Aunque
> creo que en aquel caso era al revés, procesaban paquetes fuera de la
> ventana que no debian procesarse.

En realidad, lo que pasaba es que se podían realizar checks de
validación mas especificos de lo que en su momento se hacía.

En tal sentido, esto: RFC 5927
(<http://www.rfc-editor.org/rfc/rfc5927.txt>) era peor, ya que no
chequeaban (siquiera) el TCP SEQ embebido en los errores ICMP.



> Tendrían que pensar que implicancias de seguridad tiene la  modificación
> propuesta, p.e. si hace mas fácil a un tercero hacer un DoS con paquetes
> con segmentos TCP un byte fuera de la ventana.
> A priori parecería que no hay mas problemas de los ya conocidos (
> adivinar el seqno sería equivalente a adivinar seqno-1 ) pero no estoy
> seguro.

Coincido. EL unico "caveat" es que los ZWP (Zero-Window Probe) son en la
practica de 1 bye, pero en teoría podrían ser de cualquier tamaño.
Entonces tenemos dos opciones:

1) Hacer lo que hace el I-D actual, pero aparte especificar formalmente
que lso ZWP *deben* ser de un byte, o

2) Permitir flexibilidad en el tamaño de los ZWP, pero en tal caso el
chequeo deberia permitir valores de hasta RCV.NXT - MAX_SIZE_SENT (donde
este ultimo valor seria el maximo tamaño de segmento TCP enviado hasta
ahora).

La opcion 1 es mas segura. La 2 es mas elegante y flexible.



> En principio me resulta poco confiable recomendar una modificacion
> general al procesamiento del TCP para que siempre incluya un byte menos
> que el borde de la venta en lugar de hacerlo para las situaciones

En realidad, las implementaciones reales (*) ya hacen esto (al menos
*BSD). Si no haces eso, podes caer en situaciones de DoS por "ACK wars".

(*) Salvo Windows, y tal vez otros.


> específicas en que es necesario admitir esos paquetes. Pero por otro
> lado, es posible que sea dicifil enumerar todas las situaciones en las
> que es necesario admitir un segmento con número de sequencia un byte
> fuera de la ventana.

El punto es que si queres habilitar eso solo para las "situaciones
especificas", entonces de algun modo deberias modificar la maquina de
estados TCP, apra que haya un estado "ESTABLISHED (ZWP)" .. y lo mismo
para el cierre de conexion. Y en gral, cuantos mas "casos especificos"
uno agrega, el codigo se vuelve mas complejo, etc.

En particular, creo que relajar el chequeo en un solo byte (como sería
la opcion 1) no cambia nada (en particular cuando la tendencia es a usar
ventanas TCP mas grande.. y *eso* es lo que abre de manera considerable
la ventana de ataque).

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







Más información sobre la lista de distribución Seguridad