iTerm2 veröffentlicht wichtiges Sicherheitsupdate

(iterm2.com)

2 Punkte von GN⁺ 2025-01-03 | 2 Kommentare | Auf WhatsApp teilen

iTerm2 3.5.11 ist ein am 2. Januar 2025 gebautes Release; wegen eines wichtigen Sicherheitsfixes im Zusammenhang mit der SSH-Integration wird ein sofortiges Update empfohlen
Betroffen sind Nutzer der Versionen 3.5.6 bis 3.5.10 mit aktivierter SSH-Integration sowie Nutzer aller Beta-Versionen nach 3.5.6
Tritt der Bug auf, werden Eingaben und Ausgaben auf dem Remote-Host in /tmp/framer.txt protokolliert; andere Nutzer desselben Remote-Hosts können diese Datei lesen
Voraussetzung ist die Nutzung von it2ssh oder ein Profil, in dem Command auf "SSH" gesetzt und "SSH Integration" ausgewählt ist; außerdem muss im Standardsuchpfad des Remote-Hosts Python 3.7 oder höher vorhanden sein
Nutzer sollten auf 3.5.11 upgraden und anschließend auf betroffenen Remote-Hosts /tmp/framer.txt löschen

Betroffene Versionen und Voraussetzungen

iTerm2 3.5.11 ist ein Release mit einem wichtigen Sicherheitsfix; ein sofortiges Update wird empfohlen
Potenziell betroffen sind die folgenden Versionen, wenn die SSH-Integration genutzt wird
- 3.5.6
- 3.5.7
- 3.5.8
- 3.5.9
- 3.5.10
- alle Beta-Versionen nach 3.5.6
Der Bug führt dazu, dass die SSH-Integration Eingaben und Ausgaben auf dem Remote-Host in /tmp/framer.txt schreibt
- Diese Datei kann möglicherweise von anderen Nutzern des Remote-Hosts gelesen werden
Das Problem tritt auf, wenn alle folgenden Bedingungen erfüllt sind
- Der Befehl it2ssh wird verwendet
- Oder in Settings > Profiles > General ist das Command-Popup-Menü auf "SSH" gesetzt und im SSH-Einstellungsdialog ist "SSH Integration" ausgewählt
  - Die Einstellungen "Login Shell", "Command" und "Custom Command" fallen nicht unter diese Bedingung
- Im Standardsuchpfad des Remote-Hosts ist Python 3.7 oder höher installiert

Update und Verifizierung

Nutzer sollten umgehend auf iTerm2 3.5.11 upgraden
Auf betroffenen Remote-Hosts sollte die Datei /tmp/framer.txt gelöscht werden
Der Code, der in der SSH-Integration Logdateien schreibt, wurde entfernt und soll nicht erneut in einem öffentlichen Release erscheinen
Der SHA-256-Wert der ZIP-Datei lautet wie folgt
- 655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
Zur Verifizierung der ZIP-Datei kann https://keybase.io/verify verwendet werden

2 Kommentare

xguru 2025-01-03

Als ich es gerade überprüft habe, ist meine Version 3.4.3. Ich nutze den Terminal in letzter Zeit kaum noch, deshalb habe ich auch nicht wirklich darauf geachtet und die Updates werden deshalb kaum eingespielt.

GN⁺ 2025-01-03

Meinungen auf Hacker News

Sieht aus wie ein Fall von print()-Debugging in der Produktion
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...
- Der Code selbst ist nicht merkwürdig; er schreibt nur in eine Datei, wenn der verbose mode aktiviert ist
  Der Commit, der den verbose mode deaktiviert hat, ist dieser hier, unmittelbar bevor das gesamte framer-Log entfernt wurde: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
  Der Commit, der den VERBOSE-Modus aktiviert hat, ist dieser hier: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
  Vermutlich wurde während der Implementierung oder beim Debugging auf VERBOSE=1 umgestellt und vor dem Commit vergessen, es wieder auf VERBOSE=0 zurückzusetzen
- In der TypeScript-Entwicklung haben wir console.log als Lint-Fehler definiert, sodass damit nicht gemergt werden kann; wenn es gelegentlich einen berechtigten Bedarf gibt, verwenden wir console.info
  Print-Debugging an sich ist in Ordnung und hat seine Berechtigung, aber es ist gut, Schutzmechanismen zu haben, damit man es nicht versehentlich drinlässt. Das ist ein wirklich leicht zu machender Fehler
