Commentaires sur : Local Root Exploit sous Linux http://www.tux-planet.fr/local-root-exploit-sous-linux/ Linux et les Logiciels Libres Fri, 10 Feb 2012 19:56:33 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Par : k3vin mitnick http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-11115 k3vin mitnick Mon, 18 Aug 2008 12:31:38 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-11115 C'est mieux en ajoutant cette ligne : chmod 777 vmsplice-local-root-exploit.c (^ ^,) C'est mieux en ajoutant cette ligne :
chmod 777 vmsplice-local-root-exploit.c

(^ ^,)

]]> Par : pti-seb http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3197 pti-seb Mon, 18 Feb 2008 19:25:57 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3197 <p>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 :<br /> <br /> Distribution => Delay<br /> Debian GNU/Linux => +0 hours<br /> Fedora => +8 hours<br /> Slackware Linux => +12 hours<br /> Mandriva Linux => +19 hours<br /> Frugalware Linux => +21 hours<br /> openSUSE => +23 hours<br /> rPath Linux => +26 hours<br /> Red Hat Enterprise Linux => +27 hours<br /> Ubuntu => +27 hours<br /> CentOS => +37 hours<br /> <br /> On remarque que la plupart des distributions ont réagi très rapidement.</p> 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.

]]> Par : Julien http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3187 Julien Fri, 15 Feb 2008 17:12:49 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3187 <p><b>@Vincent</b> :<br /> Clairement, mais c'est fréquent le cas.</p> @Vincent :
Clairement, mais c'est fréquent le cas.

]]> Par : pti-seb http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3176 pti-seb Fri, 15 Feb 2008 16:37:47 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3176 <p><b>@Visiteur</b> : effectivement, le code de l'exploit n'a pas été pensé pour cette architecture.</p> @Visiteur : effectivement, le code de l'exploit n'a pas été pensé pour cette architecture.

]]> Par : freeflyer http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3186 freeflyer Fri, 15 Feb 2008 15:50:22 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3186 <p>> Compile même pas sur mon macbook (powerpc / debian).<br /> <br /> Euh tu pensais vraiment qu'un source C avec de l'assembleur i386 dedans allait compiler sur powerpc ?<br /> (Pis en power pc comme ça serait pas plutôt un powerbook ou un ibook ?)</p> > 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 ?)

]]> Par : visiteur http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-1809 visiteur Fri, 15 Feb 2008 15:44:23 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-1809 <p>Compile même pas sur mon macbook (powerpc / debian).</p> Compile même pas sur mon macbook (powerpc / debian).

]]> Par : Vincent http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3175 Vincent Wed, 13 Feb 2008 18:36:52 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3175 <p>Oui enfin ceux qui laissent un accès ssh au gens sans faire exprès méritent des baffes ...<br /> Pour le ftp en compte système il suffit de ne pas permettre aux comptes de se logger ( /bin/false comme shell, etc )</p> 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 )

]]> Par : Julien http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3174 Julien Wed, 13 Feb 2008 18:01:03 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3174 <p><b>@Jey</b><br /> Un pureftpd configuré avec des comptes users comme clients permet à ces derniers d'accéder à la machine via ssh. </p> @Jey
/>
Un pureftpd configuré avec des comptes users comme clients permet à ces derniers d'accéder à la machine via ssh.

]]> Par : Jey http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3173 Jey Wed, 13 Feb 2008 17:27:08 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3173 <p><b>@Julien</b>: 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.<br /> 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.<br /> <br /> 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).<br /> <br /> <b>@Pti-seb</b> : 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!).<br /> <br /> 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.<br /> Bye!</p> @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!

]]> Par : pti-seb http://www.tux-planet.fr/local-root-exploit-sous-linux/#comment-3171 pti-seb Tue, 12 Feb 2008 23:42:03 +0000 http://127.0.0.1/wordpress/2008/02/12/local-root-exploit-sous-linux/#comment-3171 <p><b>@Julien</b> : 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.<br /> <br /> C'est sûr, c'est pas forcément la meilleure méthode à utiliser.</p> @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.

]]>