Reprise du message précédent :

 
1) Arrête de prendre au mot et de croire un article unique parce qu'il écrit "localhost" ( qui d'ailleurs devrait plutôt être "local" )
2) Comment tu expliques que ça passe quand je teste sur des serveurs qui sont à 500 km de ma console ?
3) Renseigne toi vraiment sur la faille elle même avant de soutenir mordicus n'importe quoi.
 
Merci.
 
P.S. : dans l'article collé ici je n'ai pas vu le mot "localhost" ceci dit, juste "local" qui signifie avoir un user local à la machine pour obtenir les privilèges.

 
 
OUI je sais mais dans le cas de cette faille précise !!!!

 
Apparement entre les experts et toi il y a eu un problème d'interprêtation foireuse là.

 
C'est un troll là, c'est pas possible...

mauvais troll

non je ne fait que rapporter ce qui est ecrit ! rien d'autre.
tout ça parceque quelqu'un a cru à un moment de ce topic que je parlait du terme "localhost" mais il n'en est rien  
ils parlent bien d'accès physique à la machine !
 
je vais donc etre beaucoup plus clair puisque vous ne voulez pas comprendre
 
aucun accès à la machine via un protocole réseau ne permet l'execution de la faille

Tu devrais revoir ton interprétation de l'"article" en question.

ben le probleme est là vous lisez 1 article et le prenez pour complet et unique verité...c'est ça votre problème.
j'en ai lu plusieurs et ils disent que la faille n'est pas exploitable via un protocole LAN.

 
 
Je comprends pas pourquoi tu insiste sachant que Sly Angel t'as dit qu'il avait testé l'exploit sur une machine distante et que tous le monde essai de te dire que tu as mal compris l'article ...

j'insiste parceque comme dit dans les article la faille ne marche que sur la debian !

Ok donc tu le fait exprés j'ai compris c'est effectivement un troll et tu es en train de t'amuser à nous ennerver en faisant le gars qui comprends rien

 
Bon tu me saoules, mets toi un 2.6.16 sur ta box, file moi un compte dessus on va bien voir.
 
Si tu le fais pas tu te fais TT
Si ça marche tu te fais TT
Si ça marche pas tu reste vivant sur le forum
 
merci au revoir

 
je me marre tout seul comme un imbécile devant mon écran maintenant

L'auteur du topic a lancé un vieux troll des cavernes mais finalement on se marre quand même.

http://www.securityfocus.com/bid/18874
http://www.securityfocus.com/bid/18874/discuss
 
http://www.securityfocus.com/bid/18874/exploit
 
 
 
Quand tu lis le source de cet exploit là => http://downloads.securityfocus.com [...] rctlpute.c
c'est évident que n'importe quel user qui a un compte sur la machine ciblée, peut monter en privilèges.
Il suffit juste qu'il soit logué sur la machine en question (soit devant elle, soit à distance via SSH) et puisse lancer son "banal" petit exec.
 
Si tu sais pas lire le C, insistes pas, tu risques pas de comprendre grand chose à tout ça

Petite question pendant qu'on parle de failles :
Si sur la machine il n'y a que le port 80 qui est ouvert est ce qu'un exploit via apache peut permettre de lancer un shell ?

non pas que je sache mais vu qu'il y a des gens ici qui se disent meilleurs que les expert professionnels  
ils te donneront la solution en moins de 10minutes......

 
Oui, notamment surtout si tu as du PHP. Par exemple tu as un code PHP faillible qui te permet par exemple d'uploader du code PHP à soi ou de passer en argument une commande PHP.
 
Si le serveur est non secure, tu peux imaginer executer une fonction comme system() dans le code PHP dont le rôle est justement de te permettre de lancer des commandes shell.
 
Derrière tu peux imaginer lancer un truc du style : export DISPLAY="<IP>:0.0"
 
Ensuite tu t'envoie un terminal à distance et tu as un shell, par exemple.
 
Arrivé là, tu compiles ton petit prtcl.c qui exploite la faille et tu le lances. Maintenant tu es root.
 
 
C'est un exemple basique, y'a 36 façons de faire, y'a aussi des softs en PHP qui font remote shell.
 
A partir du moment où tu as un service sur le net, il est possible potentiellement d'avoir une faille qui permette d'obtenir un moyen d'éxécuter des commandes avec le user du service. Après une fois là, c'est comme être physiquement sur la machine avec ce compte user.
 
Le chroot est une solution "relativement" fiable pour emprisonner un service dans un environnement fermé et épargner le reste du système lors d'une faille sur le service concerné. Ca entraîne une flexibilité moindre également.

 
Au revoir

 
Je crois que tu as plusieurs personnes ici qui justement sont professionnels de la sécurité des systèmes et réseaux
Qu'est ce qui te fait croire qu'il n'y a que des trolleurs comme toi sur hfr ?

C'est déjà arrivé qu'on découvre des failles de types buffer overflow, par exemple, permettant l'execution directe d'un code malicieux, dans apache (core ou un de ses modules), oui.
 
Mais bon, si t'es à jour dans apache, tu devrais pas trop avoir de souci, celles qui ont été découvertes, ont été corrigées.
 
  Si tu veux en savoir plus, visistes des sites comme securityfocus.com ou secunia.com où elles (enfin celles qui ont été rendues "publiques" ... ) sont répertoriées, et classifiées, avec qd c'est possible la parade.
 
EDIT :  tiens si t'es intéressé par Apache, en particulier :
http://secunia.com/advisories/21197/
http://secunia.com/product/73/

Merci de tout ces renseignements je vais potasser tout ça.
 
Il est en vacances combien de temsp francoispg p ?  

 
 
merci il est parfois insupportable ce type

   Tes informations sont purement et simplement erronées.
 
Voici la description _exacte_ de la faille :

Source ---> http://www.cve.mitre.org/cgi-bin/c [...] -2006-2451
 
Voici le résumé officiel émanant de Debian :

Source ---> http://www.debian.org/News/weekly/2006/29/
Détails ---> http://www.debian.org/News/2006/20060713
 
Ce que tu dis impliquerait qu'une personne malintentionnée soit parvenue à accéder _physiquement_ au serveur gluck.debian.org, ce qui est complètement faux comme le confirme le communiqué de Debian.
 
Par vulnérabilité locale, on entend par là que la faille ne peut être qu'uniquement exploitée via un compte existant localement sur le système concerné, l'accès à ce compte local se faisant physiquement ou à distance en fonction de ce serveur (dans le cas de Debian, les développeurs accèdent à distance à leur compte sur gluck.debian.org, ils ne sont pas physiquement à côté du serveur sans quoi le travail deviendrait ridicule).
 
 
 

Tu ne cites à aucun moment tes sources... Je te renvoie à celles postées ci-dessus : l'une d'entre elles provient directement de Debian, je pense que les devs concernés savent de quoi ils parlent non ?
 
 
 

Personne ici n'a prétendu être meilleur que les experts professionnels, d'ailleurs ces derniers n'ont pas du tout donné les prétendues conclusions que tu cites.
A moins que tes affirmations soient trollogènes, expert ou pas, un minimum de bon sens permet en moins de 10 minutes de comprendre la nature du problème...
 
 
 
Note :  
Ma réponse n'a pas pour but de donner une quelconque leçon ou de faire la morale, mais de fournir des renseignements concis basé sur des faits concrets. Franchement je ne comprend pas comment ce topic a pu en arriver là et déraper à ce point, le sujet n'a pourtant rien d'ambigüe à la base