Les défaillances critiques de F5 NGINX nécessitent un correctif immédiat pour éviter l'exécution de DoS et de code à distance

F5 a publié des mises à jour de sécurité hors cycle pour corriger plusieurs vulnérabilités sur les serveurs Web NGINX, dont deux gravité critique qui permettent aux attaquants distants non authentifiés de provoquer des dénis de service et, dans des conditions spécifiques, d'exécuter un code arbitraire. Ces défaillances exploitent les erreurs de mémoire classiques - l'utilisation-après-libre et les débordements dans la pile - qui font recommencer le processus de travail et, si le système a ASLR désactivé ou l'attaquant parvient à le dessiner, peut entraîner une exécution de code à distance.

Les corrections couvrent à la fois NGINX Open Source et NGINX Plus en tant que composants du portefeuille F5, y compris NGINX Gateway Fabric et NGINX Instance Manager. Grâce à la mise en œuvre intensive de ces technologies dans les entreprises et les fournisseurs de services, toute défaillance grave de NGINX entraîne un risque d'impact élevé pour les infrastructures servant des applications publiques et privées, d'autant plus que F5 a été une cible répétée de campagnes criminelles et d'État ces dernières années.

Si vous ne pouvez pas appliquer immédiatement les correctifs, F5 a souligné l'atténuation des points: désactiver HTTP / 3 (enlevant "quic" des directives écoute) pour l'une des vulnérabilités, et pour l'autre pour revoir et ajuster les directives en-tête (supprimer ignorer les en-têtes _ invalides désactivés et de réduire grand _ client _ en-tête _ tampons moins de 2 Mo). Ces mesures aident, mais ne représentent pas une solution définitive : désactiver HTTP / 3 réduit la surface d'attaque mais affecte également les performances et les caractéristiques des cellules HTTP / 3.

Face à ces avertissements, une réponse coordonnée devrait être adoptée : prioriser la correction immédiate d'instances exposées à Internet et de services critiques; déployer d'abord dans des environnements d'essai pour valider la compatibilité; et appliquer une atténuation du temps si la mise à jour n'est pas possible immédiatement. En outre, il active des contrôles compensatoires tels que des règles spécifiques WAF, la segmentation du réseau pour isoler les composants administratifs et des enregistrements élargis pour détecter des redémarrages ou des accidents inhabituels du processus nginx.

Il est également recommandé de vérifier l'état de l'ASLR et d'autres protections de la mémoire sur les serveurs touchés, d'examiner les dossiers d'audit et les alertes EDR/IDS pour les signes d'exploitation (correspondants, processus infantiles inattendus, échecs répétés des travailleurs) et d'effectuer des analyses d'intégrité en binaire et en configuration. Compte tenu du précédent des fuites de vulnérabilité et du code F5, les acteurs malveillants sont plus incités à se développer rapidement après la divulgation.

Pour obtenir des renseignements officiels sur les corrections et les CVE connexes, consultez les notes du fournisseur et le guide public sur les vulnérabilités actives : F5 page d'appui et le catalogue des vulnérabilités activement exploitées de la CISA aux États-Unis. Les États-Unis, qui tiennent un registre utile pour prioriser les mesures correctives : CISA - vulnérabilités connues exploitées (F5). Pour comprendre l'impact de la désactivation HTTP / 3 sur vos services, vous pouvez voir la documentation technique NGINX sur HTTP / 3: NGINX - HTTP / 3.

En bref, considérez cet avis comme une priorité : appliquer les correctifs du fournisseur dès que possible, utiliser l'atténuation documentée uniquement comme solution temporaire, accroître la visibilité et la surveillance des instances concernées, et revoir sa stratégie de réponse aux incidents et de gestion des correctifs afin de réduire les fenêtres d'exposition contre les acteurs qui ont historiquement exploité les vulnérabilités des produits F5.