- War das wirklich drei Jahre lang drin?
Dass wegen eines Bugs in der Funktion SSH integration Ein- und Ausgabe in die Datei /tmp/framer.txt auf dem Remote-Host geschrieben wurden und diese Datei von anderen Nutzern des Remote-Hosts gelesen werden konnte, ist ziemlich gravierend
Solche Dateien könnten auch auf Maschinen zurückgeblieben sein, auf die man früher per SSH zugegriffen hat, auf die man inzwischen aber keine Zugriffsrechte mehr hat
- Es müssen beide Bedingungen erfüllt sein
  1. Man hat den Befehl it2ssh verwendet, oder im Menü Settings > Profiles > General war im Command-Popup-Menü "SSH" eingestellt und "SSH Integration" aktiviert. "Login Shell", "Command" und "Custom Command" sind nicht betroffen
  2. Auf dem Remote-Host muss Python 3.7 oder neuer im Standard-Suchpfad installiert sein
- Dieser Bug dürfte kaum auftreten. Denn es handelt sich um eine sehr spezielle Funktion, von der 99 % hier wahrscheinlich noch nie gehört haben, geschweige denn sie genutzt haben
  Wer allerdings statt bash oder zsh ssh als Standard-Terminalbefehl verwendet, nutzt wahrscheinlich auch in anderen Apps viele ungewöhnliche Funktionen und sollte deshalb nicht nur bei iTerm, sondern auch bei anderen Angriffsflächen aufmerksam sein
Ich habe iTerm2 lange sowohl beruflich als auch privat gern genutzt, werde es weiterhin nutzen und habe vor, wie früher wieder zu spenden
Wenn ich Sätze lese wie „Ich bedauere diesen Fehler zutiefst und werde Maßnahmen ergreifen, damit so etwas nie wieder passiert“, muss ich immer ein bisschen seufzen
Entscheidend ist, welche Maßnahmen gemeint sind, aber ich weiß auch nicht recht, was man tun müsste, um zu verhindern, dass so etwas wieder passiert. Man könnte vielleicht ein automatisiertes Tool bauen, das alle Funktionen ausführt, System Calls mitschneidet und prüft, ob Dateien geöffnet oder beschrieben werden; bei einer GUI-App wirkt das aber so schwierig, dass man es vermutlich gar nicht erst versuchen würde. Mit weniger weitreichenden Maßnahmen fühlt es sich schwer an, zu garantieren, dass es nicht wieder vorkommt
- In das Fuzzing von Chrome/Chromium ist enorm viel Geld geflossen, trotzdem werden jedes Jahr weiterhin dutzende schwerwiegende Sicherheitslücken gefunden. Bei anderen großen Produkten ist es genauso
  Realistisch betrachtet ist es schwer vorstellbar, dass ein Programmierer sehr viel besser sein kann als das; deshalb ist es unfair, dieser einen Person die gesamte Verantwortung aufzubürden
- Weil die Sicherheitsmeldung kurz ist, scheint der Autor die Details zum Vorfall so schnell wie möglich veröffentlichen zu wollen
  Ich denke aber nicht, dass die Kürze bedeutet, dass er das Ausmaß des Fehlers nicht versteht. Trotzdem würde ich erwarten, dass später noch ein ausführlicher Blogbeitrag mit solchen nachgelagerten Details erscheint
