Dans un même temps, la société ISS subit un retour de flamme du à sa "mauvaise conduite" lorsqu'elle a commencé le thread sur les problèmes de sécurité d'Apache.
En effet, la procédure (non-formelle) de rapport de bug prévoit que le fabricant d'un logiciel (ou le "groupe" qui développe un logiciel libre) soit mis au courant avant la publication...
ISS n'avait pas jugé nécessaire de le faire mais avait en plus proposé un patch qui ne résolvait pas complètement le problème !
Une nouvelle version pour apache 2.0 devrait apparaitre dans peu de temps...
Aller plus loin
- la description du problème (3 clics)
- le Washington Post a propos de ISS (4 clics)
- downloader la nouvelle version (2 clics)
# Apache 2.0
Posté par Anonyme . Évalué à 10.
[^] # Re: Apache 2.0
Posté par Dalton joe . Évalué à 10.
[^] # Re: Apache 2.0
Posté par Anonyme . Évalué à 10.
Pour rappel, il n'y a pas de réelle vulnérabilité sur les archi 32bits (sauf Windows, où Apache n'est pas très répandu). Dans ce cas là, le seul risque encouru est que le processus fils qui gère la requête fautive meurt dans d'atroces souffrances.
A part dans le modèle multi-process/multi-threads d'Apache 2.0, qui, si je ne m'abuse, n'est pas celui par défaut, ça ne fait pas un DoS étant donné que le process qui meurt était occupé et que le process père est toujours là pour relancer un nouveau fils pour remplacer le défunt.
Par contre, sur les plate-formes 64 bits, il y a un plus grand risque. Par ailleurs, et toujours si je ne m'abuse, Solaris n'est réellement 64 bits que depuis la version 7. La question est : est-ce que Solaris 2.6 est quand même vulnérable ?
Pour les autres archis 64 bits, je n'en sais pas plus, mais il me semble que c'est surtout Solaris qui est utilisé à ces fins.
Qui plus est, l'alerte faisait état de cette potentielle exécution de code sur des archis 64 bits en indiquant que ça dépendait du type d'archi sans préciser de laquelle (desquelles ?) il s'agissait.
Bref, il vaut mieux mettre à jour, mais je ne pense pas que le parc complet sera mis à jour tout de suite.
[^] # Re: Apache 2.0
Posté par Gruik Man . Évalué à 8.
Enfin, dans tous les cas, qu'on "pense" que ça soit exploitable, ou non, c'est un bug, donc update, et pis c'est tout.
[^] # Re: Apache 2.0
Posté par Victor Vuillard . Évalué à 10.
sorry
[^] # Re: Apache 2.0
Posté par woof . Évalué à -2.
# Guégerre ISS Apache
Posté par Gaétan RYCKEBOER . Évalué à 10.
Puis : "Si nous n'avons pas pu prévenir Apache, c'est parce que ce n'est pas une société officielle, mais un structure de dévelopeurs disparates".
Et enfin "Nous ne faisons pas confiance à Cox, juge et partie, dans la mesure où il travaille poru RedHat, qui nous a piqué des informations il y a quelques temps". Citation et traduction libres. Reportez vous à l'article pour avoir la VO ;-)
1/ tentative de discréditer le LL
2/ géguerre avec RedHat, qu'ils "accusent" d'avoir piqué des infos, ou plla notoriété qui découle de certaines recherches de ISS. Hum....
Enfin, une note sur le Washington Post, qui ne parle que du gouvernement Bush qui tente actuellement de travailelr sur la sécurité, ie. Internet et Apache impactent directement les US, c'est donc aux US d'agir.
Voila pour mes 2ct à chaud...
[^] # Re: Guégerre ISS Apache
Posté par Anonyme . Évalué à -3.
Voilà mes 2cts à chaud...
[^] # Re: Guégerre ISS Apache
Posté par Graveen . Évalué à 10.
Et puis fait qu'ils aient prévenu le FBI, me fait l'effet d'une socièté qui cherche a se placer auprés du gouvernement...
Belle mentalité.... :(
[^] # Re: Guégerre ISS Apache
Posté par Baptiste SIMON (site web personnel) . Évalué à 10.
Surtout quand on voit qu'ils crachent sur le Libre (ici Apache)... qui leur donne du taf (payant celui-ci bien sûr) !!
Quelqu'un sait si ces co^Mderniers participent aux LLs ? parce que sinon, c'est vraiment l'hôpital qui se moque de la charité !
--
La vraie Liberté c'est d'avoir le choix
[^] # Re: Guégerre ISS Apache
Posté par Mathieu Dessus (site web personnel) . Évalué à 10.
[^] # Re: Guégerre ISS Apache
Posté par pthivent . Évalué à 10.
Je ne discuterai pas ici de la qualité ou du contenu des articles de ce journal électronique et me contenterai de rappeler que de nombreux décideurs reçoivent (et lisent) leur newsletter.
Voici en gros la partie la plus importante :
Manque de coordination
L'alerte est inquiétante en soi. Mais plus inquiétante encore est peut-être l'attitude de la communauté open source suite à cette alerte. Un article particulièrement argumenté de Cnet met en effet en évidence le manque de coordination patent entre les tenants du logiciel libre. ISS a lancé son alerte sans se soucier du travail qu'acomplissait discrètement de son côté la fondation Apache - qui est à l'origine de la création du serveur éponyme. Les responsables de cette organisation ont fait savoir après coup qu'ils travaillaient depuis quelques temps déjà sur cette faille, qui leur a été révélée par un développeur beaucoup plus discret, et qu'ils tentaient avant tout d'en cerner l'étendue.
L'ISS a lancé son alerte et son patch deux heures après avoir prévenu la fondation Apache. Un manque de coordination, qui a aujourd'hui pour conséquence de mettre à mal l'efficacité du correctif, et surtout la justesse de l'information qui l'accompagne. Car comme le souligne un membre fondateur de la fondation Apache, les recherches menées par les créateurs du serveur n'avaient pas encore pris fin. On ne sait toujours pas précisément quelles versions du serveur sont affectées, plate-forme par plate-forme.
L'ISS, qui cherchait selon ses propres déclarations à soustraire au plus vite la brêche des yeux des hackers a donc fait pire que mieux : tous les pirates sont désormais informés qu'une faille existe, quant aux adminstrateurs : "avec le lancement prématuré de l'ISS, beaucoup de serveurs Apache demeurent vulnérables puisqu'ils n'ont pas accès au patch provenant de leur fournisseur Apache" - pouvait on lire sur la liste de diffusion Bugtraq.
Conclusions ?
La première c'est que je trouve cela ennuyeux que des petits problèmes d'interêts personnels puisse menacer ainsi le modèle même de développement Open Source. C'est un problème en soi que la réactivité de la communauté soit conditionnée par de stupides problèmes de concurrence (entre l'ISS et les boîtes auxquelles les membres de la fondation Apache par exemple).
La deuxième c'est que je suis certain que la mauvaise gestion d'une telle annonce va être récupéré de partout pour alimenter les pires FUD envers l'Open Source. Les arguments sur la qualité, réactivité,... des développements du monde du libre et surtout ceux sur la piètre qualité de certaines solutions propriétaires ne serviront plus à rien si demain il fallait mettre à jour 63% des serveurs web de la planète. La communauté va devoir être très attentive dans l'avenir si elle ne veut pas offrir à ses détracteurs la brèche dans laquelle s'engouffrer.
[^] # Re: Guégerre ISS Apache
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
[^] # Re: Guégerre ISS Apache
Posté par CopainJack (site web personnel, Mastodon) . Évalué à 6.
dans l'article que tu cites, il y a également cette petite phrase qui commence la conclusion
Tout n'est pas si rose sur la planète Open Source, et certains se prennent parfois à rêver d'une coordination contre les failles aussi efficace que celle de ... Microsoft.
[^] # Re: Guégerre ISS Apache
Posté par RB . Évalué à -1.
En espérant que les administrateurs ne soient pas aussi naïfs que le grand public, la majorité de ceux qui utilisent apache savant pourquoi.
Quand on voit M$ et ses 15 worms qui proliférent... Apache n'a pas connu une seule faille sécurité en plusieures années qui oblige à faire une mise à jour rapide et celle-ci est très loin de l'être....
JDN, c'est pas un site ou il faut aller, mais un petit (ou quelques centaines) mail argumenté à ces pourris ne leurs feraient pas de mal.
# a propos d'apache 2
Posté par daniel . Évalué à 10.
Si j'ai bien compris il est stable, mais les différentes distributions attendent que tous les modules cgi courant soit portés, que l'intégration avec les différents serveurs de servlets et jsp soient.
php est déja prêt, mod_python a une version alpha, quelqu'un sait ou en sont l'intégration avec perl, tomcat4 et cocoon ?
[^] # Re: a propos d'apache 2
Posté par Dalton joe . Évalué à 10.
[^] # Re: a propos d'apache 2
Posté par Anonyme . Évalué à 10.
Par ailleurs, pour la 1.3.26, il faut a priori attendre une nouvelle version de mod_ssl (d'ailleurs, il n'y en a plus besoin dans apache 2.0 puisqu'il est intégré de base), et le serveur http://www.modssl.org(...) n'a pas l'air très en vie en ce moment...
[^] # Re: a propos d'apache 2
Posté par Anonyme . Évalué à 8.
http://www.modssl.org/source/mod_ssl-2.8.9-1.3.26.tar.gz(...)
[^] # Re: a propos d'apache 2
Posté par Francois SIMOND . Évalué à 3.
dans le README, le todo contient une ligne qui dit a peu près:
"ne plus passer par un fichier temporaire"
hemhem :P
laissons leur le temps:)
comme alternative efficace il y a toujours le fastcgi pour php. c'est rapide et ça tient bien la charge, vu que les process php sont en mémoire et y restent. ( le module fastcgi pour apache2 est aussi en cours de développement )
[^] # Re: a propos d'apache 2
Posté par Moby-Dik . Évalué à 3.
J'ai essayé au boulot PHP 4.2.1 avec Apache 2.0.39, ça ne compile même pas. La partie qui fait rustine entre php et apxs2 est en cause.
Pour la lenteur, un thread sur la liste de développement d'Apache explique que c'est dû à une mauvaise compréhension de l'API d'Apache 2 par les développeurs PHP. En gros, au lieu d'envoyer les données d'un seul coup (au moins pour les morceaux de HTML statique), ils se retrouvent à les découper en petits bouts de 400 octets, et Apache 2 reproduit ce découpage derrière, d'où performances pourries.
[^] # Re: a propos d'apache 2
Posté par Raphaël SurcouF . Évalué à -10.
hop, -1 ! ;-)
[^] # Re: a propos d'apache 2
Posté par daniel . Évalué à -2.
# Faut pas faire chier Bébert quand il répare sa pétrolette
Posté par Korbinus (site web personnel) . Évalué à 0.
# Il FAUT mettre à jour !
Posté par Anonyme . Évalué à 7.
Contrairement à ce qui est indiqué dans les alertes, la faille est exploitable sur à peu près toutes les archis (en tout cas; au moins Solaris, OpenBSD, FreeBSD et Linux).
L'exploit permet d'obtenir un remote shell
http://online.securityfocus.com/attachment/2002-06-20/apache-scalp.(...)
PS: Dommage pour OpenBSD, ils vont devoir changer leur slogan...
[^] # Re: Il FAUT mettre à jour !
Posté par falbala . Évalué à 2.
Pourquoi ?
[^] # Re: Il FAUT mettre à jour !
Posté par Anonyme . Évalué à 4.
Apache fait partie de l'install par défaut...
D'ailleurs, http://www.openbsd.org(...) n'est toujours pas à jour...
[^] # Re: Il FAUT mettre à jour !
Posté par falbala . Évalué à 0.
[^] # Re: Il FAUT mettre à jour !
Posté par Anonyme . Évalué à 1.
[^] # Re: Il FAUT mettre à jour !
Posté par falbala . Évalué à 0.
[^] # Re: Il FAUT mettre à jour !
Posté par Anonyme . Évalué à 0.
[^] # Re: Il FAUT mettre à jour !
Posté par Stéphane Salès . Évalué à 1.
qqun pour confirmer ?
[^] # Re: Il FAUT mettre à jour !
Posté par Anonyme . Évalué à 3.
[^] # Re: Il FAUT mettre à jour !
Posté par Pipo2 . Évalué à 1.
[^] # Re: Il FAUT mettre à jour !
Posté par Anonyme . Évalué à 1.
[^] # Re: Il FAUT mettre à jour !
Posté par earxtacy . Évalué à 1.
[^] # Re: Il FAUT mettre à jour !
Posté par Anonyme . É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.