Billion Laughs Attack: Das XML, das Server in die Knie zwingt

Wie eine winzige XML-Datei unter 1 KB Gigabytes an Speicher verbrauchen und Ihre Server durch exponentielle Entity-Erweiterung zum Absturz bringen kann.

Einführung: Wenn Lachen zur Waffe wird

In der Welt der Cybersicherheit kommen einige der verheerendsten Angriffe aus den unerwartetsten Quellen. Der Billion Laughs-Angriff—auch bekannt als XML-Bombe oder exponentielle Entity-Erweiterung—ist ein Paradebeispiel dafür, wie ein scheinbar harmloses XML-Dokument Enterprise-Server zum Absturz bringen kann. Dieser Denial-of-Service (DoS)-Angriff nutzt eine grundlegende Funktion von XML-Parsern aus, indem er deren hilfreiche Entity-Erweiterungsfähigkeit in eine zerstörerische Waffe verwandelt.

Bereits 2002 erstmals gemeldet und ab 2008 weitreichend bekannt, betrifft diese Schwachstelle auch moderne Anwendungen. Aktuelle CVEs in 2024 und 2025, darunter Schwachstellen in LangChain-Bibliotheken (CVE-2024-1455) und Sitemap-Parsern (CVE-2025-3225), zeigen, dass dieses Angriffsvektor mehr als zwei Jahrzehnte nach seiner Entdeckung relevant bleibt.

Verständnis von XML-Entities und DTDs

Bevor wir in die Angriffstechnik eintauchen, ist es wichtig zu verstehen, wie XML-Entities funktionieren. XML (Extensible Markup Language) erlaubt Entwicklern, Entities zu definieren—im Wesentlichen wiederverwendbare Inhaltsstücke—innerhalb einer Document Type Definition (DTD). Diese Entities fungieren als Variablen oder Konstanten, die im gesamten XML-Dokument referenziert werden können.

Es gibt zwei Arten von DTDs:

Interne DTD: Direkt im XML-Dokument definiert, eingebettet zwischen der c!DOCTYPEe-Deklaration und der schließenden Klammer.

Externe DTD: In einer separaten Datei deklariert und über eine URI-Referenz mit dem XML-Dokument verbunden.

Entities erfüllen legitime Zwecke, etwa die Definition häufig verwendeter Textstrings oder das Referenzieren externer Dateien. Diese Flexibilität schafft jedoch eine gefährliche Angriffsfläche, wenn sie mit rekursiven Entity-Definitionen kombiniert wird.

Die Anatomie eines Billion Laughs-Angriffs

Das klassische Billion Laughs-Payload ist elegant in seiner Zerstörungskraft. Hier die Struktur des Angriffs:

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

Wie die exponentielle Expansion funktioniert

Der Angriff definiert 10 Entities, von lol bis lol9. Die erste Entity enthält einfach den String “lol.” Jede nachfolgende Entity referenziert die vorherige zehnmal. Wenn ein XML-Parser dieses Dokument verarbeitet, stößt er auf 66lol9; im Dokumenteninhalt.

Hier wird die Mathematik erschreckend:

• 66lol9; expandiert zu 10 Instanzen von 66lol8;
• Jede 66lol8; expandiert zu 10 Instanzen von 66lol7;
• Dies setzt sich rekursiv bis 66lol; fort

Das Ergebnis? Ein Dokument, das 10^9 (eine Milliarde) Kopien des Strings “lol” enthält. Diese winzige XML-Datei—unter 1 Kilobyte groß—expandiert auf etwa 3 Gigabyte im Speicher. Der Name “Billion Laughs” stammt direkt von dieser billionenfachen Wiederholung von “lol”.

Die quadratische Blowup-Variante

Sicherheitsforscher und Angreifer haben Varianten entwickelt, um Abwehrmaßnahmen zu umgehen. Der quadratische Blowup-Angriff verfolgt einen anderen Ansatz, der tief verschachtelte Entities umgeht.

Anstatt rekursive Verschachtelung zu verwenden, definiert diese Variante eine einzelne große Entity mit Tausenden von Zeichen und referenziert diese Entity Tausende Male. Ein Payload von ca. 200 Kilobyte kann sich beim Parsen auf 2,5 Gigabyte ausdehnen. Dieser Ansatz umgeht spezielle Parser-Mechanismen, die auf tief verschachtelte Entity-Strukturen prüfen.

Auswirkungen in der Praxis und historische Vorfälle

WordPress- und Drupal-Schwachstelle (2014)