- Dieser Satz ist das am wenigsten Schlechte, was man sagen kann, und zugleich auch das Beste
  Sich nicht zu entschuldigen wäre schlimmer, und nicht zu sagen, dass man Maßnahmen gegen eine Wiederholung ergreifen wird, wäre ebenfalls schlimmer. Wenn jetzt schon alle Maßnahmen fertig wären, wäre das eher merkwürdig. Zuerst sollte man A) den Bug beheben, B) den Fix ausliefern, C) über den Bug und die Auslieferung des Fixes informieren und D) eine Postmortem-Analyse durchführen; vermischt man das alles, wirkt es wie ein prozessual unsauberer Ansatz
  Es wäre auch merkwürdig zu behaupten, man könne alle Bugs oder jedes unbeabsichtigte Schreiben von Dateien verhindern. Zu beweisen, dass niemals in Dateien geschrieben wird, ist unmöglich
  Ein guter Ausgangspunkt ist, wie offenbar tatsächlich geschehen, das SSH-Logging zu entfernen und automatisierte Methoden zu untersuchen, um Dateizugriffe zu verifizieren. In der macOS-Entwicklung gibt es viele Werkzeuge, die dem allgemeinen Ökosystem weit voraus sind; vielleicht gibt es etwa Methoden wie technische Dokumentation aus den 1990ern, in der man ein NSArray erlaubter Zugriffspfade angibt, oder die eingebaute dtrace-Integration in Instruments. Wenn man das in CI ausführt und Testabdeckung sicherstellt, kommt man dem Bestmöglichen nahe
  Der Knackpunkt scheint zu sein, ob man „Ich werde Maßnahmen ergreifen, damit so etwas nie wieder passiert“ als „Ich werde so lange Maßnahmen ergreifen, bis ich absolut, zu 100 % und für immer garantieren kann, dass es nie wieder passiert“ liest. An junge und leicht beeinflussbare Menschen gerichtet: Dieser Blogbeitrag ist hervorragend, und viel besser kann man es hier kaum machen
- Als Software Engineer wird so etwas unabhängig von der Größenordnung immer wieder passieren. Am Ende macht man Fehler
  Was man tun kann, ist, daraus zu lernen und an dieser Stelle künftig vorsichtiger zu sein
- In einem anderen Kommentar wurde der Ansatz erwähnt, einen Linter zu verwenden, der verhindert, dass PRs mit console.log gemergt werden; genau diesen Ansatz würde ich wohl auch wählen
  Zu verhindern, dass ungültige Zustände überhaupt existieren können, ist ein ziemlich nützliches Prinzip
Es ist wohl größtenteils Geschmackssache, aber gibt es 2025 einen wirklich überzeugenden Grund, statt des macOS-Standard-Terminals iTerm2 zu verwenden?
Es wurde mir oft empfohlen, aber wegen Sicherheits- und Privacy-Themen wie diesem SSH-Bug war ich vorsichtig
- Für mich ist das zentrale Feature Edit > Selection Respects Soft Boundaries. Damit kann man Text innerhalb von im Terminal definierten Fenstern kopieren, etwa in tmux- oder emacs-Splits, und iTerm erkennt Dinge wie Pipe-Zeichen als Fenstergrenzen
  Ein weiteres ist, dass ein versehentlich geschlossener Tab oder ein Fenster wieder erscheint, als wäre es nie geschlossen worden, wenn man innerhalb weniger Sekunden ⌘z drückt
  Außerdem ist der minimale Farbkontrast gut. Wenn sich das Farbschema des Terminals und das Farbschema des laufenden Programms ungünstig mischen und dadurch unlesbar werden, kann iTerm das erkennen und automatisch mit Farben mit höherem Kontrast überschreiben
  Allerdings sind das nur meine Kernfunktionen. iTerm ist ein aufgeblähtes Monster mit Tausenden Features, wie Word. Nicht jeder braucht alles, aber es gibt auch keinen Konsens darüber, welche Features nötig sind
- Ich wollte fragen, ob Terminal wirklich keinerlei Sicherheitsprobleme hatte, habe dann aber versucht, eine Release-Notes-Seite zu finden, und konnte keine finden
  Auch in mehreren macOS-Release-Notes habe ich nach terminal gesucht, aber nichts gefunden. Weiß jemand, wo diese Informationen veröffentlicht werden? Werden sie gar nicht veröffentlicht?
  [1] https://developer.apple.com/documentation/macos-release-note...
  [2] https://support.apple.com/en-us/120283
  [3] https://support.apple.com/en-in/109035
  [4] https://support.apple.com/en-us/106337
