Vulnerabilidad en kernel de Linux (CVE-2021-47128)
Fecha de publicación:
15/03/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf, bloqueo, auditoría: se corrigieron las comprobaciones de permisos de bloqueo de SELinux con errores. El commit 59438b46471a ("seguridad, bloqueo, selinux: implementar bloqueo de SELinux") agregó una implementación del gancho LSM lock_down a SELinux. con el objetivo de restringir qué dominios pueden realizar operaciones que violarían el bloqueo. Indirectamente, esto también implica involucrar al subsistema de auditoría para informar eventos. Esto último es problemático, como informaron Ondrej y Serhei, ya que puede hacer caer todo el sistema a través de una auditoría: 1) Los eventos de auditoría que se activan debido a llamadas a security_locked_down() pueden OOM matar una máquina, vea los detalles a continuación [0] . 2) También parece estar causando un punto muerto a través de avc_has_perm()/slow_avc_audit() cuando se intenta activar kauditd, por ejemplo, cuando se usa el punto de seguimiento trace_sched_switch(), consulte los detalles en [1]. Esto no se activó a través de algún caso hipotético de esquina, sino con herramientas existentes como runqlat y runqslower de bcc, por ejemplo, que hacen uso de este punto de seguimiento. La secuencia de llamada aproximada es así: rq_lock(rq) -> -------------------------+ trace_sched_switch() -> | bpf_prog_xyz() -> +-> punto muerto selinux_lockdown() -> | audit_log_end() -> | wake_up_interruptible() -> | try_to_wake_up() -> | rq_lock(rq) --------------+ Lo que es peor es que la intención de 59438b46471a de restringir aún más la configuración de bloqueo para aplicaciones específicas con respecto a la política de bloqueo global no es válida para BPF. La regla de política de SELinux para la verificación de bloqueo actual se parece a esto: permitir : bloqueo { }; Sin embargo, esto no coincide con la tarea 'actual' donde se ejecuta security_locked_down(), ejemplo: httpd realiza una llamada al sistema. Hay un programa de seguimiento adjunto a la llamada al sistema que activa la ejecución de un programa BPF, que termina realizando una llamada de ayuda bpf_probe_read_kernel{,_str}(). El gancho selinux_lockdown() realiza la verificación de permisos con respecto a 'actual', es decir, httpd en este ejemplo. httpd tiene literalmente cero relación con este programa de rastreo, y no tendría sentido tener que escribir una regla de política SELinux contra httpd para permitir que pase el asistente de rastreo. La política en este caso debe ser contra la entidad que está instalando el programa BPF. Por ejemplo, si bpftrace generara un histograma de recuentos de llamadas al sistema por aplicación de espacio de usuario: bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' bpftrace luego generaría un programa BPF a partir de esto internamente. Una forma de hacerlo [por el bien del ejemplo] podría ser llamar al asistente bpf_get_current_task() y luego acceder a current->comm a través de uno de los asistentes bpf_probe_read_kernel{,_str}(). Entonces, el programa en sí no tiene nada que ver con httpd o cualquier otra aplicación aleatoria que realice una llamada al sistema aquí. El programa BPF _inició explícitamente_ la verificación del bloqueo. La política de permitir/denegar pertenece al contexto de bpftrace: es decir, desea otorgar acceso a bpftrace para usar estos asistentes, pero otros rastreadores en el sistema como my_random_tracer _no_. Por lo tanto, solucione los tres problemas al mismo tiempo adoptando un enfoque completamente diferente para el enlace security_locked_down(), es decir, mueva la verificación a la fase de verificación del programa donde realmente recuperamos el protocolo de función BPF. Esto también obtiene de manera confiable la tarea (actual) que está intentando instalar el programa de rastreo de BPF, por ejemplo, bpftrace/bcc/perf/systemtap/etc,---truncado---
Gravedad CVSS v3.1: MEDIA
Última modificación:
13/03/2025
