Recientemente se dio a conocer la noticia de que identificaron una nueva vulnerabilidad (ya catalogada bajo el CVE-2021-4204) en el subsistema eBPF (para variar)…
Y es que el subsistema eBPF no ha dejado de ser una gran problemática de seguridad para el Kernel pues fácilmente en lo que fue todo el 2021 se dieron a conocer dos vulnerabilidades por mes y de las cuales hablamos de algunas de ellas aquí en el blog.
En cuanto a los detalles del actual problema se menciona que la vulnerabilidad detectada permite que un controlador se ejecute dentro del kernel de Linux en una máquina virtual JIT especial y que este a su vez permite que un usuario local sin privilegios obtenga una escalada de privilegios y ejecutar su código a nivel del kernel.
En la descripción del problema, mencionan que la vulnerabilidad se debe a un escaneo incorrecto de los programas eBPF transmitidos para su ejecución, ya que el subsistema eBPF proporciona funciones auxiliares, cuya corrección es verificada por un verificador especial.
Esta vulnerabilidad permite a los atacantes locales aumentar los privilegios en
instalaciones afectadas de Linux Kernel. Un atacante primero debe obtener la
capacidad de ejecutar código con pocos privilegios en el sistema de destino para
explotar esta vulnerabilidad.La falla específica existe en el manejo de los programas eBPF. La cuestión resulta de la falta de validación adecuada de los programas eBPF proporcionados por el usuario antes de ejecutarlos.
Ademas de ello, algunas de las funciones requieren que el valor PTR_TO_MEM se pase como argumento y el verificador debe conocer el tamaño de la memoria asociada con el argumento para evitar posibles problemas de desbordamientos de búfer.
Mientras que para las funciones bpf_ringbuf_submit y bpf_ringbuf_discard, los datos sobre el tamaño de la memoria transferida no se informan al verificador (es aqui donde el problema comienza), lo que aprovecha el atacante para poder usar para sobrescribir áreas de memoria fuera del límite del búfer al ejecutar un código eBPF especialmente diseñado.
Un atacante puede aprovechar esta vulnerabilidad para escalar privilegios y ejecutar código en el contexto del kernel. TENGA EN CUENTA que bpf sin privilegios está deshabilitado de forma predeterminada en la mayoría de las distribuciones.
Se menciona que para que un usuario pueda llevar a cabo un ataque, el usuario debe poder cargar su programa BPF y muchas distribuciones recientes de Linux lo bloquean de forma predeterminada (incluido el acceso sin privilegios a eBPF ahora está prohibido de forma predeterminada en el propio kernel, a partir de la versión 5.16).
Por ejemplo, se menciona que la vulnerabilidad puede ser explotada en la configuración por defecto en una distribucion que aún es bastante utilizada y sobre todo muy popular como lo es Ubuntu 20.04 LTS, pero en los entornos como Ubuntu 22.04-dev, Debian 11, openSUSE 15.3, RHEL 8.5, SUSE 15-SP4 y Fedora 33, solo se manifiesta si el administrador ha establecido el parámetro kernel.unprivileged_bpf_disabled en 0.
Actualmente, como solución alternativa para bloquear la vulnerabilidad, se menciona que se puede evitar que los usuarios sin privilegios ejecuten programas BPF ejecutando en una terminal el comando:
sysctl -w kernel.unprivileged_bpf_disabled=1
Finalmente, cabe mencionar que el problema ha aparecido desde el kernel de Linux 5.8 y permanece sin parches (incluida la versión 5.16) y es por ello que el código de explotación se retrasará durante 7 días y se publicará a las 12:00 UTC, es decir el 18 de enero de 2022.
Con ello se pretende dar el tiempo suficiente para que los parches correctivos sean puestos a disposición de los usuarios de las diferentes distribuciones de linux dentro de los canales oficiales de cada una de estas y tanto desarrolladores como usuarios puedan corregir dicha vulnerabilidad.
Para quienes estén interesados en poder conocer sobre el estado de la formación de actualizaciones con la eliminación del problema en alguna de las principales distribuciones, deben saber que se pueden rastrear desde estas páginas: Debian, RHEL, SUSE, Fedora, Ubuntu, Arch.
Si estás interesado en poder conocer más al respecto sobre la nota, puedes consultar el comunicado original en el siguiente enlace.