YAML ist eines der beliebtesten Formate für die Datenserialisierung und wird in zahlreichen Anwendungen und Programmiersprachen eingesetzt. Es besticht durch eine einfache, leserliche Syntax, die sich besonders für Konfigurationsdateien eignet. Allerdings bringt die scheinbare Einfachheit von YAML auch besondere Herausforderungen mit sich, vor allem wenn es darum geht, wie verschiedene YAML-Parser gleiche Eingabedateien unterschiedlich interpretieren. Genau hier setzt das Phänomen des „Safe“ YAML Monsters an – ein Begriff, der in Entwicklerkreisen aktuell für Furore sorgt und spannende Einblicke in sicherheitsrelevante Aspekte von YAML bietet. Der Ursprung der Geschichte beginnt mit der Beobachtung, dass verschiedene YAML-Parser in den populären Programmiersprachen Python, Go, Ruby, Java und Node. js ein und denselben YAML-Code auf unterschiedliche Weise auswerten.
Diese Abweichungen werden als „Parser-Differents“ bezeichnet und sind speziell in sicherheitskritischen Anwendungen von großer Bedeutung, da sie unter Umständen zu unerwartetem Verhalten führen können. Dieses Verhalten ist dabei durchaus gewollt, um sogenannte „unsafe“ Praktiken zu vermeiden, und wird als „safe parsing“ beschrieben. Doch gerade in diesem sicheren Kontext offenbaren sich überraschende Eigenheiten – ein echtes Monster im vermeintlich sicheren System. Die zentrale Fragestellung dabei ist, wie Schlüssel in YAML-Dokumenten behandelt werden, insbesondere wenn sie mehrfach vorkommen oder besondere Eigenschaften, wie das Einbetten von Binärdaten über Tags, besitzen. Das YAML-Format erlaubt es technisch zwar nicht, denselben Schlüssel mehrfach innerhalb einer Map zu verwenden – viele Parser reagieren darauf jedoch unterschiedlich. In Go beispielsweise führt ein doppelter Schlüssel zu einem Fehler. In Python hingegen wird z. B.
das letzte Vorkommen dieses Schlüssels genommen, während Ruby mit der sogenannten Merge-Key-Technik („<<:“) experimentiert, die vererbbare Maps erlaubt – wenn auch mit herstellerspezifischen Eigenheiten. Besonders spannend wird es, wenn YAML-Tags, etwa ! ! binary, ins Spiel kommen. Hierbei können Schlüssel als binäre Daten kodiert werden, was bei der Interpretation durch unterschiedliche Parser zu variierenden Resultaten führt. So kann etwa ein Schlüssel als normaler String „lang“ interpretiert werden, während ein anderer Parser denselben Schlüssel als Bytearray behandelt, was effektiv zwei verschiedene Schlüssel entstehen lässt. Daraus resultiert, dass die jeweils letzte Zuweisung in der Map für den Schlüssel unterschiedlich sein kann – ein cleverer und zugleich gefährlicher Trick, der als Basis für das „Safe“ YAML Monster dient. Des Weiteren überraschen bestimmte Unicode-Zeichen wie der Byte Order Mark (BOM) in UTF-8 kodierten Dateien den Parser.
Bei einigen Parsern, beispielsweise Ruby, kann die Anwendung des BOM in den Schlüsseln bewirken, dass eine Überschreibung durch andere Einträge verhindert wird, während andere Sprachen die BOM ignorieren oder anders interpretieren. Dadurch entsteht die Möglichkeit, denselben YAML-Code so zu gestalten, dass er je nach Parser unterschiedliche „Sprachen“ oder Werte liefert – fast so, als enthielte diese Dateien eine Art „versteckte Botschaft“ oder Mehrfachidentität. Die Erkenntnisse zu diesen „Monstern“ wurden maßgeblich durch das Zusammenspiel von Einträgen wie binären Tags, Mergeschlüsseln und Aliases (Verweisen) gewonnen. Insbesondere die Nutzung von YAML-Verankerungen (Anchors) und Verweisen (Aliases), etwa um Schlüssel mehrfach zu referenzieren, führt zu komplexen, aber validen Dokumenten, die verschiedene Parser unterschiedlich auflösen. Ein Beispiel zeigt, wie Node. js und Go durch die feine Unterscheidung von String- und Binärformat bei Aliases auseinanderdivergieren.
Während Node. js einen Alias als Key interpretiert, akzeptiert Go die Binärdaten als alleinstehenden Schlüssel und behandelt sie als normal. Die Schwierigkeit, alle diese Eigenheiten zu vereinen, wird noch bedeutender, wenn man bedenkt, dass die YAML-Spezifikation selbst gewisse Freiräume oder gar keine abschließenden Beurteilungen für das Verhalten bei einigen Features wie dem Merging („<<:“) definiert. Unterschiedliche Parsing-Engines implementieren Konzepte deshalb unterschiedlich und teilweise inkonsistent. Dies hat zur Konsequenz, dass YAML, obwohl als „lesbar“ und „einfach“ propagiert, in sicherheitskritischen Kontexten besondere Aufmerksamkeit benötigt, denn trotz aller Bemühungen um „sichere“ Parser existieren immer noch Möglichkeiten, wie etwa Überlagerungen, Mehrfachbelegungen oder spezielle Zeichencodierungen, um unterschiedliche Ausgaben in verschiedenen Umgebungen zu erzeugen.
Ein weiterer bemerkenswerter Punkt ist die Tatsache, dass der sogenannte „Safe“-Ansatz nicht unbedingt bedeutet, dass der YAML-Code für alle Parser gleich interpretiert wird. Jeder Parser kann je nach Sprache und Implementierung andere Präferenzen oder Standards erfüllen. Während Python PyYAML insbesondere aus Sicherheitsgründen den sicheren Ladevorgang bevorzugt und viele Sonderfälle strikt ablehnt, zeigen etwa Java-Parser (wie SnakeYAML), Node. js oder Rust eigene Verarbeitungslogiken, die fehleranfällig oder zumindest speziell sind. Somit entsteht ein Umfeld, in dem Entwickler vorsichtig sein sollten, wenn YAML-Dateien an unterschiedlichen Stellen verwendet werden, da Sicherheitslücken oder Fehlinterpretationen durch diese „Parser-Differentials“ möglich sind. Interessant sind auch die praktischen Tests, bei denen identische YAML-Dateien in Containern mit unterschiedlichen Laufzeitumgebungen ausgeführt wurden. So konnten mit einem einzigen YAML-Dokument in Python, Ruby, Go, Node.
js, Java und sogar Rust je unterschiedliche Ergebnisse zurückgegeben werden – was für Entwickler und Sicherheitsforscher gleichermaßen faszinierend wie herausfordernd ist. Nur so lassen sich die Burger zwischen unterschiedlichen Interpretationspfaden anhand von Binärdaten, BOMs und Merge-Schlüsseln nachvollziehen und bei Bedarf kontrollieren. Im Kern zeigen die Erkenntnisse über das „Safe“ YAML Monster eindrucksvoll, dass YAML, trotz ihrer vermeintlichen Einfachheit, ein vielschichtiges Datenformat ist, das tief in Parsing-Mechanismen verankert ist und über scheinbar triviale Features eine Schnittstelle zur Sicherheit und Integrität von Anwendungen bildet. Gerade wenn YAML als Konfigurationsformat in sicherheitsrelevanten Applikationen verwendet wird, sind diese Parser-Differenzen mehr als nur akademische Spielereien – sie können zu realen Schwachstellen führen.
Für Entwickler empfiehlt es sich daher, die Besonderheiten des verwendeten Parsers zu verstehen, strenge Konventionen für YAML-Dokumente einzuhalten und im Zweifel Parser-spezifische Eigenheiten zu berücksichtigen. Dazu gehören neben dem Verzicht auf Mehrfachbelegungen von Schlüsseln auch eine präzise Nutzung von YAML-Tags und das Bewusstsein für Zeichenkodierungen wie BOM. Ebenso sollten nicht-standardisierte Features wie Merge-Operatoren nur mit Vorsicht und dem Wissen um deren Implementierung in der Zielumgebung verwendet werden. Abschließend lässt sich festhalten, dass das „Safe“ YAML Monster ein spannendes Beispiel dafür ist, wie scheinbar triviale technische Details und unterschiedliche Software-Implementierungen zu weitreichenden Auswirkungen, vor allem in puncto Sicherheit, führen können. Es bleibt weiterhin wichtig, den Austausch zwischen der Entwickler- und Sicherheits-Community zu fördern, um solche „Monster“ zu erkennen, zu dokumentieren und im besten Fall zu bezwingen.
YAML bleibt zwar ein mächtiges und flexibles Werkzeug, aber nur wer seine inneren Fallen kennt und umgeht, kann dessen volle Stärke sicher nutzen.
