FreeBSD : fuite de socket dans blocklistd provoque surcharge
Les faits
Le 10 février 2026, une vulnérabilité critique a été portée à connaissance concernant blocklistd, le démon FreeBSD chargé de gérer des listes de blocage dynamiques. Une fuite de descripteurs de sockets permet d'ouvrir des connexions non nettoyées et de saturer rapidement les ressources d'un hôte FreeBSD, provoquant un déni de service local ou à distance selon la configuration réseau et les interfaces exposées ². Des analyses publiques et un rapport technique confirment la possibilité de reproduire cette fuite en quelques dizaines de secondes sur des systèmes non protégés ¹ ³.
Concrètement :
- blocklistd ouvre des sockets UDP/TCP pour traiter des mises à jour et ne les ferme pas correctement quand il reçoit un volume important d'entrées malformées ou très fréquentes. ²
- Aucune limitation interne du nombre de descripteurs par instance n'empêche l'accumulation jusqu'à l'épuisement des ressources noyau; les services dépendants retournent alors des erreurs « too many open files ». ² ³
- Une fois la limite atteinte, des dégradations en cascade apparaissent : services réseau qui échouent, redémarrages ou basculements incontrôlés, voire indisponibilité des appliances en production.
Des tests de reproduction montrent que, selon la taille des paquets et la cadence d'envoi, un attaquant peut générer plusieurs centaines de descripteurs en l'espace de quelques dizaines de secondes sur une machine vulnérable ³. Les appliances réseau, pare-feu d'entreprise et infrastructures critiques exécutant FreeBSD sont particulièrement à risque si elles n'ont pas appliqué les mesures compensatoires recommandées ².
Contexte
blocklistd est largement utilisé pour synchroniser des listes de blocage et alimenter des politiques de filtrage en espace utilisateur. On le retrouve aussi bien dans des appliances commerciales que dans des installations sur mesure. Les composants de filtrage en espace utilisateur ont historiquement été une fonte d'erreurs induisant des fuites de ressources quand la charge, la concurrence ou des entrées malformées ne sont pas correctement gérées ³.
Entre 2016 et 2022, plusieurs incidents similaires ont mis en lumière la fragilité de daemons manipulant des règles réseau : fuites de descripteurs, conditions de concurrence non traitées, et validations d'entrée insuffisantes. Ces erreurs apparaissent souvent quand les interactions avec le noyau ne sont pas atomiques et quand les mécanismes de limitation des ressources font défaut ³.
Dans ce cas particulier, le vecteur d'exploitation est réduit : une interface exposée et la capacité d'envoyer des mises à jour suffisent. L'absence de fermeture systématique des sockets, combinée à l'absence de quotas applicatifs, offre un levier simple pour provoquer la saturation du système ¹ ².
Réactions et conséquences
Correctifs et actions officielles
Les mainteneurs de FreeBSD ont publié un avis de sécurité et un correctif pour blocklistd visant à corriger la fermeture des sockets et à désactiver temporairement certains points d'entrée non nécessaires ². Plusieurs fournisseurs d'appliances et distributions dérivées ont reçu des communications pour intégrer ces correctifs dans leurs images. Des recommandations immédiates incluent l'application du patch officiel, le redémarrage ordonné du démon et l'augmentation de la journalisation pour détecter des motifs de fuite ².
Un rapport d'analyse indépendant fournit des détails sur les conditions de reproduction et sur des mesures compensatoires à court terme, notamment la limitation logicielle des appels créant des sockets et des vérifications d'intégrité des entrées reçues ¹ ³.
Impacts opérationnels
Les conséquences les plus visibles sont des interruptions de services réseau : pare-feu, NAT, proxies et autres appliances peuvent perdre la capacité d'établir de nouvelles connexions. Dans des environnements hautement disponibles, des basculements fréquents ou mal orchestrés peuvent amplifier la dégradation, générant latence et perte de sessions.
Pour les fournisseurs d'accès ou opérateurs qui exécutent des NAT/CGNAT sur FreeBSD, l'effet peut se traduire par des coupures massives touchant des milliers d'abonnés si une appliance critique tombe en panne ou est rendue instable par la fuite de sockets ¹ ².
Au-delà du déni de service pur, un attaquant capable de placer une appliance en état dégradé peut profiter de la fenêtre d'opportunité pour tenter d'autres actions : exfiltration, manipulation de routage, ou exploitation d'autres vulnérabilités présentes sur des systèmes surchargés.
Recommandations
Mesures immédiates (48 heures)
- Appliquez le correctif officiel publié par le projet FreeBSD et redémarrez blocklistd de manière contrôlée ².
- Si le patch ne peut pas être déployé immédiatement, désactivez les interfaces ou services superflus exposant blocklistd et bloquez les sources suspectes au niveau du pare-feu (pf, ipfw).
- Activez une journalisation détaillée et des alertes sur l'évolution du nombre de descripteurs ouverts par processus. Commandes utiles sur FreeBSD :
- systat -ifstat et top pour la surveillance système générale - procstat -fpour lister les descripteurs d'un processus - sockstat -4 -l | grep blocklistd pour inventorier les sockets livrés par blocklistd
- En dépannage rapide, ajustez temporairement les paramètres
kern.maxfilesetkern.maxfilesperprocpour limiter la vélocité d'épuisement, tout en planifiant un correctif définitif ².
Mesures opérationnelles et long terme
- Implémentez un rate limiting sur les flux de mise à jour envoyés à blocklistd, côté producteurs et côté récepteur.
- Segmentez les fonctions critiques sur des hôtes séparés et privilégiez des contrôles de santé indépendants afin d'éviter des basculements en cascade.
- Auditez tous les scripts et appliances qui alimentent blocklistd : validez et nettoyez systématiquement les entrées, imposez des quotas par source et traitez les erreurs de façon robuste.
- Intégrez des tests de charge et des exercices de crise (tabletop) centrés sur l'épuisement des ressources : simulez des flux malformés pour vérifier la résilience et la qualité des procédures de reprise.
Détection et indicateurs
Surveillez ces indicateurs :
- Augmentation rapide et soutenue du nombre de sockets ouverts par le processus blocklistd.
- Logs système montrant des erreurs « too many open files » ou refus d'allocations.
- Pics de trafic ciblant les endpoints API de blocklistd ou des sous-réseaux spécifiques.
Mettez en place des alertes si la dérive du nombre de descripteurs dépasse un seuil défini sur une fenêtre courte (par exemple, +50% en 60 s).
Communication et remédiation
Si vous observez un incident : isolez l'hôte, collectez diagnostics et journaux (procstat, sockstat, dumps si possible), appliquez le patch, puis redémarrez blocklistd de façon ordonnée. Informez les équipes réseau et opérations et préparez un bulletin de sécurité pour les clients et partenaires, en indiquant l'état de la remédiation et les mesures compensatoires appliquées ².
Scénarios opérationnels illustrés
- Pare-feu d'entreprise exposé à un partenaire : une interface mal configurée permet à un partenaire compromis d'envoyer des mises à jour malformées et de faire basculer la machine. Le basculement automatique déclenche des latences et perturbe les services métiers.
- Opérateur avec CGNAT sur FreeBSD : une appliance saturée par la fuite provoque une dégradation de l'accès à Internet pour des milliers d'abonnés jusqu'à détection et correction manuelle.
Ces scénarios soulignent la nécessité d'un inventaire précis des appliances exécutant blocklistd et d'une feuille de route de patching prioritaire ².