Einer der bedeutendsten Vorfälle ereignete sich 2014, als Millionen von WordPress- und Drupal-Installationen anfällig für XML-quadratische Blowup-Angriffe waren. Die Schwachstelle im XML-Processor von PHP, der von XMLRPC-Implementierungen genutzt wird, erlaubte Angreifern, CPU- und Speicherauslastung zu verursachen, was Websites offline brachte und Datenbanken mit Verbindungsanfragen überflutete.

MediaWiki-Schwachstellen (2015)

MediaWiki-Versionen vor 1.24.2 waren anfällig für Billion Laughs durch SVG-Uploads und XMP-Metadaten-Parsing, was zeigt, wie der Angriff durch scheinbar harmlose Dateiuploads verbreitet werden kann.

Moderne KI-Framework-Schwachstellen (2024-2025)

Auch hochentwickelte Technologien sind betroffen. CVE-2024-1455 betraf die beliebte LangChain-KI-Bibliothek, bei der XML-Parsing in bestimmten Komponenten für Billion Laughs-Angriffe ausgenutzt werden konnte. Dies unterstreicht, dass diese Schwachstelle über traditionelle Webanwendungen hinausgeht und moderne KI-Infrastrukturen betrifft.

Über XML hinaus: Angriffspfade in anderen Formaten

Obwohl ursprünglich auf XML abzielend, gilt das Konzept der Billion Laughs auch für jedes Format, das Makro- oder Entity-Erweiterung unterstützt.

YAML-Parser

YAML-Parser sind durch Anker (6) und Aliase (*), die rekursive Referenzen ermöglichen, ähnlich gefährdet. Diese können während der Deserialisierung exponentielle Datenexpansionen verursachen. Die PyYAML-Bibliothek hat dokumentierte Schwachstellen in diesem Zusammenhang.

SVG und Bildmetadaten

SVG-Dateien, die XML-basiert sind, können Billion Laughs-Payloads enthalten. Ebenso können XMP-Metadaten in Formaten wie PDF oder JPEG XML-Bomben enthalten, die Metadaten-Extraktions-Tools ausnutzen.

JSON-Überlegungen

Da JSON keine native Entity-Unterstützung bietet, treten ähnliche DoS-Angriffe durch tief verschachtelte oder rekursive Strukturen auf. Die Jackson-Bibliothek in Java erlebte beispielsweise CVE-2020-36518, bei der unbeschränkte Verschachtelung zu Stack-Overflow-Ausnahmen führte.

Häufige Angriffsszenarien

Angreifer können Billion Laughs-Payloads über mehrere Vektoren liefern:

Webanwendungs-POST-Anfragen: Senden bösartiger XML direkt an Endpunkte, die XML-Eingaben akzeptieren, z.B. SOAP-Services oder REST-APIs.

Dateiuploads: Hochladen von SVG-Bildern, Office-Dokumenten (DOCX, XLSX) oder anderen XML-haltigen Dateien, die beim Server geparst werden.

SOAP-Nachrichten: Enterprise-Webdienste, die SOAP verwenden, sind besonders anfällig bei der Verarbeitung von untrusted XML-Payloads.

Konfigurationsdateien: Anwendungen, die XML-Konfigurationsdateien von Nutzern akzeptieren, könnten unbeabsichtigt bösartige Entities verarbeiten.

Prävention und Abwehrmaßnahmen

Der Schutz vor Billion Laughs-Angriffen erfordert einen mehrschichtigen Ansatz.

1. DTD-Verarbeitung vollständig deaktivieren

Der effektivste Schutz besteht darin, die DTD-Verarbeitung komplett zu deaktivieren. Wenn DTDs verboten sind, werden fast alle XML-Entity-Angriffe unmöglich. Laut OWASP-Richtlinien sollte dies die primäre Verteidigungsmaßnahme sein.

2. Begrenzung der Entity-Erweiterung

Wenn die Deaktivierung von DTDs nicht möglich ist, sollten strenge Limits für die Entity-Erweiterung gesetzt werden. Für .NET-Anwendungen steuert die MaxCharactersFromEntities-Eigenschaft, wie viel Inhalt Entities erweitern dürfen. Java-Anwendungen können XMLConstants.FEATURE_SECURE_PROCESSING verwenden, um Sicherheitsbeschränkungen zu aktivieren.

3. Sichere Parser-Konfigurationen verwenden

Verschiedene Programmiersprachen erfordern spezifische Einstellungen:

