Récemment, la nouvelle a éclaté que identifié une nouvelle vulnérabilité (déjà répertorié sous CVE-2021-4204) dans le sous-système eBPF (pour varier) ...
Et c'est que le sous-système eBPF n'a pas cessé d'être un gros problème de sécurité pour le Kernel car facilement en ce qui a été tout 2021 deux vulnérabilités ont été révélées par mois et dont nous parlons de certaines d'entre elles ici sur le blog.
Concernant les détails du problème actuel, il est mentionné que la vulnérabilité détectée permet à un pilote de s'exécuter dans le noyau Linux dans une machine virtuelle JIT spéciale et que cela permet à son tour à un utilisateur local non privilégié d'obtenir une élévation de privilèges et d'exécuter son code au niveau du noyau.
Dans la description du problème, ils mentionnent que la vulnérabilité est due à une analyse incorrecte des programmes eBPF transmis pour exécution, puisque le sous-système eBPF fournit des fonctions auxiliaires, dont l'exactitude est vérifiée par un vérificateur spécial.
Cette vulnérabilité permet aux attaquants locaux d'augmenter les privilèges sur
installations du noyau Linux affectées. Un attaquant doit d'abord obtenir le
possibilité d'exécuter du code à faible privilège sur le système cible pour
exploiter cette vulnérabilité.La faille spécifique existe dans la gestion des programmes eBPF. La question résulte du manque de validation appropriée des programmes eBPF fournis par l'utilisateur avant de les exécuter.
Par ailleurs, certaines fonctions nécessitent que la valeur PTR_TO_MEM soit passée en argument et le vérificateur doit connaître la taille de la mémoire associée à l'argument pour éviter d'éventuels problèmes de débordement de la mémoire tampon.
Alors que pour les fonctions bpf_ringbuf_submit et bpf_ringbuf_discard, les données sur la taille de la mémoire transférée ne sont pas signalées au vérificateur (c'est là que le problème commence), dont l'attaquant profite pour pouvoir écraser des zones mémoire en dehors de la limite de tampon lors de l'exécution de code eBPF spécialement conçu.
Un attaquant peut exploiter cette vulnérabilité pour augmenter les privilèges et exécuter le code dans le contexte du noyau. VEUILLEZ NOTER que bpf non privilégié est désactivé par défaut sur la plupart des distributions.
Il est mentionné que pour qu'un utilisateur effectue une attaque, l'utilisateur doit pouvoir charger son programme BPF et de nombreuses distributions Linux récentes le bloquent par défaut (y compris l'accès non privilégié à eBPF est désormais interdit par défaut dans le noyau lui-même, à partir de la version 5.16).
Par exemple, il est mentionné que la vulnérabilité peut être exploité dans la configuration par défaut dans une distribution encore assez utilisée et surtout très appréciée car Ubuntu 20.04LTS, mais dans des environnements comme Ubuntu 22.04-dev, Debian 11, openSUSE 15.3, RHEL 8.5, SUSE 15-SP4 et Fedora 33, cela ne se manifeste que si l'administrateur a défini le paramètre kernel.unprivileged_bpf_disabled à 0.
Actuellement, comme solution de contournement pour bloquer la vulnérabilité, il est mentionné que les utilisateurs non privilégiés peuvent être empêchés d'exécuter des programmes BPF en exécutant la commande dans un terminal :
sysctl -w kernel.unprivileged_bpf_disabled=1
Enfin, il convient de mentionner que le problème est apparu depuis le noyau Linux 5.8 et reste non corrigé (y compris la version 5.16) et c'est pourquoi le code d'exploit sera retardé de 7 jours Et il sera publié à 12h00 UTC, c'est-à-dire le 18 janvier 2022.
Avec lui Il est destiné à laisser suffisamment de temps pour que les correctifs soient disponibles des utilisateurs des différentes distributions Linux au sein des canaux officiels de chacune d'entre elles et les développeurs comme les utilisateurs peuvent corriger ladite vulnérabilité.
Pour ceux qui souhaitent pouvoir connaître l'état de la formation des mises à jour avec l'élimination du problème dans certaines des distributions principales, ils doivent savoir qu'elles peuvent être tracées à partir de ces pages : Debian, RHEL, SUSE, Fedora, Ubuntu, Arch.
Si vous intéressé à en savoir plus sur la note, vous pouvez consulter la déclaration originale dans le lien suivant.