Tcl-Sandbox ausgehebelt: Wenn eine Zeitzone Code ausführt

Tcl kann fremden Code in einer Sandbox ausführen. Bei SektionEins wurden mithilfe von KI mehrere Wege gefunden, auf denen solcher Code aus ihr ausbricht und mit den vollen Rechten der Anwendung beliebige Befehle ausführt. Ein Advisory mit allen Details ist heute erschienen.

Tcl in aller Kürze

Tcl steht für „Tool Command Language“ und wird meist „tickle“ ausgesprochen. John Ousterhout hat die Sprache 1988 an der University of California in Berkeley entwickelt. Seine Idee war eine kleine Skriptsprache, die man in eigene Programme einbettet, damit nicht jedes Werkzeug seine eigene Kommandosprache erfinden muss. 1991 kam das GUI-Toolkit Tk dazu, das bis heute hinter Pythons tkinter steckt.

Wer nicht in der passenden Nische arbeitet, begegnet Tcl selten bewusst. Verbreitet ist es trotzdem: Werkzeuge für den Chipentwurf wie Vivado oder Quartus werden über Tcl gesteuert, mit Expect automatisieren Administratoren seit über 30 Jahren interaktive Kommandozeilenprogramme, Cisco-Router und F5-Loadbalancer lassen sich in Tcl skripten, und die Testsuite von SQLite ist in Tcl geschrieben. Dazu kommen viele Inhouse-Anwendungen, die seit Jahren zuverlässig laufen und über die niemand spricht. Aktuell ist Tcl 9, viele Installationen laufen aber noch mit 8.6.

Die Sandbox: Safe-Interpreter

Tcl kann fremden Code in einem sogenannten Safe-Interpreter ausführen. Dort fehlen Befehle wie exec, open oder socket, der Code kann also weder Programme starten noch beliebige Dateien öffnen. Anwendungen nutzen das für Plugin- und Makrosysteme, für Formel- und Regel-Engines oder für Templates, also überall dort, wo Benutzer eigenen Tcl-Code mitbringen.

Ein paar Befehle reicht Tcl trotzdem in die Sandbox durch. Sie laufen dann im vertrauenswürdigen Interpreter der Anwendung, mit allen Rechten. Einer davon ist clock, der Befehl für Datum und Uhrzeit.

Die Lücken

clock lädt bei Bedarf Sprachdateien (etwa für Monatsnamen) und Zeitzonendateien. Aus einem Namen wie de_DE oder Europe/Berlin baut Tcl einen Dateipfad und führt die Datei als Tcl-Code aus. Ein regulärer Ausdruck soll verhindern, dass der Name aus dem Datenverzeichnis herausführt. Diese Prüfung hat an mehreren Stellen nicht gehalten.

Seit Tcl 8.6.5 aus dem Jahr 2016 wurde die Sprachangabe gar nicht geprüft. Eine Zeile in der Sandbox reichte, damit die Anwendung eine beliebige Datei mit der Endung .msg ausführte:

clock format 0 -gmt 1 -locale /pfad/zur/datei

Anfang Oktober 2026 hatten die Tcl-Entwickler unabhängig davon eine Prüfung ergänzt, als gewöhnlichen Bugfix und nicht als Sicherheitskorrektur. Diese Prüfung ließ Pfade mit Tilde durch, und aus ~/verzeichnis/datei macht Tcl 8.6 einen Pfad im Home-Verzeichnis. Das wurde am 20. Oktober gemeldet, neun Tage später war die Korrektur in allen Entwicklungszweigen.

Beim Nachprüfen dieser Korrektur wurde eine zweite Stelle mit derselben Lücke gefunden, die Zeitzonenangabe:

clock format 0 -timezone :~/verzeichnis/datei

Hier hängt Tcl keine Dateiendung an, jede Datei unterhalb eines Home-Verzeichnisses kommt in Frage. Diese Lücke steckt seit Tcl 8.6.16 im Code und ist Stand heute noch offen. Tcl 9 ist von ihr nicht betroffen.

