Deux nouvelles vulnérabilités ont été identifiées dans le sous-système eBPF, qui vous permet d'exécuter des gestionnaires à l'intérieur du noyau Linux dans une machine virtuelle spéciale avec JIT. Les deux vulnérabilités permettent d'exécuter votre code avec les droits du noyau, en dehors d'une machine virtuelle eBPF isolée. Des informations sur les problèmes ont été publiées par l'équipe Zero Day Initiative, qui organise le concours Pwn2Own, au cours duquel cette année, trois attaques sur Ubuntu Linux utilisant des vulnérabilités jusqu'alors inconnues ont été démontrées (il n'est pas signalé si les vulnérabilités d'eBPF sont liées à ces attaques). .
- CVE-2021-3490 - La vulnérabilité est causée par un manque de vérification des limites 32 bits lors de l'exécution d'opérations ET, OU et XOR au niveau du bit dans eBPF ALU32. Un attaquant peut profiter de cette erreur pour lire et écrire des données en dehors des limites du tampon alloué. Le problème avec les opérations XOR apparaît à partir de la version 5.7-rc1 du noyau, et AND et OR à partir de la version 5.10-rc1.
- CVE-2021-3489 - La vulnérabilité est causée par une erreur dans l'implémentation du tampon en anneau et est due au fait que la fonction bpf_ringbuf_reserve n'a pas vérifié la possibilité que la taille de la région mémoire allouée puisse être inférieure à la taille réelle du ringbuf. Le problème apparaît depuis la version 5.8-rc1.
L'état des correctifs aux vulnérabilités dans les distributions peut être suivi sur ces pages : Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Les correctifs sont également disponibles sous forme de correctifs (CVE-2021-3489, CVE-2021-3490). La possibilité d'exploiter le problème dépend de la question de savoir si l'appel système eBPF est accessible à l'utilisateur. Par exemple, dans la configuration par défaut de RHEL, l'exploitation de la vulnérabilité nécessite que l'utilisateur dispose des droits CAP_SYS_ADMIN.
Par ailleurs, nous pouvons noter une autre vulnérabilité dans le noyau Linux - CVE-2021-32606, qui permet à un utilisateur local d'élever ses privilèges au niveau racine. Le problème est évident depuis le noyau Linux 5.11 et est dû à une condition de concurrence critique dans l'implémentation du protocole CAN ISOTP, qui permet de modifier les paramètres de liaison de socket en raison de l'absence de définition des verrous appropriés dans la fonction isotp_setsockopt(). lors du traitement de l'indicateur CAN_ISOTP_SF_BROADCAST.
Après la fermeture du socket ISOTP, la liaison au socket destinataire reste en vigueur, qui peut continuer à utiliser les structures associées au socket après que la mémoire qui leur est associée soit libérée (use-after-free dû à l'appel à une structure isotp_sock qui a déjà été libéré lors de l'appel de isotp_rcv()). Grâce à la manipulation des données, vous pouvez remplacer le pointeur vers la fonction sk_error_report() et exécuter votre code au niveau du noyau.
Source: opennet.ru