Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Responsable .NET

    Une mise à jour disponible pour colmater la vulnérabilité critique dans le serveur Web Apache
    Apache HTTP Server 2.2.20 disponible
    La mise à jour corrige une faille permettant des attaques par déni de service

    Mise à jour du 31/08/11

    Apache HTTP Server 2.2.20 est disponible. Cette version corrige la faille de sécurité critique dans le daemon du serveur Web dévoilée la semaine dernière (lire ci-avant). Cette vulnérabilité était massivement exploitée par des pirates avec l’utilitaire « Apache Killer » pour effectuer des attaques par déni de service (DoS).

    La faille de sécurité se situait dans la façon dont le serveur Apache traite les requêtes HTTP volumineuses qui se chevauchent. Le traitement de ces requêtes pouvait provoquer une utilisation excessive de mémoire pouvant entraîner le dysfonctionnement du serveur.

    Les correctifs de la version 2.2.20 d’Apache HTTP Server permettent donc de réduire la quantité de mémoire qui est utilisée par des requêtes range. Le serveur somme désormais le nombre d’octets de l’ensemble des requêtes range qui se chevauchent, et les compare avec la taille du fichier demandé. Si cette somme dépasse la taille du fichier, le fichier est retourné en entier sans que ces requêtes ne soient traitées.

    Les modules écrits pour Apache 2.0 devront être recompilés sans (ou avec très peu de) modifications du code pour fonctionner avec cette version du serveur Web.

    Les développeurs de la plateforme recommandent aux administrateurs de procéder dans les plus brefs délais à une mise à jour de leur serveur Apache.

    Télécharger Apache HTTP Server 2.2.20

    Source : Apache

    Vulnérabilité critique dans le serveur Web Apache
    Un outil exploite la faille qui permet des attaques par déni de service

    Les versions 1.3 et 2.x du serveur Web open source Apache est sujet à une faille de sécurité pouvant être exploitée par des pirates pour des attaques par déni de service (DoS).

    L’annonce a été faite par les développeurs de la plateforme qui travaillent activement pour apporter un correctif le plus tôt possible.

    La faille de sécurité se situe au niveau de la façon dont le serveur Apache traite les requêtes HTTP volumineuses qui se chevauchent, pouvant conduire à une utilisation complète de la mémoire de l’appareil.

    Cette faille peut être exploitée par un pirate distant en empilant de multiples en-têtes HTTP Range pour demander au serveur de lui renvoyer un très grand nombre de morceaux de fichiers de tailles différentes. Le traitement de ces requêtes provoque donc une fuite de mémoire qui peut entraîner le dysfonctionnement du serveur.

    Cette vulnérabilité ne serait pas nouvelle. Elle aurait été découverte pour la première fois il y a de cela quatre ans (en 2007) par Michal Zalewski, un chercheur en sécurité qui travaille actuellement pour Google.

    Mais un outil baptisé « Apache Killer » qui exploite cette vulnérabilité serait en ce moment de circulation et serait très utilisé par des pirates de plus en plus nombreux, selon l’avis même des développeurs du serveur Web.

    Dans le document qu'ils ont publié, des solutions sont également proposées pour permettre aux administrateurs de protéger leur système.

    Les correctifs pour Apache 2.0 et 2.2 devraient être disponibles d'ici 48 heures.

    Et vous ?

    Que pensez-vous de cette faille, et du fait qu'elle n'ait pas été corrigée depuis 4 ans ?
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre émérite
    Plutôt bizarre que personne n'aie soumis de patch relatif à une faille si importante de 4 ans...

    Et tout aussi bizarre qu'ils ne se réveillent que maintenant, et annoncent un patch dans les 48H...

    Quelqu'un à des infos supplémentaires? Parce que bon, s'ils sont capables de la corriger en 48H, comment ça se fait qu'ils ne l'aient pas fait avant? C'est juste à cause du fait qu'un outil pour l'exploiter se répande?

  3. #3
    Expert éminent
    pour moi c'est une erreur monumental de n'avoir pas corriger cette faille étant donné le nombre de serveurs tournant sous apache je pense même qu'il aurait du faire leur communiqué après avoir patché cette faille histoire de limiter les dégâts car en 48 heures qui sait de quoi sont capables les pirates?
    "L'humanité se divise en trois catégories : ceux qui ne peuvent pas bouger, ceux qui peuvent bouger, et ceux qui bougent."
    - Benjamin Franklin

    De l'aide en Javascript , consultez la FAQ JS.

    De l'aide sur le FrameWork JS DHTMLX : posez vos questions sur le forum des Bibliothèques & Frameworks JS.

  4. #4
    Membre éprouvé
    Plutôt bizarre que personne n'aie soumis de patch relatif à une faille si importante de 4 ans...

    Et tout aussi bizarre qu'ils ne se réveillent que maintenant, et annoncent un patch dans les 48H...
    S'ils n'ont pas connaissance du problème, ils ne le corrigent pas.

    Si ça fait 4 ans que tu as des termites dans le toit de ta maison, ça ne fait pas forcement 4 ans que tu le sais
    Si vous moinsez, merci de répondre pour argumenter!
    Ma présentation

  5. #5
    Membre émérite
    Citation Envoyé par kdmbella
    pour moi c'est une erreur monumental de n'avoir pas corriger cette faille étant donné le nombre de serveurs tournant sous apache je pense même qu'il aurait du faire leur communiqué après avoir patché cette faille histoire de limiter les dégâts car en 48 heures qui sait de quoi sont capables les pirates?
    C'est justement la raison de la publication.
    Un outil circule déjà, et justement, son utilisation semble de plus en plus importante.
    Publier cette information et la façon de combattre cette faille en attendant le patch est donc justement pour freiner les problèmes. Les administrateurs sérieux de sites web ont déjà probablement utilisé une des solutions temporaires préconisées, en vue de se protéger.

    Citation Envoyé par YannPeniguel Voir le message
    S'ils n'ont pas connaissance du problème, ils ne le corrigent pas.

    Si ça fait 4 ans que tu as des termites dans le toit de ta maison, ça ne fait pas forcement 4 ans que tu le sais
    Si on ne la connaissais pas il y a 4 ans, alors on ne saurait pas qu'elle a été découverte il y a 4 ans...

  6. #6
    Nouveau membre du Club
    Bonjour,

    c'est effectivement une info que j'ai vu sur d'autres sites.

    Il y a une page avec quelques recommandations ( ICI ) pour limiter un peu la casse en attendant une correction.

    Comme vous pouvez le voir, il s'agit d'ajouter des lignes dans le .htaccess, comme RequestHeader unset Range env=bad-range ou des RewriteRule etc ....

    Ma question est simple : étant sur un serveur mutualisé et ayant déjà pas mal personnalisé mon htacess (pour faire du URL rewriting, des mises en cache etc..), est-ce à moi de le mettre à jour pour protéger mon site d'éventuels DOS ou est-ce à mon hébergeur ?

    Car logiquement, une attaque DOS fout en l'air le serveur en entier, donc pas seulement mon site mais également les autres hébergements mutualisés .... pourtant c'est un réglage de .htaccess ?

    Merci d'eclairer ma lanterne

  7. #7
    Membre éprouvé
    Citation Envoyé par Freem Voir le message

    Si on ne la connaissais pas il y a 4 ans, alors on ne saurait pas qu'elle a été découverte il y a 4 ans...
    J'avais mal lu la news, en effet. Donc les devs ont effectivement merdé en ayant attendu qu'un exploit circule.
    Si vous moinsez, merci de répondre pour argumenter!
    Ma présentation

  8. #8
    Responsable .NET

    Apache HTTP Server 2.2.20 disponible
    Apache HTTP Server 2.2.20 disponible
    La mise à jour corrige une faille permettant des attaques par déni de service

    Mise à jour du 31/08/11

    Apache HTTP Server 2.2.20 est disponible. Cette version corrige la faille de sécurité critique dans le daemon du serveur Web dévoilée la semaine dernière (lire ci-avant). Cette vulnérabilité était massivement exploitée par des pirates avec l’utilitaire « Apache Killer » pour effectuer des attaques par déni de service (DoS).

    La faille de sécurité se situait dans la façon dont le serveur Apache traite les requêtes HTTP volumineuses qui se chevauchent. Le traitement de ces requêtes pouvait provoquer une utilisation excessive de mémoire pouvant entraîner le dysfonctionnement du serveur.

    Les correctifs de la version 2.2.20 d’Apache HTTP Server permettent donc de réduire la quantité de mémoire qui est utilisée par des requêtes range. Le serveur ajoute désormais le nombre d’octets de l’ensemble des requêtes range qui se chevauchent, et les compare avec la taille du fichier demandé. Si cette somme dépasse la taille du fichier, le fichier est retourné en entier sans que ces requêtes ne soient traitées.

    Les modules écrits pour Apache 2.0 devront être recompilés sans (ou avec très peu de) modifications du code pour fonctionner avec cette version du serveur Web.

    Les développeurs de la plateforme recommandent aux administrateurs de procéder dans les plus brefs délais à une mise à jour de leur serveur Apache.

    Télécharger Apache HTTP Server 2.2.20

    Source : Apache
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  9. #9
    Expert éminent
    ba c'est pas trop tôt !
    "L'humanité se divise en trois catégories : ceux qui ne peuvent pas bouger, ceux qui peuvent bouger, et ceux qui bougent."
    - Benjamin Franklin

    De l'aide en Javascript , consultez la FAQ JS.

    De l'aide sur le FrameWork JS DHTMLX : posez vos questions sur le forum des Bibliothèques & Frameworks JS.

###raw>template_hook.ano_emploi###