Se han identificado dos nuevas vulnerabilidades en el subsistema eBPF, que permite ejecutar controladores dentro del kernel de Linux en una máquina virtual especial con JIT. Ambas vulnerabilidades permiten ejecutar su código con derechos del kernel, fuera de una máquina virtual eBPF aislada. La información sobre los problemas fue publicada por el equipo de Zero Day Initiative, que organiza el concurso Pwn2Own, durante el cual este año se demostraron tres ataques a Ubuntu Linux que utilizaron vulnerabilidades previamente desconocidas (no se informa si las vulnerabilidades en eBPF están relacionadas con estos ataques). .
- CVE-2021-3490: la vulnerabilidad se debe a una falta de verificación fuera de límites de 32 bits al realizar operaciones AND, OR y XOR bit a bit en eBPF ALU32. Un atacante puede aprovechar este error para leer y escribir datos fuera de los límites del búfer asignado. El problema con las operaciones XOR aparece a partir de la versión del kernel 5.7-rc1, y AND y OR, a partir de la versión 5.10-rc1.
- CVE-2021-3489: La vulnerabilidad es causada por un error en la implementación del búfer de anillo y se debe a que la función bpf_ringbuf_reserve no verificó la posibilidad de que el tamaño de la región de memoria asignada pudiera ser menor que el tamaño real. del ringbuf. El problema aparece desde la versión 5.8-rc1.
El estado de parcheo de vulnerabilidades en distribuciones se puede rastrear en estas páginas: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Las correcciones también están disponibles como parches (CVE-2021-3489, CVE-2021-3490). La posibilidad de explotar el problema depende de si el usuario puede acceder a la llamada al sistema eBPF. Por ejemplo, en la configuración predeterminada en RHEL, la explotación de la vulnerabilidad requiere que el usuario tenga derechos CAP_SYS_ADMIN.
Por otra parte, podemos observar otra vulnerabilidad en el kernel de Linux: CVE-2021-32606, que permite a un usuario local elevar sus privilegios al nivel raíz. El problema ha sido evidente desde el kernel de Linux 5.11 y es causado por una condición de carrera en la implementación del protocolo CAN ISOTP, que permite cambiar los parámetros de enlace del socket debido a la falta de configuración de los bloqueos adecuados en la función isotp_setsockopt(). al procesar el indicador CAN_ISOTP_SF_BROADCAST.
Después de cerrar el socket ISOTP, el enlace al socket del destinatario permanece vigente, el cual puede continuar usando las estructuras asociadas al socket después de que se libera la memoria asociada a ellas (uso después de la liberación debido a la llamada a una estructura isotp_sock que ya ha sido liberado cuando se llama a isotp_rcv()). Mediante la manipulación de datos, puede anular el puntero a la función sk_error_report() y ejecutar su código en el nivel del kernel.
Fuente: opennet.ru