Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace pocos días se dio a conocer la noticia sobre el descubrimiento de una vulnerabilidad en el subsistema Netfilter (utilizado para interceptar y manipular los paquetes de red), la vulnerabilidad catalogada bajo CVE-2023-6817 calificada bajo una puntuación de gravedad alta de 7.8, representa una amenaza a considerar, pues permite a un usuario local escalar sus privilegios en el sistema.

Netfilter es un componente crucial que actúa como un guardián, gestionando el flujo de paquetes de datos en la pila de la red y que facilita diversas operaciones como modificar direcciones, descartar paquetes y registrar actividades.

Se menciona que la falla puede provocar una condición de uso después de la liberación, un escenario peligroso en el que el sistema continúa usando la memoria después de haber sido liberada, lo cual genera una condición para aprovechar el fallo por parte de atacantes y además que podría provocar fallas en las aplicaciones, divulgación de información o, lo que es aún más alarmante, escalada de privilegios locales.

La vulnerabilidad aparece a partir de la versión 5.6 del kernel de Linux (excluyendo Linux 5.10.204), asi como también en Linux 5.11 (excluyendo Linux 5.15.143), también en Linux 5.16 (excluyendo Linux 6.1.68), Linux 6.2 (excluyendo 6.6.7) y también las RC1, 2, 3 y 4 de Linux 6.7 (aunque este último ya fue lanzado su versión estable donde se soluciona la vulnerabilidad desde la RC5).

Sobre el problema, se menciona que sé debe a un acceso a la memoria de uso después de la liberación en el módulo nf_tables, que proporciona el filtro de paquetes nftables y se debe a un error en la función nft_pipapo_walk, debido al cual el proceso de iteración sobre elementos PIPAPO (Pile Packet Policies) no verifica la actividad de un elemento antes de operar sobre él, lo que puede provocar una vulnerabilidad de uso después de liberar.

La función nft_rhash_walk() en otros backends de conjunto también no omite los elementos inactivos durante el recorrido del conjunto y como resultado, el comando NFT_MSG_DELSETELEM se puede llamar dos veces en una transacción para eliminar cada elemento en ese conjunto dos veces, lo que resulta en una doble liberación 1

Si el backend es un conjunto pipapo, se llamará a nft_pipapo_walk(). Esta función no verifica la actividad de un elemento antes de operar sobre él, al igual que las funciones similares en otros backends de conjunto, como nft_rhash_walk(). Por lo tanto, el comando NFT_MSG_DELSETELEM se puede llamar dos veces en una transacción para eliminar cada elemento en ese conjunto dos veces, lo que resulta en una doble liberación.

Además de ello, se menciona que para que el proceso de explotación de la vulnerabilidad sea exitoso, el ataque requiere acceso a nftables, que se puede obtener teniendo derechos CAP_NET_ADMIN en cualquier espacio de nombres de usuario o espacio de nombres de red, que se puede proporcionar, por ejemplo, en contenedores aislados. Para demostrar la vulnerabilidad se ha publicado un prototipo de exploit para probar.

Finalmente, cabe mencionar que el fallo fue abordado mucho antes de su divulgación, ya que como mencionamos, la solución de la vulnerabilidad se propuso en la versión de prueba del kernel de Linux 6.7-rc5 y se trasladó a las ramas estables actuales de Linux 5.10.204, 5.15.143, 6.1.68 y 6.6.7.

Se menciona que la solución implica aplicar algunos cambios sobre el modo de operación de la función `nft_pipapo_walk`, pues para solucionar el fallo, esta debe omitir elementos inactivos durante las caminatas establecidas. Este enfoque previene eficazmente la doble desactivación de elementos PIPAPO (Pile Packet Policies), eliminando así la condición de uso después de la liberación.

Por último, y no menos importante, y como siempre solemos hacerlo, damos la recomendación a todos nuestros queridos lectores de implementar las correcciones pertinentes, ya que a pesar de que la vulnerabilidad difícilmente podría ser explotada de forma remota, nunca está de más implementar las correcciones correspondientes.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace. En cuanto a los interesados en poder probar el prototipo de exploit, pueden consultar el código de este en el siguiente enlace.