Serveur HTTP Apache 2.4.67 correctif critique contre une vulnérabilité HTTP / 2 sévère qui pourrait provoquer un déni de service et une exécution de code distant

La Fondation Apache a publié des correctifs critiques pour le serveur HTTP après avoir trouvé une vulnérabilité grave à la gestion HTTP / 2 qui peut entraîner un déni de service et, sous certaines conditions, une exécution de code à distance. La version corrigée est Apache HTTP Server 2.4.67 et la recommandation immédiate à l'intention des gestionnaires est de mettre à jour dès que possible les organismes concernés qui appliquent encore le paragraphe 2.4.66 ou plus tôt.

Le problème est placé dans la logique de nettoyage du flux mod _ http2 et est un cas classique de double libération de mémoire qui peut être tourné par une séquence de lignes HTTP / 2 envoyées par un client. En pratique, cela signifie qu'un attaquant à distance peut faire bloquer un travailleur avec quelques paquets bien formés; Le déni de service est banal à jouer dans les déploiements par défaut. Le chemin vers l'exécution de code à distance (CER) nécessite des conditions supplémentaires - une attribution de mémoire mmap dans APR et une chaîne d'étapes pour réutiliser la direction publiée - mais les chercheurs ont montré qu'elle est viable en laboratoire sous des paramètres Debian communs et dans l'image officielle httpd Docker.

Que l'exploitation des URCE dépend du mmap et des éléments tels que le « tableau de bord » du serveur rend certaines plateformes plus attrayantes : dans Debian et dans l'image officielle de Docker, le comportement par défaut facilite le flux de l'explosion. Les configurations multifils avec mod _ http2 activés sont les plus exposées; le MPM préfork ne subit pas cette défaillance Ainsi, le passage temporaire à la préfourche peut être une atténuation partielle dans les environnements où il n'est pas possible de stationner immédiatement.

En plus du patch, les mesures d'atténuation immédiates qui doivent être envisagées sont : mise à jour à 2.4.67 sur tous les serveurs exposés, désactiver mod _ http2 si ce n'est pas strictement nécessaire, et vérifier si l'APR utilise le mmap (une recombinaison de APR sans mmap réduit la fenêtre de fonctionnement). Pour les environnements conteneur, assurez-vous de reconstruire et de déployer des images basées sur la version corrigée du serveur et assurez-vous que les images de production ne continuent pas à utiliser la version vulnérable.

Les opérateurs et l'équipement de sécurité devraient surveiller des indicateurs d'abus clairs: les profils de connexion qui provoquent le redémarrage répété des travailleurs, les braindumps ou les entrées inhabituelles dans les enregistrements d'erreurs httpd. Implémenter des limites de débit au niveau du rocker ou du pare-feu, ou forcer la terminaison HTTP / 2 dans un proxy / terminateur TLS patché, peut contenir des attaques ciblées pendant que la mise à jour complète du parc est appliquée.

La vulnérabilité a été signalée par des chercheurs indépendants et leur cote du CVSS (8,8 selon le rapport) souligne son impact. Bien que la route menant aux URCE exige des conditions techniques supplémentaires et un certain degré de «spray» et de fuite d'informations, les attaques de déni de service sont simples et suffisantes pour justifier la priorité dans le stationnement. Pour plus de détails techniques et la liste officielle des corrections, consultez la page de sécurité du serveur HTTP Apache et la documentation mod _ http2. https: / / httpd.apache.org / sécurité / vulnérabilités _ 24.html et https: / / httpd.apache.org / docs / 2.4 / mod / mod _ http2.html.

En bref : appliquer la version 2.4.67 dès que possible, prioriser les serveurs et conteneurs publics basés sur Debian ou l'image officielle de httpd, envisager une atténuation temporaire telle que désactiver le mod _ http2 ou passer à la préforche si vous ne pouvez pas vous garer immédiatement, et augmenter la surveillance de la stabilité anormale et des événements de trafic sur votre front HTTP / 2.