Die eingeschleuste Datei läuft in allen Fällen mit den vollen Rechten der Anwendung und kann zum Beispiel über exec beliebige Programme starten. Eine Voraussetzung bleibt: Der Angreifer muss vorher eine Datei mit eigenem Inhalt an einer bekannten Stelle ablegen können, etwa über eine Upload-Funktion. Das Risiko ist mit CVSS 8.3 als hoch eingestuft. Eine Tcl-Version mit den Korrekturen ist noch nicht erschienen. Alle Lücken wurden mit Builds verschiedener Tcl-Versionen von 8.5 bis zum aktuellen Entwicklungsstand und je einem Proof of Concept nachvollzogen.

Auch ohne Sandbox gibt es ein Problem. Webanwendungen, die eine Sprache aus der Anfrage (?lang=de oder Accept-Language) ungeprüft an clock oder msgcat weitergeben, laden damit Dateien, die der Angreifer bestimmt.

Zwei Prüfungen, dieselbe Lücke

Lehrreich ist, wie es zur Zeitzonen-Lücke kam. Bis Tcl 8.6.15 prüfte clock Zeitzonennamen mit einer Allowlist: Erlaubt waren nur Buchstaben, Bindestrich, Unterstrich und Schrägstrich. Weil sich damit Namen wie Etc/GMT+5 nicht laden ließen, wurde sie Ende 2024 durch eine Denylist ersetzt, die absolute Pfade, Laufwerksbuchstaben und „..“ verbietet. An die Tilde hat dabei niemand gedacht. Die neue Prüfung für Sprachdateien vom Oktober hat diese Denylist übernommen, samt Lücke.

Wenn aus Benutzereingaben Dateinamen werden, ist eine Allowlist fast immer die bessere Wahl. Sie legt fest, was erlaubt ist, statt darauf zu hoffen, dass man an alles Verbotene gedacht hat.

Was Tcl-Anwender jetzt tun können

Wer Safe-Interpreter für fremden Code einsetzt, sollte prüfen, ob der Code dort clock überhaupt braucht. Wenn nicht, lässt sich der Befehl mit einer Zeile aus der Sandbox entfernen:

interp alias $child clock {}

Andernfalls hilft ein Wrapper, der Sprach- und Zeitzonenangaben mit Pfadanteilen ablehnt. Ein getestetes Beispiel steht im Advisory. Im übrigen Anwendungscode sollten Sprachangaben gegen eine Allowlist geprüft werden, bevor sie an clock oder msgcat gehen.

Ein Safe-Interpreter schränkt außerdem nur die verfügbaren Befehle ein. Speicher und Rechenzeit begrenzt er nicht, deshalb gehört wirklich fremder Code zusätzlich in einen eigenen Prozess mit wenig Rechten. Sobald Tcl-Versionen mit den Korrekturen erscheinen, sollten Sie aktualisieren.

Nicht die erste Lücke im Tcl-Umfeld

Schon 2015 wurde bei SektionEins eine Lücke in tcllib, der Standardbibliothek von Tcl, gefunden und veröffentlicht: Die Funktion html::textarea übernahm Formulareingaben ungefiltert in die HTML-Ausgabe. Jede Anwendung, die sie nutzte, war damit anfällig für Cross-Site-Scripting. Vier Wochen nach der Meldung war die Lücke behoben (Advisory 01/2015).

Gemeldet wurde damals wie heute im öffentlichen Ticketsystem des Tcl-Projekts, denn einen vertraulichen Meldeweg für Sicherheitslücken gibt es dort nicht. Die Entwickler haben auch diesmal schnell reagiert. Was fehlt, ist ein Hinweis in den Release Notes, dass es um Sicherheitskorrekturen geht. Ohne ihn haben die Maintainer der Linux-Distributionen wenig Grund, die Updates bevorzugt auszuliefern.

Fazit

Tcl ist seit fast 40 Jahren im Einsatz und tut in vielen Systemen unauffällig seinen Dienst. Die ungeprüfte Sprachangabe stand seit 2016 im Code, ohne dass es jemandem auffiel. Wer Safe-Interpreter einsetzt, sollte jetzt prüfen, ob der Code in der Sandbox clock wirklich braucht.

Alle Details, die betroffenen Versionen und Workarounds stehen im Advisory: Advisory 01/2026: Tcl safe-interpreter escapes via clock locale and time zone names

---

Dieser Artikel wurde am 3. November 2026 auch auf LinkedIn veröffentlicht.