- Der einzige Grund, warum ich zu iTerm2 gewechselt bin, war, dass ich wollte, dass sich die Terminal-Farben ändern, wenn ich per SSH auf andere Hosts zugreife
  Ich wollte, dass es blau wird, wenn ich per SSH auf die Firmenmaschine gehe, und lila, wenn ich auf die Maschine zu Hause gehe. Ich habe es auch mit dem Standard-Terminal versucht, aber je nachdem, wie die Session beendet wurde, gab es verwirrende Probleme, und Leute empfahlen mir iTerm2, weil es das löse. Zumindest bei mir hat es das tatsächlich gelöst
- Ich nutze seit Jahren hauptsächlich Kitty (https://sw.kovidgoyal.net/kitty), und zusammen mit tmux ist es großartig
  Über https://ghostty.org/ habe ich auch viel Gutes gehört, es aber noch nicht ausprobiert
  Nebenbei: Ich habe die Frage fälschlicherweise als „Welche Alternativen gibt es?“ gelesen
- Am Ende hängt es davon ab, wie lange man macOS schon nutzt und welche kleinen Gewohnheiten und Eigenheiten man entwickelt hat
  Für mich ist es schon wertvoll, einen anderen Vollbildmodus als den nativen macOS-Vollbildmodus nutzen zu können. Allerdings gibt es weltweit vielleicht nur etwa sieben Leute, denen das wichtig ist
Ich habe großes Mitgefühl mit dem Entwickler, der iTerm mit vergleichsweise wenig Geld entwickelt. Wegen der AI-Integration hat er bereits mehr Kritik abbekommen als nötig
Gleichzeitig mache ich mir jetzt große Sorgen, ob ich iTerm weiterverwenden kann
Wenn man auf HPC-Umgebungen zugreift, hat man unter Umständen nur für kurze Zeit Zugriff, muss die Daten nach der Nutzung selbst bereinigen und erwartet, dass keine Daten abfließen. Wenn ich im vergangenen Jahr mit personenbezogenen Forschungsdaten gearbeitet und dabei die SSH-Integration von iTerm genutzt hätte, wäre das problematisch geworden. Ich hätte vielleicht peinliche E-Mails an Admins schreiben müssen, um zu prüfen, ob es Logs gibt und ob sie von mir stammen, und anschließend öffentlich machen müssen, dass Daten abgeflossen sind
Ich nutze zwar auch einige fortgeschrittene Features, frage mich jetzt aber, ob ich überhaupt mehr als die Grundfunktionen nutzen sollte. Dann könnte ich genauso gut ein anderes Terminal verwenden. Einschließlich Ghostty habe ich noch kein Cross-Platform-Terminal gefunden, das sich unter MacOS so nativ anfühlt wie iTerm
- Ich kann wezterm wärmstens empfehlen
- Ist ein einzelnes Issue in der langen Zeit, die es bisher existiert, wirklich ein Grund, zu einem anderen Terminal zu wechseln?
  Das ist ein bisschen so, als würde man ein Auto wegwerfen, weil einmal ein Reifen geplatzt ist. Angesichts seiner Vorteile und Features ist iTerm vielleicht weiterhin die beste Wahl
- Als Forschender ist es nicht deine persönliche Verantwortung, eine sichere Computing-Umgebung aufrechtzuerhalten
  Wenn Einzelpersonen die Sicherheit des gesamten Systems und jeder verwendeten Software selbst überprüfen müssten, dann hätte diese Organisation keine Sicherheit
  Ein kompetenter Systemadministrator mit Sicherheitskenntnissen kann leicht dafür sorgen, dass Dateien, die über SSH angelegt werden, nicht standardmäßig für alle lesbar sind. Es lassen sich auch andere Sperren einrichten, um Benutzerdateien vollständig zu isolieren, und global beschreibbare Ordner wie /tmp/ können sogar ganz deaktiviert werden
  Wenn jemand einem vorwirft, unsichere Software benutzt zu haben, sollte man zurückfragen, warum deren System so sicherheitsanfällig ist
- Ich nutze Prompt von Panic
Vor einigen Jahren habe ich ein Problem gemeldet, bei dem iTerm2 sensible Suchverläufe in die Konfigurationsdatei leakte, und dieses Problem wurde schnell behoben
Aber auch heute findet man noch Leute, die in öffentlichen dotfiles-Repositories ihren Suchverlauf unbeabsichtigt offenlegen
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
Der Vorschlag „einfach iTerm2 nicht verwenden“ leuchtet mir nicht ganz ein
Probleme dieser Art können in jedem Projekt auftreten, und ein Wechsel des Tools bietet keinen nennenswerten Schutz. Im Gegenteil: Nach solchen Vorfällen werden Sicherheitspraktiken oft eher verschärft. Das erinnert an den alten Witz, ob man den Engineer feuern würde, der einen Fehler gemacht hat, worauf der Manager antwortet: „Warum sollte ich ihn feuern? Er hat gerade eine Lektion gelernt, die er nie vergessen wird.“
Wenn man sich die Historie von iTerm2 ansieht, scheint es nicht so, als hätte es häufig kritische Sicherheitsprobleme gegeben, und es wirkt auch nicht wahrscheinlich, dass derselbe Fehler wiederholt wird. Falls doch, kann man es dann neu bewerten
Die macOS-App Terminal ist einfacher und wird seltener aktualisiert, was wie ein geringeres Risiko wirken kann. Aber sie ist Closed Source, lässt sich also nicht auditieren, und das bringt eigene Risiken mit sich. Am Ende hat jedes Tool Trade-offs, und man sollte anhand der Balance zwischen benötigten Funktionen und potenziellen Risiken wählen
- Glaubst du, dass Entwicklungspraktiken die Häufigkeit von Sicherheitsbugs beeinflussen? Und glaubst du, dass die bisherige Historie diese Häufigkeit von Sicherheitsbugs widerspiegelt?
  Viele Menschen halten beides für vernünftige Annahmen. Das ist eine deutlich nuanciertere Sicht als „jedes Projekt kann Bugs haben“. Eine solche Schwarz-Weiß-Sicht hilft bei der Risikobewertung kaum weiter
iTerm2 ist zunehmend zu komplex und aufgebläht geworden, und es scheint auch zu viele Sicherheitsprobleme zu geben
Ich habe mich schon lange nicht mehr nach einem neuen Terminal-Emulator für macOS umgesehen, aber jetzt scheint der Zeitpunkt gekommen zu sein
GNU Screen wirkt ebenfalls stehen geblieben, also sollte ich den aufgeschobenen Umstieg auf tmux wohl endlich angehen
- Ich habe kürzlich Ghostty ausprobiert und bin danach vollständig von iTerm2 gewechselt. Es fühlt sich vertraut an und ist zugleich sehr ausgereift
- „Zu komplex“ und „aufgebläht“ sind Allzweckformulierungen; man müsste das etwas konkreter ausführen
  Persönlich habe ich nicht das Gefühl, dass iTerm2 auf eines von beidem zutrifft
- Ich nutze die tmux-Integration von iTerm2 ziemlich häufig. Sie sorgt dafür, dass Mausrad-Scrollen in tmux-Fenstern natürlich funktioniert
  Ich habe bisher kein anderes Terminal gesehen, das tmux auf demselben Niveau unterstützt
- Ich nutze Terminal.app seit 10.0 und hatte nie das Gefühl, es ersetzen zu müssen
  Was fehlt Terminal, sodass eine andere App den Alltag spürbar verbessern würde?
- Nutzt du immer noch GNU Screen? Sowohl GNU Screen als auch tmux hatten in der Vergangenheit Sicherheitsprobleme, aber bei GNU Screen war es schlimmer, deshalb bin ich gewechselt
  Zellij ist ein in Rust geschriebener Terminal-Multiplexer und einen Blick wert. Besonders gut ist, dass sich die Key Bindings leicht entdecken lassen. Es kommt dem nahe, was ich mir für eine TUI erträumt habe
Gilt das nur für die SSH-Integration und nicht für den Fall, dass man in iTerm einfach "ssh" ausführt?
Auf den Hosts, mit denen ich per normalem ssh verbunden war, konnte ich keine Datei /tmp/framer.txt finden
- Den Release Notes nach zu urteilen scheint es nur zuzutreffen, wenn man die eingebaute SSH-Integration nutzt und auf dem Server eine vergleichsweise aktuelle Python-Version vorhanden ist
  Letztere Bedingung dürfte auch bei Enterprise-Distributionen meist erfüllt sein. RHEL 9 bringt zum Beispiel standardmäßig Python 3.9 mit