Java: Setzen Sie die Eigenschaft http://apache.org/xml/features/disallow-doctype-decl auf true bei DocumentBuilderFactory oder SAXParserFactory.

Python: Nutzen Sie die defusedxml-Bibliothek oder konfigurieren Sie Parser mit resolve_entities=False.

PHP: Für Versionen vor 8.0 deaktivieren Sie explizit das Laden externer Entities. PHP 8.0 und neuer verhindern XXE standardmäßig.

.NET: Versionen 4.5.2 und später haben integrierten Schutz, ältere Versionen erfordern explizite Konfiguration, um DtdProcessing auf Prohibit oder Ignore zu setzen.

4. Lazy Entity Expansion implementieren

Statt alle Entities sofort zu erweitern, konfigurieren Sie Parser so, dass Entities nur bei Bedarf expandiert werden. Dies begrenzt die Auswirkungen der exponentiellen Expansion.

5. Alternative Formate in Betracht ziehen

JSON ist in vielen Szenarien das bevorzugte Format für den Datenaustausch. Da JSON keine externen Entities oder Entity-Erweiterung unterstützt, eliminiert es diese Angriffsart vollständig.

6. Eingabekontrolle und -sanitisierung

Validieren und säubern Sie XML-Eingaben vor der Verarbeitung. Blockieren oder maskieren Sie XML-Metazeichen wie c, e, " und 6 bei nutzerdefinierten Inhalten, die in XML-Dokumente eingebettet werden.

Tests auf Schwachstellen

Sicherheitsteams sollten regelmäßig Anwendungen auf XML-Bomben-Schwachstellen testen, z.B. mit:

• OWASP ZAP: Enthält Prüfungen auf exponentielle Entity-Erweiterung
• Burp Suite: Kann bösartige XML-Payloads injizieren, um das Verhalten des Parsers zu testen
• Nikto: Erkennt XXE- und verwandte Schwachstellen in Webanwendungen

Fuzzing-Methoden, die schädliche Entities in XML-Payloads injizieren, können Schwächen des Parsers aufdecken, bevor Angreifer sie ausnutzen.

Framework-spezifische Hinweise

.NET Framework

Anwendungen mit .NET Framework 4.5.1 und älter sind standardmäßig anfällig. Die Klassen XmlDocument, XPathNavigator und XMLReader erfordern explizite Konfiguration, um DTD-Verarbeitung zu deaktivieren:

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

Java-Anwendungen

Java-Anwendungen sollten die Parser-Factory so konfigurieren, dass Doctype-Deklarationen verboten sind:

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

Python-Anwendungen

Die XML-Module der Standardbibliothek haben unterschiedliche Sicherheitsniveaus. Die offizielle Python-Dokumentation empfiehlt die Verwendung von defusedxml für die Verarbeitung untrusted XML.

Fazit: Eine anhaltende Schwachstelle

Der Billion Laughs-Angriff zeigt eine faszinierende Schnittstelle zwischen cleverer Technik und verheerender Wirkung. Ein Konzept, das vor über zwei Jahrzehnten dokumentiert wurde, beeinflusst noch heute moderne Anwendungen, von Content-Management-Systemen bis hin zu fortschrittlichen KI-Frameworks.

Die Persistenz dieser Schwachstelle unterstreicht wichtige Lektionen für die Sicherheitsgemeinschaft. Erstens: Grundlegende Designfehler in weitverbreiteten Technologien können erstaunlich lange bestehen bleiben. Zweitens: Sicherheit muss in Parser-Konfigurationen standardmäßig integriert sein, nicht nur eine Entwickleraufgabe. Drittens: Auch gut verstandene Schwachstellen erfordern ständige Wachsamkeit, da sie in neuen Kontexten und Technologien wieder auftauchen.

Für Entwickler und Sicherheitsexperten ist der Weg klar: Deaktivieren Sie DTD-Verarbeitung, wo immer möglich, setzen Sie strenge Limits für Entity-Erweiterungen bei Bedarf, auditieren Sie Anwendungen regelmäßig auf XML-Sicherheitslücken und erwägen Sie den Umstieg auf sicherere Datenformate, bei denen XML-Funktionen nicht notwendig sind.

Der Billion Laughs-Angriff mag einen humorvollen Namen haben, aber es ist nichts Lustiges, wenn ein Produktionsserver abstürzt. Durch das Verständnis der Angriffsmechanismen und die Implementierung geeigneter Schutzmaßnahmen können Organisationen sicherstellen, dass der letzte Lacher ihnen gehört—nicht den Angreifern.