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 de que se detecto una falla en el manejo de la expansión de la pila en el kernel de Linux 6.1 hasta la versión 6.4 también conocido como «Stack Rot».
Se menciona que la traducción del VMA (Área de memoria virtual) de la estructura de datos «red-black tree» a «maple tree» en el kernel de Linux 6.1 provocó la aparición de una vulnerabilidad ( CVE-2023-3269 ) que permite a un usuario sin privilegios lograr la ejecución de su código con derechos de kernel.
Como StackRot es una vulnerabilidad del kernel de Linux que se encuentra en la gestión de memoria del subsistema, afecta a casi todas las configuraciones del kernel y requiere un mínimo de capacidades para desencadenar. Sin embargo, cabe señalar que los nodos de maple se liberan usando devoluciones de llamada de RCU, retrasando la desasignación de memoria real hasta después del período de gracia de RCU. En consecuencia, la explotación de esta vulnerabilidad se considera desafiante.
Sobre Stack Rot
La vulnerabilidad, cuyo nombre en código es StackRot, ha estado presente desde el lanzamiento del kernel 6.1 y se corrigió en las actualizaciones 6.4.1, 6.3.11 y 6.1.37.
Sobre la vulnerabilidad se menciona que la estructura de «maple tree» es una variante del árbol B que admite la indexación de rangos y está diseñada para hacer un uso eficiente de la memoria caché de los procesadores modernos.
En comparación con el «red-black tree», el uso del «maple tree» le permite lograr un mayor rendimiento. La vulnerabilidad se debe a un error en el controlador de extensión de pila: en la estructura de «maple tree» utilizada para administrar áreas de memoria virtual en el kernel, el reemplazo de un nodo en el árbol podría ocurrir sin establecer un bloqueo de escritura, lo que creó condiciones para acceder al área de memoria después de liberarla (use-after-free).
Cada vez que se utiliza la llamada al sistema `mmap()` para establecer una asignación de memoria, el kernel genera una estructura llamada `vm_area_struct` para representar el
área de memoria virtual (VMA) correspondiente. Esta estructura almacena varios
información que incluye banderas, propiedades y otros detalles pertinentes relacionados con el mapeo.
Posteriormente, cuando el kernel encuentra fallos de página u otros problemas relacionados con la memoria o llamadas al sistema, requiere una búsqueda rápida del VMA basada únicamente en la dirección.
Se menciona que anteriormente, los VMA se gestionaban mediante red-black tree. Sin embargo, a partir de la versión 6.1 del kernel de Linux, se llevó a cabo la migración a los maple tree, los cuales son estructuras de datos de árbol B seguras para RCU optimizadas para almacenar rangos que no se superponen. No obstante, su naturaleza intrincada agrega complejidad al código base e introduce la vulnerabilidad StackRot.
El problema surge al acceder a los VMA, ya que solo se mantiene el bloqueo de lectura de MM
y no ingresa a la sección crítica de RCU. En consecuencia, en teoría, la devolución de llamada podría invocarse en cualquier momento, lo que daría como resultado la liberación del antiguo nodo.
Por la parte de la explotación de Stack Rot, se menciona que esta se complicó por el hecho de que los nodos en la estructura del «maple tree» se liberan en un modo retrasado mediante llamadas de devolución de llamada con bloqueos RCU (Read-copy-update).
Sin embargo, los investigadores lograron superar las dificultades y preparar un exploit funcional de Stack Rot que planean publicar a finales de julio para dar tiempo a los usuarios de actualizar sus sistemas. La operación es posible en casi todas las configuraciones del kernel y requiere solo privilegios mínimos.
Cabe mencionar que como toda noticia de vulnerabilidades, estas sirven como una divulgación “temprana” de la vulnerabilidad, en este caso de StackRot. Como tal todo lleva un proceso y antes de ser anunciada ya se han enviado las notificaciones pertinentes para que sea solucionada la vulnerabilidad.
Finalmente, se menciona que se han proporcionado todos los detalles esenciales de la vulnerabilidad, el código de explotación completo y un informe completo se pondrán a disposición del público a más tardar a finales de julio.
Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.