Vous venez de mettre à jour vos OpenSSH-portable ?
 
Recommencez si vous êtes sous Linux, FreeBSD ou Solaris, des failles de sécurité ont été découvertes dans l'interface avec PAM. Passez en OpenSSH 3.7.1p2.
 
Vous utilisez encore Proftpd ? Un nouveau root exploit vient d'être découvert. Accessible à toute personne en mesure d'uploader un fichier sur un serveur Proftpd.
 
Youpi, c'est la fête.

et pure-ftpd, ça va bien, pas de faille ?

je commence a avoir l'impression qu'on bouche une passoire et qu'on a pas assez de doigt pour ca .......
 
 
 
 
 

 
Bein non... toujours rien à signaler à ma connaissance... zZzZzZ.
 

 
Barf en ce moment des failles sont trouvées un peu partout et sur tous les OS.
 
Tant mieux, les admin sys au chomage vont peut-être retrouver du boulot

 
axey, comment as tu été prévenu de l'exploit root de proftpd?

 
La différence c'est que le libre ne cherche pas à les dissimuler, les corrige en 24 heures, et quand on met à jour, l'éditeur ne nous fait pas signer un nouvel EULA avec son sang lui autorisant à avoir un accès en root sur nos machines

 
ISS vient de publier qu'une faille avait été découverte dans les transferts ASCII de proftpd.
 
Tous les sources sur le site FTP de proftpd ont disparus (pratique pour les Gentoo et BSD qui recompilent à partir des sources). A la place, il y a des versions patchées à l'arrache. Il reste meme les fichiers .orig dans les .tar.gz
 
Le correctif appliqué est très bizarre. La fonction qui traite les conversions ASCII a beaucoup changée, peut-être pour que le bogue soit plus dur à trouver ?
 
Car à première vue le seul "problème" concerne la taille d'un buffer (session.xfer.buf) auquel il faudrait ajouter deux octets.
C'est dans src/data.c, le pcalloc() de la ligne 160 :
 
    session.xfer.buf = pcalloc(session.xfer.p, session.xfer.bufsize);
 
Il manque un "+2" après bufsize.
 
Ajouter deux caractères aurait suffit à faire un tel correctif, pas besoin de réecrire la fonction.
 
La faille a vraiment l'air exploitable. Les pcalloc() sont libérés juste après (via destroy_pool()) et on doit pouvoir changer la taille des blocs. Je suis en tout cas arrivé très facilement à modifier free_blk->h.next.
 
Ca peut être un peu plus dur à exploiter sur les BSD que sur les Linux à cause de PKMalloc. Par contre quelque soit l'OS c'est trivial de ce servir de cette faille pour provoquer un déni de service. Downloadez un fichier de 1044 octets en ASCII => la charge du CPU reste à 100% et le seul moyen d'en sortir est un killall -9 proftpd.
 

 
C'est clair :
 
http://www.pivx.com/larholm/unpatched/

 
C'est effectivement le cas avec le SP1 de WinXP (que je n'utilise plus) lorsqu'on s'attarde précisément sur le CLUF.
 
Belle prose de Zeb_ qui nous renvoie à la beauté du diable.

J'ai beau essayer d'être informaticien, lire un truc come ça dès le matin ... j'arrives pas !