009: SECURITY FIX: March 3, 2003
A buffer overflow in the envelope comments processing in sendmail(8) may allow an attacker to gain root privileges.
A source code patch exists which remedies the problem.
Bon je veux bien que Sendmail soit pas aussi bouseux qu'on le dise et qu'ils aient fait des progres (de la correction de bugs par decouvertes exhaustive :) a ce niveau ces dernieres annees, mais de la a en faire l'apologie faut pas abuser :)
Oh, et au niveau des performances Postfix supporte tres bien les domaines multiples et tourne chez moi depuis plus de trois ans et demi sans -le moindre- probleme (vraiment pas un seul, jamais).
maintenant que la question est clarifiee, on peut continuer le debat sur pourquoi phpnuke est code avec les pieds :)
J'ai un peu peur, tu n'as pas compilé avec -lc_r comme option j'éspère ? Bien "-pthread" comme cela doit être fait (voir FAQs, mans et livres de sorcellerie).
>> vi, vi -pthread et -lc_r ;)
Les threads natifs comme tu les appellent sont ceux accessible à travers cette interface que sont les pthreads, donc j'ai du mal à suivre ton histoire de pthread /= threads natifs.
> j'ai repris le terme employé je ne sais plus
> ou, quand je dis thread natifs, je ne parles
> plus des gnu pth.
Si tu me parles de GNU pth là je comprends un peu mieux.
> heh
Lier directement un programme avec libc_r (c-à-d sans l'option "-pthread" pour le linker) est très gruik, et surtout risque fortement de déconner grave ... (cf. archives des ml open)
J'avoue que je ne vois pas comment compiler avec "-pthread" peut changer quelque chose sur des services qui n'utilisent pas les pthreads au départ. Je parle uniquement de ce qui fait partie de la base (sendmail, ftpd (donc inetd) et ssh dans les noms que tu as cités).
> j'ai pas ete voir les sources, je pense pas
> avoir le niveau (d'ailleurs non seulement je
> pense pas, mais en plus je suis SUR de ne pas
> l'avoir) pour aller voir pourquoi tel service
> merde quand il est compilé de telle ou telle
> facon. Marrant que tu parles d'inetd, j'ai pas
> essayé du tout inetd, tout tournait en
> standalone (du moins chez moi).
Bon, voyons ce que tu as posté sur misc@open
marc.theaimsgroup.com/?l=openbsd-misc&am
Sinon, après avoir lu ce que tu as posté ...
Tu utilisais un apache compilé à la main, curieux ...
> je suis pas un grand fan des ports ;)
Tu t'es fait éconduire car tu ne fournissait pas de détails ...
> tu doit pas lire le bon, le thread etait assez
> long, j'ai même fournit l'executable qui
> permettait de tester si la machine subissait
> le crash ou non.
>
> j'ai fait pas mal de post sur les mailing d'
> open, cherche encore ;)
Quand tu as recompilé tout pour que ça marche désormais, qu'as-tu recompilé ? Juste la libc_r, ou le noyau aussi ou tout ?
> j'ai d'abord recompilé libc_r, pis apres je me
> suis appercut que cette lib etait utilisée par
> pas mal d'autres libs, alors je me suis dit qu'
> il fallait recompiler toutes les libs, j'ai
> fait un gros make build. Mais comme j'ai lu a
> un moment KERNEL_PTHREAD lors d'une compilation
> j'en ai déduit que le kernel devait influencer
> donc... la totale.
Ça ressemblait plus à une panne hard ou un driver buggé mais bon ...
D'autres gens ont eu un problème, un bon vieux "mb_map full", cf FAQ OpenBSD pour régler ça, et ça ne fait même pas tomber la machine, juste la rendre indisponible une demi-minute).
> nan rien a voir, ca ca se corrige en optimisant
> le kernel ca. Meme en ayant optimisé à fond le
> kernel, on peut toujours crasher Open.
Perso je n'ai le problème sur aucune de mes deux machines (une en -current (x86, carte réseau "vr"), l'autre 2.9-stable (sparc, carte réseau "le")).
- OpenBSD toutes les versions supérieures à la 2.7 qu'elles soient en branche -base, -stable ou -current plantent, plus aucun problème une fois que l'on utilise les threads natifs (libc_r) qui sont actuellement dans la branche -current.
- NetBSD aucun bleme
- FreeBSD aucun bleme
J'ai beau adorer OpenBSD, si un bug est -spécifique- à cet OS, je n'ai rien à gagner en me disant le contraire.
elle méthodologie a été utilisée pour ce que tu avances ? et quels services sont impactés ?
>> methodologie ?
>> J'avais réalisé un executable qui effectuait
>> une simulation d'authentification puis se
>> déconnectait aussitot dans une boucle. Cet
>> executable a ete
>> envoyes à diverses personnes sur l'une des
>> mailing list d'OpenBSD il y a environ deux
>> mois de cela (peut-être un peu plus).
>> Pour les services on a essayé sur ftpd, proftpd
>> sendmail, postfix, cucipop, popa3d (pour ma
>> part) et probablement d'autres (je ne sais
>> pas ce qui faisait tourner les machines des
>> autres)...
as tu des chiffres (protocole de transport physique, vitesse de la connexion, nb de connexions simultanées, tcp ou udp ou icmp ou la combinaison) concrets à nous communiquer ?
>> les tests ont pour la plupart etes fait en
>> reseaux locaux sur des 10mb/s et des 100mb/s,
>> attention il ne s'agissait PAS de connexions
>> simultanées, mais de connexions les unes à la
>> suite des autres.
>> En fait, les chiffres étaient assez variables,
>> mais en envoyant en moyenne, 2 ou 3 milles
>> demandes de connexions par minutes, le serveur
>> plantait en 20/30 secondes (si tu as un doute
>> tu cherches dans les archives DoS, tu va voir
>> un thread avec les personnes qui ont testées
>> le denial).
>> Au niveau du protocole, de
>> mon coté c'etait du tcp, maintenant je sais
>> pas si quelqu'un a pas essayé en udp...
Je pense que n'importe quel OS (ou ASIC) est DoSable dans la mesure où on dispose des ressources suffisantes pour le faire planter.
>> Attention, la je parle bien de DoS sans trop
>> de ressources, ce qui fait peur...
C'est pourquoi des données concrètes nous permetterait de trouver une parade si besoin. Ces données pourraient être soumises à la critique de Theo & the crew sur misc@ ou tech@.
Peut etre est ce le moment de réveler la présence de très nombreux denial of service sur la plateforme OpenBSD due à ce bug de thread. En effet, tout les services ayant étés compilés avec les pthreads sous OpenBSD ne gèrent pas une montée massive de connexions. Ainsi, dès lors qu'un service tourne (à la seule exception de OpenSSH, probablement non compilé avec les pthreads), des demandes de connexions répétitives à grande vitesse suffisent à faire planter la machine. Les tests ont étés effectués sur différentes configurations matérielles sous différentes versions d'OpenBSD (postérieures à la version 2.7) et chez différentes personnes, on en est arrivé à la conclusion qu'un script kiddie équippé d'une machine sous windows pouvait faire freezer un OpenBSD en moins de 17 secondes pourvu que les connexions soient effectuées assez rapidement.
La seule solution valable est la recompilation de tout les services en utilisant les threads natifs en lieu et place des pthreads.
Voila, c'etait le scoop qui parait chez vous avant ailleurs ;)
[^] # Re: PHP-Nuke quitte le monde du libre
Posté par Gilles Chehade . En réponse à la dépêche PHP-Nuke quitte le monde du libre. Évalué à 0.
009: SECURITY FIX: March 3, 2003
A buffer overflow in the envelope comments processing in sendmail(8) may allow an attacker to gain root privileges.
A source code patch exists which remedies the problem.
Bon je veux bien que Sendmail soit pas aussi bouseux qu'on le dise et qu'ils aient fait des progres (de la correction de bugs par decouvertes exhaustive :) a ce niveau ces dernieres annees, mais de la a en faire l'apologie faut pas abuser :)
Oh, et au niveau des performances Postfix supporte tres bien les domaines multiples et tourne chez moi depuis plus de trois ans et demi sans -le moindre- probleme (vraiment pas un seul, jamais).
maintenant que la question est clarifiee, on peut continuer le debat sur pourquoi phpnuke est code avec les pieds :)
[^] # Re: Remote DoS
Posté par Gilles Chehade . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 1.
>> vi, vi -pthread et -lc_r ;)
Les threads natifs comme tu les appellent sont ceux accessible à travers cette interface que sont les pthreads, donc j'ai du mal à suivre ton histoire de pthread /= threads natifs.
> j'ai repris le terme employé je ne sais plus
> ou, quand je dis thread natifs, je ne parles
> plus des gnu pth.
Si tu me parles de GNU pth là je comprends un peu mieux.
> heh
Lier directement un programme avec libc_r (c-à-d sans l'option "-pthread" pour le linker) est très gruik, et surtout risque fortement de déconner grave ... (cf. archives des ml open)
J'avoue que je ne vois pas comment compiler avec "-pthread" peut changer quelque chose sur des services qui n'utilisent pas les pthreads au départ. Je parle uniquement de ce qui fait partie de la base (sendmail, ftpd (donc inetd) et ssh dans les noms que tu as cités).
> j'ai pas ete voir les sources, je pense pas
> avoir le niveau (d'ailleurs non seulement je
> pense pas, mais en plus je suis SUR de ne pas
> l'avoir) pour aller voir pourquoi tel service
> merde quand il est compilé de telle ou telle
> facon. Marrant que tu parles d'inetd, j'ai pas
> essayé du tout inetd, tout tournait en
> standalone (du moins chez moi).
Bon, voyons ce que tu as posté sur misc@open
marc.theaimsgroup.com/?l=openbsd-misc&am
Sinon, après avoir lu ce que tu as posté ...
Tu utilisais un apache compilé à la main, curieux ...
> je suis pas un grand fan des ports ;)
Tu t'es fait éconduire car tu ne fournissait pas de détails ...
> tu doit pas lire le bon, le thread etait assez
> long, j'ai même fournit l'executable qui
> permettait de tester si la machine subissait
> le crash ou non.
>
> j'ai fait pas mal de post sur les mailing d'
> open, cherche encore ;)
Quand tu as recompilé tout pour que ça marche désormais, qu'as-tu recompilé ? Juste la libc_r, ou le noyau aussi ou tout ?
> j'ai d'abord recompilé libc_r, pis apres je me
> suis appercut que cette lib etait utilisée par
> pas mal d'autres libs, alors je me suis dit qu'
> il fallait recompiler toutes les libs, j'ai
> fait un gros make build. Mais comme j'ai lu a
> un moment KERNEL_PTHREAD lors d'une compilation
> j'en ai déduit que le kernel devait influencer
> donc... la totale.
Ça ressemblait plus à une panne hard ou un driver buggé mais bon ...
D'autres gens ont eu un problème, un bon vieux "mb_map full", cf FAQ OpenBSD pour régler ça, et ça ne fait même pas tomber la machine, juste la rendre indisponible une demi-minute).
> nan rien a voir, ca ca se corrige en optimisant
> le kernel ca. Meme en ayant optimisé à fond le
> kernel, on peut toujours crasher Open.
Perso je n'ai le problème sur aucune de mes deux machines (une en -current (x86, carte réseau "vr"), l'autre 2.9-stable (sparc, carte réseau "le")).
> on a été environ une 50aines à tester, 80% des
> personnes qui tournaient sous Open on subit le
> crash, que ce soit sur des i386, des sparcs,
> des alphas.
Tu devrais envoyer un vrai bug report chez open.
> c'est fait depuis un moment déjà, mais c'est
> plus la peine d'en faire un vu que ca a été
> apparemment corrigé dans -current.
[^] # Re: Remote DoS
Posté par Gilles Chehade . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 1.
- OpenBSD toutes les versions supérieures à la 2.7 qu'elles soient en branche -base, -stable ou -current plantent, plus aucun problème une fois que l'on utilise les threads natifs (libc_r) qui sont actuellement dans la branche -current.
- NetBSD aucun bleme
- FreeBSD aucun bleme
J'ai beau adorer OpenBSD, si un bug est -spécifique- à cet OS, je n'ai rien à gagner en me disant le contraire.
[^] # Re: Remote DoS
Posté par Gilles Chehade . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 2.
>> methodologie ?
>> J'avais réalisé un executable qui effectuait
>> une simulation d'authentification puis se
>> déconnectait aussitot dans une boucle. Cet
>> executable a ete
>> envoyes à diverses personnes sur l'une des
>> mailing list d'OpenBSD il y a environ deux
>> mois de cela (peut-être un peu plus).
>> Pour les services on a essayé sur ftpd, proftpd
>> sendmail, postfix, cucipop, popa3d (pour ma
>> part) et probablement d'autres (je ne sais
>> pas ce qui faisait tourner les machines des
>> autres)...
as tu des chiffres (protocole de transport physique, vitesse de la connexion, nb de connexions simultanées, tcp ou udp ou icmp ou la combinaison) concrets à nous communiquer ?
>> les tests ont pour la plupart etes fait en
>> reseaux locaux sur des 10mb/s et des 100mb/s,
>> attention il ne s'agissait PAS de connexions
>> simultanées, mais de connexions les unes à la
>> suite des autres.
>> En fait, les chiffres étaient assez variables,
>> mais en envoyant en moyenne, 2 ou 3 milles
>> demandes de connexions par minutes, le serveur
>> plantait en 20/30 secondes (si tu as un doute
>> tu cherches dans les archives DoS, tu va voir
>> un thread avec les personnes qui ont testées
>> le denial).
>> Au niveau du protocole, de
>> mon coté c'etait du tcp, maintenant je sais
>> pas si quelqu'un a pas essayé en udp...
Je pense que n'importe quel OS (ou ASIC) est DoSable dans la mesure où on dispose des ressources suffisantes pour le faire planter.
>> Attention, la je parle bien de DoS sans trop
>> de ressources, ce qui fait peur...
C'est pourquoi des données concrètes nous permetterait de trouver une parade si besoin. Ces données pourraient être soumises à la critique de Theo & the crew sur misc@ ou tech@.
>> Déjà envoyés là bas depuis deux/trois mois.
Qu'en penses-tu ?
>> C'est une bonne idée ;)
# Remote DoS
Posté par Gilles Chehade . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 8.
La seule solution valable est la recompilation de tout les services en utilisant les threads natifs en lieu et place des pthreads.
Voila, c'etait le scoop qui parait chez vous avant ailleurs ;)