Billion Laughs Attack : L'XML qui met les serveurs à genoux

Comment un petit fichier XML de moins de 1 Ko peut consommer des gigaoctets de mémoire et faire planter vos serveurs via une expansion exponentielle des entités.

Introduction : Quand le rire devient une arme

Dans le domaine de la cybersécurité, certaines des attaques les plus dévastatrices proviennent d’endroits inattendus. L’attaque Billion Laughs — aussi appelée bombe XML ou attaque d’expansion exponentielle des entités — est un exemple parfait de comment un document XML apparemment inoffensif peut faire s’effondrer des serveurs d’entreprise. Cette attaque par déni de service (DoS) exploite une fonctionnalité fondamentale des parsers XML, transformant leur capacité utile d’expansion des entités en une arme destructrice.

Déjà signalée dès 2002 et ayant attiré une attention mondiale vers 2008, cette vulnérabilité continue d’affecter les applications modernes. Des CVEs récentes en 2024 et 2025, notamment des vulnérabilités dans les bibliothèques LangChain (CVE-2024-1455) et dans les parsers de sitemap (CVE-2025-3225), montrent que cette voie d’attaque reste pertinente plus de deux décennies après sa découverte.

Comprendre les entités XML et DTD

Avant d’aborder la mécanique de l’attaque, il est essentiel de comprendre comment fonctionnent les entités XML. XML (Extensible Markup Language) permet aux développeurs de définir des entités — des morceaux de contenu réutilisables — dans une Définition de Type de Document (DTD). Ces entités agissent comme des variables ou constantes référencées tout au long d’un document XML.

Il existe deux types de DTD :

