Linux en español
Kernel de Linux
Noticias

Detectadas dos vulnerabilidades de denegación de servicio en el Kernel de Linux

4 minutos de lectura

Durante el lapso de esta semana se han dado a conocer algunas soluciones a diversos problemas con el Kernel de Linux, pero también se descubrieron algunos otros, de los cuales Wanpeng Li descubrió recientemente dos denegaciones de servicio (DOS) en el kernel de Linux.

Con lo cual esto permite a los atacantes locales usar un puntero nulo para hacer referencia a un error para desencadenar un estado DOS.

HIT Closer

La primera vulnerabilidad, con el número CVE-2018-19406 en vulnerabilidades y exposiciones comunes, existe en la función kvm_pv_send_ipi del kernel de Linux, que se define en el archivo arch/x86/kvm/lapic.c.

La vulnerabilidad CVE-2018-19406 existe en Linux Kernel 4.19.2, lo que permite al atacante utilizar llamadas elaboradas al sistema en dispositivos no reparados para lograr el estado de DOS. La causa de este problema se debe a la falla del controlador programable avanzado de interrupción (APIC) para que se inicialice correctamente.

Wanpeng Li escribió:

“La razón es que el mapa apic aún no se ha inicializado, el testcase activa la interfaz pv_send_ipi por vmcall, lo que da como resultado que kvm-> arch.apic_map no esté referenciado. “Este parche lo arregla verificando si el mapa apic es NULL o no y de inmediato si es así”.

La segunda vulnerabilidad descubierta por Wanpeng Li se limita a situaciones en las que un atacante puede acceder físicamente al dispositivo.

Este problema está numerado CVE-2018-19407 en la base de datos nacional de vulnerabilidad y aparece en la función vcpu_scan_ioapic en arch/x86/kvm/x86.c en el kernel de Linux 4.19.2, lo que permite a los usuarios locales causar una denegación de servicio (puntero NULL) desviación y BUG) a través de llamadas de sistema diseñadas que llegan a una situación en la que ioapic no está inicializado.

Otra vulnerabilidad mas que afecta al Kernel de Linux CVE-2018-18955

Por otra parte, también en el transcurso de esta semana se detectó una vulnerabilidad (CVE-2018-18955) en el código de traducción de uid/gid desde los espacios de nombre de usuario (user namespace).

Al conjunto de identificador principal, que permite a un usuario sin privilegios con privilegios de administrador en un contenedor aislado (CAP_SYS_ADMIN) evitar las restricciones de seguridad y acceder a recursos fuera del espacio de nombres del identificador actual.

Por ejemplo, cuando utiliza un sistema de archivos compartido en un contenedor y un entorno host, puede leer el contenido del archivo /etc/shadow en el entorno principal a través de una apelación directa a i-node.

La vulnerabilidad está presente en las distribuciones que utilizan el kernel 4.15 y versiones más recientes, por ejemplo, en Ubuntu 18.04 y Ubuntu 18.10 , Arch Linux y Fedora (el kernel 4.19.2 con corrección ya está disponible en Arch y Fedora ).

RHEL y SUSE no se ven afectados. En Debian y Red Hat Enterprise Linux, la compatibilidad con el espacio de usuario no está activada por defecto, pero está incluida en Ubuntu y Fedora.

La vulnerabilidad es causada por un error en el código del Kernel de Linux 4.15, introducido en octubre del año pasado.

El problema se ha solucionado en las versiones 4.18.19, 4.19.2 y 4.20-rc2.

La vulnerabilidad está presente en la función map_write () definida en el archivo del kernel /user_namespace.c, y está causada por el procesamiento incorrecto de espacios de identificadores de usuarios anidados que utilizan más de 5 rangos UID o GID.

En estas condiciones, la traducción de los identificadores uid / gid del espacio de nombres al kernel (mapa hacia adelante) funciona correctamente, pero no se realiza durante la conversión inversa (mapa inverso, del kernel al espacio del identificador).

Surge una situación en la que el ID de usuario 0 (raíz) se asigna correctamente al identificador 0 en el kernel durante la conversión directa, pero no refleja la situación real durante la transformación inversa utilizada en las comprobaciones inode_owner_or_capable () y privileged_wrt_inode_uidgid ().

Por lo tanto, al acceder a un inodo, el kernel considera que el usuario tiene la autoridad adecuada, a pesar del hecho de que el identificador 0 no se usa desde el conjunto principal de identificadores de usuario, sino desde un espacio de nombres separado.

Noticia obtenida de blog.desdelinux.net

Valorar post

Entradas relaccionadas

ReactOS no está muerto, sino que ha priorizado la calidad en su desarrollo

Redacción

Nuevo PC de código abierto ‘Thelio’ de System76

Linux en Español

Deepin 20.9, una actualización de mantenimiento… ¿antes del gran cambio?

Redacción

AMD vs Intel ¿Cual elegirías?

Linux en Español

La Steam Deck consolida el dominio de AMD en el Linux Gaming

Redacción

The Linux Foundation Europe anuncia oficialmente la creación de la OpenWallet Foundation

Redacción

Este sitio web utiliza cookies para mejorar su experiencia. Asumiremos que está de acuerdo con esto, pero puede optar por no participar si lo desea. Aceptar Leer más

Política de privacidad y cookies