CVE-2024-27415

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: bridge: confirme los paquetes de multidifusión antes de pasarlos a la pila conntrack La lógica nf_confirm no puede manejar skbs clonados que hagan referencia a la misma entrada nf_conn, lo que sucederá con las tramas de multidifusión (difusión) en puentes. Ejemplo: macvlan0 | br0 / \ ethX ethY ethX (o Y) recibe un paquete de multidifusión o difusión L2 que contiene un paquete IP, el flujo aún no está en la tabla conntrack. 1. skb pasa por el puente y el enrutamiento previo de IP falsa (br_netfilter). -> skb->_nfct ahora hace referencia a una entrada no confirmada 2. skb es un paquete amplio/mcast. El puente ahora pasa clones en cada interfaz del puente. 3. skb pasa a la pila. 4. En el caso de macvlan, el controlador macvlan conserva los clones del skb mcast y programa una cola de trabajo para enviarlos a los dispositivos inferiores. El clon skb->_nfct no es una copia, es la misma entrada que el skb original. El controlador macvlan rx luego devuelve RX_HANDLER_PASS. 5. Los ganchos de conexión normales (en NF_INET_LOCAL_IN) confirman el skb original. El trabajador de transmisión de Macvlan y la ruta de confirmación normal correrán. Esta carrera no se realizará si el paso 2 ya confirmó un clon. En ese caso, los pasos posteriores realizan skb_clone() con skb->_nfct ya confirmado (en la tabla hash). Esto funciona bien. Pero dicha confirmación no ocurrirá cuando las reglas eb/ip/nftables eliminen los paquetes antes de que alcancen el paso nf_confirm en el posenrutamiento. Pablo señala que nf_conntrack_bridge no permite el uso de nat con estado, por lo que podemos descartar con seguridad la entrada nf_conn y dejar que inet llame a conntrack nuevamente. Esto no funciona para bridge netfilter: skb podría tener una transformación nat. Además, bridge nf evita la reinvocación del enrutamiento previo de inet a través del gancho 'sabotage_in'. Evite este problema confirmando explícitamente la entrada en el momento LOCAL_IN, antes de que la capa superior tenga la oportunidad de clonar la entrada no confirmada. La desventaja es que esto desactiva NAT y los asistentes de conexión. Una solución alternativa sería agregar bloqueo a todas las partes del código que tratan con paquetes no confirmados, pero incluso si eso pudiera hacerse de manera sensata, esto abre otros problemas, por ejemplo: -m physdev --physdev-out eth0 -j SNAT - -snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5 Para el caso de multidifusión, solo se creará una de estas asignaciones conflictivas, conntrack solo maneja asignaciones NAT 1:1. Los usuarios deben crear una configuración que marque explícitamente dicho tráfico NOTRACK (omisión de conntrack) para evitar esto, pero no podemos omitirlos automáticamente, es posible que el conjunto de reglas ya haya aceptado reglas para el tráfico sin seguimiento, por lo que el comportamiento visible para el usuario cambiaría.