Vulnerabilidad en kernel de Linux (CVE-2023-52881)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: no acepta ACK de bytes que nunca enviamos. Este parche se basa en un informe detallado e ideas de Yepeng Pan y Christian Rossow. La validación de secuencia de ACK sigue actualmente las pautas RFC 5961 5.2: El valor de ACK se considera aceptable solo si está en el rango de ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). Todos los segmentos entrantes cuyo valor ACK no satisface la condición anterior DEBEN descartarse y enviarse un ACK. Es necesario tener en cuenta que RFC 793 en la página 72 (quinta verificación) dice: "Si el ACK es un duplicado (SEG.ACK < SND.UNA), se puede ignorar. Si el ACK reconoce algo que aún no se ha enviado (SEG. ACK > SND.NXT) luego envía un ACK, descarta el segmento y regresa". Lo "ignorado" anterior implica que el procesamiento del segmento de datos entrantes continúa, lo que significa que el valor ACK se trata como aceptable. Esta mitigación hace que la verificación de ACK sea más estricta, ya que no se aceptará ningún ACK < SND.UNA; en su lugar, solo se aceptarán ACK que estén en el rango ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND. NXT) pasar. Esto se puede perfeccionar para flujos nuevos (y posiblemente falsificados) al no aceptar ACK para bytes que nunca se enviaron. Esto mejora enormemente la seguridad de TCP a un costo reducido. Agregué una etiqueta Correcciones: para asegurarme de que este parche llegue a árboles estables, incluso si el parche "culpado" se adhirió al RFC. tp->bytes_acked se agregó en Linux-4.2 La siguiente prueba de packagedrill (cortesía de Yepeng Pan) muestra el problema en cuestión: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1 ], 4) = 0 +0 enlazar(3, ..., ...) = 0 +0 escuchar(3, 1024) = 0 // ---------------- Apretón de manos ------------------- // // cuando la escala de la ventana se establece en 14, el tamaño de la ventana se puede ampliar a // 65535 * (2^14) = 1073725440. Linux aceptaría un paquete ACK // con un número de reconocimiento en (Server_ISN+1-1073725440. Server_ISN+1) //, aunque este número de reconocimiento reconoce algunos datos // nunca enviados por el servidor. +0 < S 0:0(0) win 65535 +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 aceptar(3, ..., ...) = 4 // Para la conexión establecida, enviamos un paquete ACK, // el paquete de confirmación utiliza el número de confirmación 1 - 1073725300 + 2^32, // donde 2^32 se usa para envolver. // Nota: utilizamos 1073725300 en lugar de 1073725440 para evitar posibles // casos extremos. // 1 - 1073725300 + 2^32 = 3221241997 // Vaya, los núcleos antiguos aceptan felizmente este paquete. +0 <. 1:1001(1000) ACK 3221241997 win 65535 // Después de la corrección del kernel, lo siguiente será reemplazado por un ACK de desafío, // y el marco malicioso anterior se eliminará. +0 > . 1:1(0) reconocimiento 1001