DTD interne : Défini directement dans le document XML, entre la déclaration `!DOCTYPE et la fermeture.

DTD externe : Déclaré dans un fichier séparé et lié au document XML via une référence URI.

Les entités ont des usages légitimes, comme définir des chaînes de texte fréquemment utilisées ou référencer des fichiers externes. Cependant, cette flexibilité crée une surface d’attaque dangereuse lorsqu’elle est combinée avec des définitions d’entités récursives.

L’anatomie d’une attaque Billion Laughs

La charge utile classique de Billion Laughs est élégamment destructrice dans sa simplicité. Voici la structure de l’attaque :

?xml version="1.0"?
!DOCTYPE lolz [
  !ENTITY lol "lol"
  !ELEMENT lolz (#PCDATA)
  !ENTITY lol1 "lol;lol;lol;lol;lol;lol;lol;lol;lol;lol;"
  !ENTITY lol2 "lol1;lol1;lol1;lol1;lol1;lol1;lol1;lol1;lol1;lol1;"
  !ENTITY lol3 "lol2;lol2;lol2;lol2;lol2;lol2;lol2;lol2;lol2;lol2;"
  !ENTITY lol4 "lol3;lol3;lol3;lol3;lol3;lol3;lol3;lol3;lol3;lol3;"
  !ENTITY lol5 "lol4;lol4;lol4;lol4;lol4;lol4;lol4;lol4;lol4;lol4;"
  !ENTITY lol6 "lol5;lol5;lol5;lol5;lol5;lol5;lol5;lol5;lol5;lol5;"
  !ENTITY lol7 "lol6;lol6;lol6;lol6;lol6;lol6;lol6;lol6;lol6;lol6;"
  !ENTITY lol8 "lol7;lol7;lol7;lol7;lol7;lol7;lol7;lol7;lol7;lol7;"
  !ENTITY lol9 "lol8;lol8;lol8;lol8;lol8;lol8;lol8;lol8;lol8;lol8;"
]
lolzlol9;/lolz

Comment fonctionne l’expansion exponentielle

L’attaque définit 10 entités, de lol à lol9. La première contient simplement la chaîne “lol”. Chaque entité suivante référence la précédente dix fois. Lorsqu’un parser XML traite ce document, il rencontre lol9; dans le corps du document.

Voici où la mathématique devient terrifiante :

• lol9; se développe en 10 instances de lol8;
• Chaque lol8; se développe en 10 instances de lol7;
• Cela continue récursivement jusqu’à lol;

Le résultat ? Un document contenant 10^9 (un milliard) de copies de la chaîne “lol.” Ce petit fichier XML — de moins de 1 Ko — s’étend à environ 3 gigaoctets en mémoire. Le nom “Billion Laughs” vient directement de cette répétition d’un milliard de “lol”.

La variante de déploiement quadratique

Les chercheurs en sécurité et les attaquants ont développé des variantes pour contourner les contre-mesures. L’attaque de déploiement quadratique adopte une approche différente qui évite la détection des entités profondément imbriquées.

Au lieu d’utiliser un nesting récursif, cette variante définit une seule grande entité contenant des milliers de caractères, puis la référence des milliers de fois. Une charge utile d’environ 200 Ko peut s’étendre à 2,5 gigaoctets lors du parsing. Cette méthode évite de déclencher les contre-mesures du parser qui vérifient spécifiquement les structures d’entités profondément imbriquées.

Impact réel et incidents historiques

Vulnérabilité WordPress et Drupal (2014)

Un des incidents majeurs s’est produit en 2014, lorsque des millions d’installations WordPress et Drupal ont été trouvées vulnérables aux attaques de déploiement quadratique XML. La vulnérabilité dans le processeur XML de PHP, utilisé par XMLRPC, permettait aux attaquants de provoquer une surcharge CPU et mémoire, pouvant mettre hors ligne des sites et submerger des bases de données avec des requêtes.

Vulnérabilités MediaWiki (2015)

Les versions de MediaWiki avant 1.24.2 étaient vulnérables aux attaques Billion Laughs via le téléchargement SVG et l’analyse des métadonnées XMP, montrant comment l’attaque peut se propager via des uploads de fichiers apparemment innocents.

Vulnérabilités des frameworks IA modernes (2024-2025)

Même les technologies de pointe restent vulnérables. CVE-2024-1455 a affecté la bibliothèque d’IA LangChain, où l’analyse XML dans certains composants pouvait être exploitée pour des attaques Billion Laughs. Cela souligne que cette vulnérabilité dépasse les applications web traditionnelles et touche aussi l’infrastructure IA moderne.

Au-delà de XML : vecteurs d’attaque dans d’autres formats

Bien que ciblant initialement XML, le concept de Billion Laughs s’applique à tout format supportant l’expansion de macro ou d’entités.

Parsers YAML

Les parsers YAML présentent des risques similaires via les ancres () et les alias (*), qui permettent des références récursives provoquant une expansion exponentielle lors de la désérialisation. La bibliothèque PyYAML, par exemple, a des vulnérabilités documentées liées à ce modèle d’attaque.

Métadonnées SVG et images

Les fichiers SVG, étant basés sur XML, peuvent contenir des charges utiles Billion Laughs. De même, les métadonnées XMP dans des formats comme PDF ou JPEG peuvent contenir des bombes XML exploitant l’extraction de métadonnées.

Considérations JSON

Bien que JSON ne supporte pas nativement les entités, des attaques par déni de service similaires peuvent survenir via des structures profondément imbriquées ou récursives. La bibliothèque Jackson en Java, par exemple, a connu CVE-2020-36518, où un nesting non limité provoquait un dépassement de pile.

Scénarios d’attaque courants

Les attaquants peuvent livrer des charges Billion Laughs via plusieurs vecteurs :

Requêtes POST d’applications web : Envoi de XML malveillant directement aux endpoints acceptant du XML, comme les services SOAP ou les API REST.

Uploads de fichiers : Upload d’images SVG, documents Office (DOCX, XLSX) ou autres fichiers contenant du XML qui déclenchent le parsing côté serveur.

Messages SOAP : Les web services d’entreprise utilisant SOAP sont particulièrement vulnérables lors du traitement de payloads XML non fiables.

Fichiers de configuration : Les applications acceptant des fichiers XML de configuration de l’utilisateur peuvent traiter involontairement des entités malveillantes.

Stratégies de prévention et de mitigation

Protéger les applications contre les attaques Billion Laughs nécessite une approche en plusieurs couches.

1. Désactiver complètement le traitement DTD

La défense la plus efficace consiste à désactiver totalement le traitement DTD (Document Type Definition). Lorsqu’il est désactivé, presque toutes les attaques par entités XML deviennent impossibles. Selon les recommandations OWASP, cela doit être la première ligne de défense.

2. Limiter l’expansion des entités

Si la désactivation du DTD n’est pas possible, configurer des limites strictes sur l’expansion des entités. Pour les applications .NET, la propriété MaxCharactersFromEntities limite la quantité de contenu pouvant être générée par les entités. En Java, on peut utiliser XMLConstants.FEATURE_SECURE_PROCESSING pour activer des restrictions de sécurité.

3. Utiliser des configurations de parser sécurisées

Différents langages nécessitent des configurations spécifiques :

Java : Définir la propriété http://apache.org/xml/features/disallow-doctype-decl à true sur DocumentBuilderFactory ou SAXParserFactory.

Python : Utiliser la bibliothèque defusedxml ou configurer les parsers avec resolve_entities=False.

PHP : Avant la version 8.0, désactiver explicitement le chargement des entités externes. PHP 8.0 et versions ultérieures empêchent par défaut les XXE.

.NET : Les versions 4.5.2 et ultérieures incluent des protections intégrées, mais les versions plus anciennes nécessitent une configuration explicite pour définir DtdProcessing à Prohibit ou Ignore.

4. Implémenter une expansion paresseuse des entités

Au lieu d’expanser toutes les entités immédiatement, configurer les parsers pour n’expanser les entités que lorsque leur contenu est réellement nécessaire. Cela limite l’impact de l’expansion exponentielle.

5. Considérer des formats alternatifs

JSON est devenu l’alternative privilégiée à XML pour l’échange de données dans de nombreux scénarios. Étant donné que JSON ne supporte pas les références d’entités externes ni leur expansion, il élimine toute cette classe de vulnérabilités.

6. Validation et assainissement des entrées

Avant de traiter tout XML, valider et assainir le contenu. Bloquer ou échapper les métacaractères XML comme , , ", et  lorsque ceux-ci apparaissent dans du contenu fourni par l’utilisateur destiné à être intégré dans des documents XML.

Tester la vulnérabilité

Les équipes de sécurité doivent régulièrement tester leurs applications contre les vulnérabilités de bombes XML en utilisant des outils comme :

• OWASP ZAP : Inclut des vérifications pour les vulnérabilités d’expansion exponentielle des entités
• Burp Suite : Peut injecter des payloads XML malveillants pour tester le comportement du parser
• Nikto : Identifie les vulnérabilités XXE et autres dans les applications web

Les techniques de fuzzing qui injectent des entités malveillantes dans des payloads XML peuvent révéler les faiblesses du parser avant que des attaquants ne les exploitent.

Conseils spécifiques aux frameworks

Framework .NET

Les applications utilisant .NET Framework 4.5.1 et antérieur sont vulnérables par défaut. Les classes XmlDocument, XPathNavigator, et XMLReader nécessitent une configuration explicite pour désactiver le traitement DTD :

XmlReaderSettings settings = new XmlReaderSettings()
{
    DtdProcessing = DtdProcessing.Prohibit,
    MaxCharactersFromEntities = 1024
};

Applications Java

Les applications Java doivent configurer leurs usines de parser pour interdire les déclarations doctype :

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setXIncludeAware(false);

Applications Python

Les modules XML de la bibliothèque standard ont des vulnérabilités variables. La documentation officielle recommande d’utiliser defusedxml pour traiter du XML non fiable.

Conclusion : Une vulnérabilité persistante

L’attaque Billion Laughs représente une intersection fascinante entre ingénierie astucieuse et impact dévastateur. Un concept documenté il y a plus de deux décennies continue d’affecter les applications modernes, des systèmes de gestion de contenu aux frameworks IA de pointe.

La persistance de cette vulnérabilité souligne plusieurs leçons importantes pour la communauté de la sécurité. D’abord, des défauts fondamentaux dans des technologies largement utilisées peuvent avoir une longévité remarquable. Ensuite, la sécurité doit être intégrée par défaut dans la configuration des parsers, pas laissée à la discrétion des développeurs. Enfin, même les vulnérabilités bien comprises nécessitent une vigilance constante alors qu’elles apparaissent dans de nouveaux contextes et technologies.

Pour les développeurs et professionnels de la sécurité, la voie à suivre est claire : désactiver le traitement DTD autant que possible, mettre en place des limites strictes d’expansion des entités lorsque les DTD sont nécessaires, auditer régulièrement les applications pour détecter des vulnérabilités XML, et envisager la migration vers des formats de données plus sûrs où les fonctionnalités XML ne sont pas essentielles.

L’attaque Billion Laughs peut avoir un nom amusant, mais il n’y a rien de drôle à voir un serveur en production s’effondrer. En comprenant la mécanique de cette attaque et en mettant en œuvre des défenses appropriées, les organisations peuvent s’assurer que le dernier rire leur appartient — pas aux attaquants.