ls */../*/../*/../*/../*/../* (etc.) pour que le démon prenne subitement toutes les ressources (cpu et mémoire) de la machine qui finit par s'écrouler.
Le serveur FTP de NetBSD semble avoir le meme problème et il est possible que d'autres logiciels soient concernés par la meme faille.
L'équipe de ProFTPd tente de résoudre le bug, classé critique.
update: PureFTPd, qui n'aurait pas avoir avoir ce bug (mais qui l'a quand même). L'auteur s'est fait avoir à son propre jeu, hihihi :-)
Aller plus loin
- ProFTPd (4 clics)
- PureFTPd (qui a ce problème) (6 clics)
- NetBSD (3 clics)
# pub
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: pub
Posté par Anonyme . Évalué à 0.
[^] # Re: pub
Posté par j . Évalué à 1.
Le FTP de Solaris et BeroFTPd se font avoir aussi...
C'est la fete.
[^] # Re: pub
Posté par Anonyme . Évalué à 0.
DenyFilter /\*/\.\.
Apparemment, son auteur te l'a envoyé, pourquoi ne l'as-tu pas transmise aussi???
Ensuite en vrac:
-je note que ton système de protection contre l'attaque est léger:
doshack = strstr(arg, "/../");
-pour ce qui est de la mauvaise foi, je pense que tu n'as pas de leçon à leur donner vu ton attitude à leur égard. Comme l'a très justement rappelé Daniel (l'intervenant proftpd), il y a des règles pour la divulgation d'une faille et tu t'es assis dessus.
-enfin, concernant le blocage de leur serveur, tested on the Proftpd site, c'est toi qui l'écrit...
Mes 2 centimes...
[^] # Re: pub
Posté par j . Évalué à 1.
Merci aussi pour sa mauvaise foi et ses fausses accusations (je n'ai jamais bloqué leur serveur).
Cela dit, c'est vrai qu'on a plutot les boules quand un gros trou de sécu est découvert dans ce que l'on vient de coder. J'en ai chialé et je n'ai pas pu fermer l'oeil de la nuit. Enfin bon, au moins ce bug ne sera plus dans la 1.0 .
[^] # Re: pub
Posté par Anonyme . Évalué à 0.
15 minutes avant de poster le meme message sur
bugtraq ;)
# pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Il y a malheureusement des abrutis/script kiddies partout et ca serait con qu'un abruti passant par la se mette a essayer ca sur des serveurs au hasard pour voir si ce qu'il a lu fonctionne vraiment, surtout vu que le bugfix n'est pas encore sorti.
Donc je propose aux moderateurs de virer la ligne "ls blablabla".
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
héhé!
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
[^] # Re: pas une tres bonne idee...
Posté par bmc . Évalué à 1.
sur Sid et ça le fait, et c'est meme assez violent...
[^] # J'ai essayé...
Posté par Rafael Pinilla . Évalué à 1.
Ca fait monter progressivement la charge, in.proftpd prend 85% de CPU, et puis c'est tout. Noyau 2.2.16 à la sauce RedHat.
Et puis après, cela s'arrete tout à coup.
Ca ne perturbe pas du tout le debit ADSL en download de la woody.
Stable.
Critique, sans doute, mais je précise que mon routeur est un P133/32Mo. Par une brute bipro. Même pas SCSI, juste 2x1Go IDE. Carte réseau 3com quand même. Fait pas delirer.
Bref, si critique que cela ? Ceci dit, j'ai pas essayé avec un transfert en même temps...
Re Bref, pas impressionné par le bug. C'est un bug qui ne bugue pas beaucoup...
Bug, peut être, mais critique ?.?.?.?
Bof.
[^] # Re: J'ai essayé...
Posté par j . Évalué à 1.
Si tu n'as quasiment aucun répertoire dans ton FTP c'est normal que l'effet ne soit pas transcendant non plus.
[^] # Re: pas une tres bonne idee...
Posté par Ramón Perez (site web personnel) . Évalué à 1.
A partir de là les connections commencent à ramer par manque de mémoire (une connection à la machine en local prend une 15aine de secondes ;-)
Puis lorsque toute la ram et le swap sont plein, le noyau tue proftpd, en faisant un joli core de la taille complète du swap + de la ram (à moins d'un ulimit), et là n'espérez plus vous connecter au serveur...
Le même problème se produit si quelqu'un exécute la commande en shell...
Bon, c'est un peu le même genre de problème que le while(fork()); il faut limiter la taille en ram, le nombre de process, ....
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
ceci dit, on peut faire l'autruche du genre: "si c'est pas moi qui le fait, ca sera qqun d'autre..."
moraliré: plus vite y zaurons corrigé le bug, mieux ca sera !
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
Et si quelqu'un le fait sur mon serveur, ça m'apprendra et ne pas updater/patcher mes services. Je préfère savoir et me protéger que faire l'autruche.
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Tu sais lire ?
C'est ecrit : "L'équipe de ProFTPd tente de résoudre le bug, classé critique. " ce qui signifie que le bugfix n'est PAS encore disponible.
Tu veux te proteger comment si le patch est pas dispo a part arreter ton serveur ftp ?
Et question, si ca avait ete "lolofeduvelo" qui avait ecrit ce message et pas moi, t'aurais reagi comme ca ? ou bien c'est juste du delit de sale gueule ?
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Maintenant, si t'as envie de te foutre de moi, vas-y te gene pas, t'es libre de le faire et je vais pas m'amuser a demander a Fabien qu'il cree un killfile pour autant, et je viendrais pas non plus te dire "t'es gonflant casse toi d'ici" pour la simple et bonne raison que j'y ferais pas attention et j'y repondrai pas au lieu d'essayer d'eliminer l'interlocuteur quand ce qu'il dit ne correspond pas a mon opinion.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à -1.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à -1.
ouverture d'esprit + politesse : lance un double dé 6 (pipé bien sur)
k`
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à -1.
[^] # Re: pas une tres bonne idee...
Posté par Mjolnir! . Évalué à -1.
[^] # Re: pas une tres bonne idee...
Posté par Ano . Évalué à 1.
Pour faire passer les utilisateurs linux pour des crétins boutoneux, y'a pas mieux...
[^] # Re: pas une tres bonne idee...
Posté par Mjolnir! . Évalué à 1.
Merci de faire le nécessaire.
[^] # Re: pas une tres bonne idee...
Posté par Mjolnir! . Évalué à -1.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
On peut très bien être anti linux et venir racconter des con-bip-rie sur LinuxFR.
Ca n'empeche que ça n'est pas polis.
[^] # Re: pas une tres bonne idee...
Posté par Benjamin . Évalué à 1.
[^] # Re: pas une tres bonne idee...
Posté par Benjamin . Évalué à 1.
euh, c'est pas déjà fait ? ou c'est seulement quand ca t'arrange qu'il faut le faire remarquer ?
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Enfin bon, je crois que toi et moi on sait qu'on arrivera pas a se convaincre la dessus, donc si on revenait a la discussion initiale qui est cette vulnerabilite de ProFTPd et autres serveurs ftp.
[^] # Re: pas une tres bonne idee...
Posté par Benjamin . Évalué à 1.
Tu dis, "On domine le desktop" et "Vous etes paranos en disant que MS veut dominer le non-desktop".
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Quand je parles de cette "parano" a propos de MS, pour moi c'est que j'ai l'impression que vous voyez MS comme un big brother qui veut tout controler, tout decider a la place des gens et qui essayerait d'eliminer les concurrents par tous les moyens possibles.
Oui MS veut etre leader dans tous les marches ou il est present, comme toute societe. Non MS n'est pas ce big brother dont tout le monde parle.
[^] # Re: pas une tres bonne idee...
Posté par j . Évalué à 1.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
temps, cpu, ram ???
(?)
[^] # Re: pas une tres bonne idee...
Posté par j . Évalué à 1.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à -1.
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à -1.
pasBill(qui se met -1 lui aussi)
[^] # Re: pas une tres bonne idee...
Posté par hostbot . Évalué à 1.
et si après lecture attentive, tu n'es toujours pas mort d'indigestion cérébrale, tu peux toujours allez faire un tour sur FR.USENET.FORUMS.EVOLUTION et poster un AAD quelconque, du genre fr.masses.education.revitalisation.par.le.vide
j'ai volontairement écris lisiblement pour que tes petits yeux de graine de censeur puisse lire de façon intelligible la référence citée.
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Ca fait du bien des posts comme ca, ca me fait sentir qu'on se preoccupe de moi :+)
T'as pas d'autres liens histoire que le neuneu que je suis puisse en apprendre plus ?
pasBill(qui se met -1 de nouveau car ca merite pas mieux)
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à -1.
- impoli
- mauvaise orthographe(il y a un 's' qui manque a retourne et un 'e' a b*)
- lache car anonyme
- peu imaginatif(le meme post 2 fois)
Non franchement c'est joli, il y a pas a dire, tu vas surement arriver a me faire partir avec des arguments de ce genre :+)
pasBill(qui se marre et se met -1)
[^] # Re: pas une tres bonne idee...
Posté par Mjolnir! . Évalué à -1.
Pfff...
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à -1.
[^] # Re: pas une tres bonne idee...
Posté par Griffone . Évalué à 1.
La démonstration de ceci,c'est Debian.
Et n'importe comment,il vaut mieux être au courant des vulnérabilitées de son système,comme ca au moins tu es incités à chercher une solution pour résoudre le problème par toi-meme.
Pour ce qui est de ceux qui pourront exploiter cette faille pour faire chier le monde,dis-toi qu'ils l'auraient découverte tôt ou tard.Donc autant prendre les devants
Si tu ne connaissais pas les vulnérabilitées de ton système,je doute que tu puisses en faire autant.
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Je dis pas qu'il ne faut pas dire qu'il y a un trou de securite, je dis qu'il ne faut pas donner la ligne exact de ce qui cree le probleme tant qu'on a pas le bugfix.
Regarde quelques posts plus bas, un admin a vu en live un petit merdeux essayer de tester ca sur son serveur. Si ca se trouve, ce petit con a vu la ligne sur linuxfr et s'est dit qu'il allait essayer. Heureusement il n'est rien arrive, mais ca montre le risque, vu que tu ne peux pour l'instant pas te premunir contre ce DoS.
PS: ca fait plaisir de voir des gens polis et qui parlent de maniere intelligente :+)
[^] # Re: pas une tres bonne idee...
Posté par Jean-Sébastien Samson . Évalué à 1.
Il faut arrêter d'être de mauvaise foi et de parler de censure ou autre grande idée sur le dos de laquelle on fait tout passer : n'importe qui qui s'intéresse réellement à la sécurité de son serveur FTP peux suivre les liens ou aller sur la homepage pour voir ce qu'il en est. Afficher partout comment foutre le bordel sur un serveur FTP ce n'est pas très malin, et n'annoncer que le problème sans donner toute la procédure, ce n'est pas de la censure, c'est simplement éviter de tenter tous les script-kiddies.
[^] # Re: pas une tres bonne idee...
Posté par gle . Évalué à 1.
La seule solution est à mon sens de fixer des limites au % de cpu et de ram utilisable par un process FTP, où à la durée d'une requête.
Mais pour moi ce n'est pas une erreur de programmation, donc pas de bugfix.
[^] # Re: pas une tres bonne idee...
Posté par j . Évalué à 1.
*/../* est interprété comme une recherche recursive, il va, à l'intérieur d'un répertoire, lister tous les répertoires un niveau au dessus, c'est à dire entre autres lui-meme, d'où une boucle.
C'est un peu comme si tu faisais :
ln -s . toto
et que tu faisais des 'cd toto' sans cesse en esperant tomber un jour sur autre chose que 'toto'.
[^] # Re: pas une tres bonne idee...
Posté par Laurent Saint-Michel . Évalué à 1.
voila ...
[^] # Re: pas une tres bonne idee...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: pas une tres bonne idee...
Posté par gle . Évalué à 1.
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Tu sais faire la difference entre dire qu'il y a un trou de securite et donner la marche a suivre pour appliquer le DoS et crasher le serveur ?
Tu arrives a me citer ou est-ce que j'ai dit qu'il ne fallait pas annoncer qu'il y avait un trou de securite ?
Si tu n'y arrives pas, je te prierais a l'avenir de lire 3 fois minutieusement ce que j'ecris avant de me sauter a la gorge et m'agresser parce que je bosses pour une boite que tu n'aimes pas.
A bon entendeur, salut
[^] # Re: pas une tres bonne idee...
Posté par Anonyme . Évalué à 0.
Un truc bien neutre genre bob...
[^] # Re: pas une tres bonne idee...
Posté par pasBill pasGates . Évalué à 1.
Mais bon, ca m'a donne une idee ton conseil...:+)
# Wah
Posté par Anonyme . Évalué à 0.
M'enfin moi je viens d'assayer avec une version CVS de ProFTPD qui date d'octobre 2000 (un peu après la 1.2.0rc2) et ça n'a pas marché... j'ai pourtant insisté en mettant une bonne grosse ligne au cas où mais ça a fini par me dire "line too long" et c'est tout.
Par curiosité j'essayerai sur un BSD et sur un ProFTPD plus récent ;-)
# Des paquets debian pour pureftpd ?
Posté par bmc . Évalué à 1.
[^] # Re: Des paquets debian pour pureftpd ?
Posté par j . Évalué à 1.
Recupere le source, puis tape 'dpkg-build' et tu auras le .deb ... N'hesite pas à me l'envoyer pour le mettre sur sourceforge.
[^] # Re: Des paquets debian pour pureftpd ?
Posté par j . Évalué à 1.
[^] # Re: Des paquets debian pour pureftpd ?
Posté par bmc . Évalué à 1.
[^] # Re: Des paquets debian pour pureftpd ?
Posté par j . Évalué à 1.
Merci encore pour ton aide.
S'il y a ici un membre de Debian qui veut maintenir le package, il est le bienvenu !
[^] # Re: Des paquets debian pour pureftpd ?
Posté par Anonyme . Évalué à 0.
[^] # Re: Des paquets debian pour pureftpd ?
Posté par bmc . Évalué à 1.
Et, pour information, mon paquet Debian était tellement pourri (c mon premier :) qu'il en a refait un lui-meme.
Satisfait ?
# écrouler = quoi exactement
Posté par Anonyme . Évalué à 0.
La machine finit par planter ? PAS BIEN :-) Théoriquement ça ne devrait pas arriver car linux devrait tuer le processus avant (mais à l'époque c'était possible avec des scripts perls en boucle infinie par exemple).
Si ceux qui ont testés peuvent m'éclaircir...
[^] # Re: écrouler = quoi exactement
Posté par pasBill pasGates . Évalué à 1.
Mais sinon, effectivement les sites qui n'ont pas de ftp anonyme ne risquent pas grand chose, car il faut que l'user se logge pour lancer ca, et a moins d'avoir un compte "vole", ca revient a ecrire son nom sur le mur de la banque apres l'avoir braquee.
Note que ce genre d'aneries arrive quand meme, il y a pas longtemps aux USA, un gars s'est fait arrete apres avoir braque une banque : il avait tendu a la caissiere un message disant "je suis arme, donnez le cash"(ou un truc identique), la caissiere a obei et le gars s'est enfui, mais le probleme est qu'il avait ecrit ca sur une de ses cartes de visite, pas fute le gars...
[^] # Re: écrouler = quoi exactement
Posté par Anonyme . Évalué à -1.
Aux USA c'était pas forcément une anerie :)
[^] # Re: écrouler = quoi exactement
Posté par vrm (site web personnel) . Évalué à 1.
[^] # Re: écrouler = quoi exactement
Posté par pasBill pasGates . Évalué à 1.
Ca te permet de :
- specifier un nbre max de process
- un temps CPU limite total, une fois que le temps est atteint tous les process du job sont killes
- un temps CPU limite par processus
- sur quel processeur les processes du job tournent
- la priorite pour tous les processus du job
- limiter l'usage de la memoire
- modifier les droits d'acces des processes
- limiter l'acces a la GUI pour les processus
[^] # Re: écrouler = quoi exactement
Posté par vrm (site web personnel) . Évalué à 1.
Merci quand même
[^] # Re: écrouler = quoi exactement
Posté par oliv . Évalué à 1.
# Ca ne marche pas DU TOUT ton truc
Posté par Anonyme . Évalué à 0.
Résultat : le serveur n'a rien senti, il ne se passe RIEN, mais alors RIEN de RIEN.
Par contre, c'est le petit lamer qui a tenté le coup qui va devoir rapidement changer de provider, car mon rapport à abuse@wanadoo.fr est parti aussi sec.
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Anonyme . Évalué à 0.
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Ramón Perez (site web personnel) . Évalué à -1.
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Anonyme . Évalué à -1.
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Ramón Perez (site web personnel) . Évalué à -1.
Moi le genre de réflexion "le mec fait une tentative de connexion, ça veut dire qu'il a voulu pirater ma machine, faut que je le dénonce pour le bien de la société" m'énerve depuis que j'ai reçu un mail de plainte du abuse@wanadoo parce j'avais recherché la machine d'un pote en faisant des nmap sur une plage IP...
En plus, rien que le fait de faire une dénonciation anonyme (car le "pseudo-pirate" ne saura jamais qui l'a dénoncé), je trouve ça malsain....
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par gen_origi . Évalué à -1.
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Anonyme . Évalué à 0.
2- Je t'emmerde. Si un gars tape ce ls de merde, ce n'est certainement pas innocent ; il est manifeste qu'il cherche à foirer la machine
3- Si tu n'es pas content qu'on te dénonce quand tu joues au gr0 warL0rd, alors retourne au bac à sable. Un lamer n'a pas droit à la moindre pitié.
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Anonyme . Évalué à 0.
J'en ai rapporté plusieurs vers plusieurs FAI et seulement quelques-uns repondent (donc encore moins s'en occupent reellement). La meilleure réponse (avec action) que j'ai eu c'est quand j'ai dénoncé un mec qui utilisait une machine d'entreprise pour faire ses forfaits ...
Il faut dire que les FAI doivent en recevoir des tonnes de mail à "abuse".
Quelques regles quand on dénonce:
-ne pas le faire anonymement
-mettre un copie des logs (synchroniser la machine
en NTP pour que l'heure des logs soit interessante, sinon avec toutes les connexions actuelles en IP dynamique, le FAI ne peux pas trouver le bon client).
-ne pas s'attendre a grand chose en retour :-)
-ne pas oublier que l'IP Spoofing ca existe... le plus sur c'est d'etre la quand ca arrive, de prendre vite fait un shell et d'essayer de trouver des preuves que l'IP est reelle.
Enfin autre chose pour le warlodz en puissance:
sachez qu'un simple scan de port avec nmap peut faire tomber la machine visée ou une des applis de la machine visée si c'est de la merde (ca existe !!). Du coup, c'est passible de prison ...
Moi je dis ne jouez pas avec les serveurs d'autruit :-)))
PLuG
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Anonyme . Évalué à 0.
je l'utilise comme ca pour le fun, et je trouve que les FAI ont bien raison de ne pas s'occuper des dénonciations de ce genre.
Actuellement, la plupart des scans de ports sont faits par des robots. et ce n'est pas le "warlodz" de chez wanadoo qui sera très dangereux pour toi.
A moins que tu sois complètement parano...
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Ramón Perez (site web personnel) . Évalué à -1.
En fait ce qui m'a le plus énervé c'est le ton de ton message : un mec qui utilise courrament les mots warL0rd, lamer, ... je le vois difficilement administrateur système...
Mais bon, c'est peut être de l'humour...
En tout cas, j'ai trouvé une superbe fortune moi :
"Si tu n'es pas content qu'on te dénonce quand tu joues au gr0 warL0rd, alors retourne au bac à sable. Un lamer n'a pas droit à la moindre pitié."
[^] # Re: Ca ne marche pas DU TOUT ton truc
Posté par Anonyme . Évalué à 0.
# Corriger le problème
Posté par Vanhu . Évalué à 1.
1) Le gars qui suit les problèmes de sécurité informatique uniquement sur Linuxfr, il a un problème.
2) Un workaround *existe* !!!
Sur la mailing-list proftpd:
--------------
Date: Thu, 15 Mar 2001 22:30:10 +0300
open your proftpd.conf file, and add
DenyFilter /\*/\.\.
in ALL sections, include <Global>.
--------------
Le filtre n'est pas idéal, puisque le post ne concernait que la variante */../*/..* (....), mais il suffit de le travailler un peu, et dès hier, on était protégés contre le plus probable...
Ensuite, sur n'importe quel serveur à peu près bien configuré, *aucun* service ne devrait tourner sans un minimum d'encadrements, au moins avec ulimit.
Enfin, un problème "critique", pour moi, c'est un remote root accès, pas un DOS !
A +
VANHU, qui va quand meme surveiller la sortie du patch...
[^] # Re: Corriger le problème
Posté par pasBill pasGates . Évalué à 1.
Le vrai hacker, il trouvera de toute facon qu'on montre ou pas l'exploit, mais le script kiddie, si il doit chercher l'exploit ca devient deja beaucoup plus problematique pour lui, et de cette maniere ca permet de limiter les DoS de la part de petits cons jusqu'a ce que le bugfix soit dehors.
On peut meme donner des infos sur le type de la faille, genre c'est du a une utilisation particuliere de ls,... l'important etant de ne pas donner aux script kiddies un travail tout fait.
[^] # Re: Corriger le problème
Posté par Anonyme . Évalué à -1.
Moi j'apprécie beaucoup la petite phrase bien ironique et cinglante sur le site de proftpd:
"Additionally, the administrators of ftp.proftpd.org would like to thank Frank Denis for testing his theory about the vunerability by launching a denial of service attack against that server, causing it to become unavailable for a period of time."
C'est vrai que c'est assez révélateur de l'état d'esprit dans lequel ce bug a été posté... Aller vérifier un bug en crashant un serveur sans prévenir puis le diffuser à la terre entière c'est vraiment nul.
- Jeff
[^] # Re: Corriger le problème
Posté par j . Évalué à 1.
Quant au workaround, il a été posté moins d'une heure après que je leur ait reporté la faille.
La vulnérabilité a été publiée sur bugtraq *après*.
En revanche, ils n'ont pas hésité à cracher sur pureftpd en publiant une variante, 30 secondes seulement après avoir posté un message sur un forum censé m'en avertir.
Alors reste à démontrer qui a commencé les hostilités... celui qui signale un bug ou celui qui ment sans raison ?
Entre logiciels opensource et free, ça n'a franchement aucun intéret de vouloir une guerre. Soit on poursuit des objectifs différents, soit on s'entraide.
[^] # Re: Corriger le problème
Posté par Matthias Saou . Évalué à 1.
C'est un avis personnel (en rien une attaque personnelle) et dans l'absolu, soit j'ai tort, soit tu t'en rendra compte avec un peu de recul, mais je trouve aussi ton comportement sur BUGTRAQ et ton test dirigé directement vers le serveur ProFTPD officiel un peu exagérés. Sans parler de la news quasi-instantanée sur linuxfr...
[^] # Re: Corriger le problème
Posté par bmc . Évalué à 1.
Maintenant, il a dit et répété qu'il n'était pas l'auteur du "test" sur le serveur proftpd officiel, et d'ailleurs je ne vois pas à quoi ça l'aurait avancé. Faire comprendre à l'équipe proftpd que le bug était sérieux ? il leur dit et poste sur Bugtraq => ils sont obligés d'y faire attention.
Et puis à ma connaissance il ne gagne pas de sous sur pureftpd.
Maintenant, que les différentes annonces soient trop rapprochées de la découverte du bug, j'avoue que je ne lis pas bugtraq (je ne suis pas admin système) mais que j'apprecie etre tenu au courant des failles importantes des logiciels que je suis susceptible d'utiliser.
D'autant que sur la mailing-list de pureftpd, on peut trouver un patch pour ProFTP, alors qu'on arrete un peu la parano, ce sont deux logiciels libres.
# La même ligne avec bash
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
ulimit est mon ami.
# ftpd freebsd
Posté par Anonyme . Évalué à 0.
[^] # Re: ftpd freebsd
Posté par j . Évalué à 1.
Sur un ftp anonyme tous les serveurs font un chroot() de toutes façons.
[^] # Re: ftpd freebsd
Posté par dcantin . Évalué à 1.
# post bugtraq
Posté par j . Évalué à 1.
Luis Miguel Ferreira Silva <lms@ispgaya.pt>
To: jedi@CLARANET.FR
Cc: BUGTRAQ@SECURITYFOCUS.COM
Date: 16 mar 2001, 11:10:24
Subject: Re: [Bug 1066] Changed - Globbing bug - denial of service (fwd)
ahmm, this looks pretty WEIRD.. ;)
A dewd writes stating that HE found a bug [at least, it looked like it]...
Showed a "paste" of the proftpd site crashing...
And then, proftpd states that they where the ones who found the bug?!
ROTFL :)
On Thu, 15 Mar 2001 jedi@CLARANET.FR wrote:
> > > The globbing bug has been confirmed and tracked by the Proftpd team.
> > --
> -=- Frank DENIS aka Jedi/Sector One <j@c9x.org> -=-
> "If Bill Gates had a dime for every time a Windows box crashed...
> ... Oh, wait a minute, he already does."
> > >
[^] # Re: post bugtraq
Posté par j . Évalué à 1.
Comme par hasard.
# Shells...
Posté par j . Évalué à 1.
echo */../*/../*/../*/../*/../*/../*/../*/../*
ash,ksh,bash,zsh,csh, le sh de solaris... apparemment ils partent tous en boucle.
Quant à wuftpd, ils n'ont *pas* réellement fixé le problème. Ils s'arretent lorsque la ligne est trop longue, ce qui peut se produire pour des requetes tout à fait ordinaire si le nom des fichiers est long ou que l'on est loin dans les sous-répertoires.
[^] # Re: Shells...
Posté par Mjolnir! . Évalué à 1.
[^] # Re: Shells...
Posté par Anonyme . Évalué à 0.
Qqun essaye un petit dir */../*/../*/../*/../*/.. pour voir...
nicO
[^] # Re: Shells...
Posté par j . Évalué à 1.
Les autres globs ont déjà été protégés dans la 0.96 (et ne concernent pas les utilisateurs anonymes de toutes façons) .
Quant au post 15 minutes après sur bugtraq, il faudrait apprendre à lire les dates sur les en-tetes des mails... Ca fait plutot 3 heures (après le fix) .
Bon allez zou, chacun retourne auditer son code. Plutot que de glander sur Linuxfr, allons tester nos CGI/shells/serveurs pour coder les patches.
# mdr!
Posté par Anonyme . Évalué à 0.
Adieu les super-slogans-limite-narcissiques mon cher Jedi ;-)
OK, la version 0.96 corrige, mais ce qui est découvert est découvert... va falloir upggrader les ftpd et virer tous les paragraphes trop élogieux des docs :-)))
[^] # Re: mdr!
Posté par Matthias Saou . Évalué à 1.
--
[NOTE to the fellow readership: "Frank DENIS (Jedi/Sector One)" is
the author of Pure-FTPD]
On Thu, Mar 15, 2001 at 09:34:09AM +0100, Frank DENIS (Jedi/Sector One) wrote:
> - Proftpd built-in 'ls' command has a globbing bug that allows remote
> denial-of-service.
>
> Here's a simple exploit, tested on the Proftpd site :
That's really great. Very convenient for you to run DoS attacks against
the main distribution site of ProFTPD.
> - PureFTPd (any version) is not vulnerable. Result is "Simplified wildcard
> expression to *" and the 'ls *' output.
It is not vulnerable to the simple attack, but to more "sophisticated"
attacks it is. 20 seconds spent looking into the source reveals:
from pure-ftpd-0.96/src/ls.c:
/* try to defend against wildcard denial-of-service attack */
doshack = strstr(arg, "/../");
if (doshack) {
/* first eliminate those at the start */
if (doshack == arg) {
while (strncmp(arg, "/../", 4) == 0) {
size_t cpa = strlen(arg + 4) + 1U;
memmove(arg, arg + 4, cpa);
}
doshack = strstr(arg, "/../");
}
/* next, eliminate /../ in the middle of the string */
while (doshack) {
char *nextcomponent = doshack + 4;
size_t cpa;
if (doshack != arg && *doshack == '/')
doshack--;
while (doshack != arg && *doshack != '/')
doshack--;
if (*doshack == '/')
doshack++;
cpa = strlen(nextcomponent) + 1U;
memmove(doshack, nextcomponent, cpa);
doshack = strstr(arg, "/../");
}
addreply(0, "Simplified wildcard expression to %s", arg);
}
So your defense is just removing "/../" sequences. That's not enough.
ls .*./*?/.*./*?/.*./*?/.*./*?/.*./*?/.*./*?/.*./*?/.*./*?/.*./*?/
ls */.*/*/.*/*/.*/*/.*/*/.*/*/.*/*/.*/*/.*/*/.*/*/.*/*/.*/*/.*/
These lead exactly to the same problems ProFTPD has. You've only gone
half-way. Thanks to John Morrissey <jwm@horde.net> for verifying this
on a test installation of Pure-FTPD.
BTW: Flood (Jesse Sipprell <jss@inflicted.net>) found that you are using
unprotected calls to glob() all over the place and concludes that it
would be trivial to launch this attack against other FTP commands (DELE
etc.) against Pure-FTPD as well.
I guess you should re-think your Skill inventory on Sourceforge:
http://sourceforge.net/people/viewprofile.php?user_id=37669(...)
Same with the statement "Unlike other popular FTP servers, it has no
known security flaw" on the Pure-FTPD homepage.
King for a day, fool for a lifetime, eh?
> Maintainers of vulnerable servers have been warned of this bug.
Yes. 15 *minutes* before you sent this posting off to Bugtraq. I'm not
going into the usual discussion about how to handle security problems.
May the fellow readership judge for themselves how responsible your
behaviour was.
You may want to take a look at http://www.wiretrip.net/rfp/policy.html(...)
For ProFTPD users: an official response with a workaround to the problem
is being released right now here to Bugtraq.
Daniel
ProFTPD RPM packaging maintainer
[^] # Re: mdr!
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
Depusi que le paquet est sur sourceforge il a été modifié tout en gardant le même numéro de version !!!
Il y a donc dans la nature des plusieurs versions 0.96 tout a fait vulnérable et ce d'autant plus que la dernière version l'est toujours !!!
Pour prouver mes dires voici un extrait du patch ( http://christophe.merlet.free.fr/GNU-Linux/mdr/pureftpd-0.96-mdr.pa(...) ) entre la version du 16 mars à 07h12 et celle du 16 mars 19h15 (au décalage horaire prés) :
diff -uNr pureftpd-0.96a/pure-ftpd-0.96/README pureftpd-0.96b/pure-ftpd-0.96/README
--- pureftpd-0.96a/pure-ftpd-0.96/README Thu Mar 15 19:56:19 2001
+++ pureftpd-0.96b/pure-ftpd-0.96/README Fri Mar 16 09:41:56 2001
@@ -9,9 +9,10 @@
Pure-FTPd is a fast, production-quality, standard-conformant FTP server,
based upon Troll-FTPd.
-Unlike other popular FTP servers, it has no known security flaw, it is
-really trivial to set up and it is especially designed for modern Linux
-kernels (setfsuid, sendfile, capabilities) .
+Unlike other popular FTP servers, it's designed to be secure in default
+configuration, has no known buffer overflow, it is really trivial to set up
+and it is especially designed for modern Linux kernels (setfsuid, sendfile,
+capabilities) .
Features include PAM support, IPv6, chroot()ed home directories, virtual
domains, built-in 'ls', anti-warez system, bounded ports for passive
Le fichier le plus critique (src/ls.c) est bien sur modifié au passage.
Pour quelqu'un qui ce dit être expert en sécurité je trouve le comportement injustifiable !
1) Il annonce publiquement sur divers forums publiques toute la méthodologie pour faire planter les serveurs FTP des concurrants en annoncant que le sien est nickel sans laisser le temps aux concurrents de produire un patch.
2) Il joue l'outragé lorsque en réponse de son comportement immature les équipes concurrentes annonce publiquement les failles de son logiciel.
3) Constatant que sa version de pure-ftpd qu'il croyait être exempte de bogue l'est finalement tout autant que les autres il tente de maquiller ce fait en releasant des versions différentes ayant le même numéro de version !!!
Je croyais Frank DENIS être une personne fort respectable et compétente. Or suite à la comédie qu'il joue depuis son annonce il vient de chuter définitivement dans mon estime.
[^] # Re: mdr!
Posté par j . Évalué à 1.
Ca n'a pas été "maquillé". Un message a été posté dans le forum à ce sujet. J'ai ajouté par la suite une news sur la page à ce propos.
# Patch pour ProFTPd
Posté par j . Évalué à 1.
http://bugs.proftpd.org/showattachment.cgi?attach_id=1057(...)
# Corrigé dans le CVS de Proftpd
Posté par j . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.