iTerm2 publie une mise à jour de sécurité critique
(iterm2.com)- iTerm2 3.5.11 est une version buildée le 2 janvier 2025, dont la mise à jour immédiate est recommandée en raison d’un correctif de sécurité critique lié à l’intégration SSH
- Le périmètre concerné couvre les utilisateurs des versions 3.5.6 à 3.5.10 ayant utilisé la fonctionnalité d’intégration SSH, ainsi que toutes les versions bêta postérieures à 3.5.6
- Lorsque le bug se produit, les entrées et sorties sont enregistrées dans /tmp/framer.txt sur l’hôte distant, et d’autres utilisateurs du même hôte distant peuvent lire ce fichier
- Les conditions sont l’utilisation de
it2ssh, ou un profil dont Command est"SSH"avec"SSH Integration"sélectionné, et la présence de Python 3.7 ou ultérieur dans le chemin de recherche par défaut de l’hôte distant - Les utilisateurs doivent mettre à niveau vers la version 3.5.11, puis supprimer
/tmp/framer.txtsur les hôtes distants concernés
Périmètre et conditions de déclenchement
- iTerm2 3.5.11 est une version incluant un correctif de sécurité critique, et une mise à jour immédiate est recommandée
- Les versions potentiellement affectées sont les suivantes, si la fonctionnalité d’intégration SSH a été utilisée
- 3.5.6
- 3.5.7
- 3.5.8
- 3.5.9
- 3.5.10
- Toutes les versions bêta postérieures à 3.5.6
- Le bug amène la fonctionnalité d’intégration SSH à enregistrer les entrées et sorties dans
/tmp/framer.txtsur l’hôte distant- Ce fichier peut être lisible par d’autres utilisateurs de l’hôte distant
- Le problème survient lorsque toutes les conditions suivantes sont réunies
- La commande
it2sshest utilisée - Ou, dans
Settings > Profiles > General, le menu contextuel Command est réglé sur"SSH", et"SSH Integration"est sélectionné dans la boîte de dialogue de configuration SSH- Les réglages
"Login Shell","Command"et"Custom Command"ne sont pas inclus dans cette condition
- Les réglages
- Python 3.7 ou ultérieur est installé dans le chemin de recherche par défaut de l’hôte distant
- La commande
Mise à jour et vérification
- Les utilisateurs doivent immédiatement passer à iTerm2 3.5.11
- Sur les hôtes distants concernés, le fichier
/tmp/framer.txtdoit être supprimé - Le code qui écrivait un fichier de log dans l’intégration SSH a été supprimé et ne sera pas à nouveau publié dans une version publique
- La valeur SHA-256 du fichier zip est la suivante
655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
https://keybase.io/verifypeut être utilisé pour vérifier le fichier zip
2 commentaires
J’ai été surpris de voir que ma version est la 3.4.3. Je n’utilise pas beaucoup le terminal en ce moment, donc je n’ai pas non plus pris l’habitude de le mettre à jour régulièrement.
Avis sur Hacker News
Ça ressemble à un cas de débogage avec print() arrivé en production
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...
Le commit qui a désactivé le mode verbose est celui-ci, juste avant la suppression de tout le journal framer : https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
Le commit qui a activé le mode VERBOSE est celui-ci : https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
Il a probablement mis
VERBOSE=1pendant l’implémentation ou le débogage, puis oublié de le remettre àVERBOSE=0avant de committerconsole.infoLe débogage avec print n’est pas mauvais en soi et a ses usages, mais il vaut mieux mettre des garde-fous pour éviter de le laisser par erreur. C’est vraiment une erreur très facile à faire
Le fait qu’à cause d’un bug de la fonctionnalité
SSH integration, les entrées et sorties aient été enregistrées dans un fichier/tmp/framer.txtsur l’hôte distant, et que ce fichier ait pu être lu par d’autres utilisateurs de cet hôte, est assez graveDe tels fichiers peuvent aussi être restés sur des machines auxquelles on s’est connecté en SSH par le passé, mais auxquelles on n’a plus accès aujourd’hui
it2ssh, ou avoir eu le menu déroulant Command réglé sur"SSH"dans Settings > Profiles > General, avec"SSH Integration"coché."Login Shell","Command"et"Custom Command"ne sont pas concernésCela dit, si vous êtes du genre à utiliser
sshcomme commande de terminal par défaut au lieu debashouzsh, il y a de fortes chances que vous utilisiez aussi beaucoup de fonctionnalités atypiques dans d’autres apps ; il faut donc surveiller d’autres surfaces d’attaque, pas seulement iTermJ’utilise iTerm2 depuis longtemps, aussi bien pour le travail que pour un usage personnel, et je continuerai à l’utiliser tout en refaisant un don, comme je l’ai déjà fait par le passé
Quand je lis une phrase du genre « Je regrette profondément cette erreur et prendrai des mesures pour que cela ne se reproduise plus », je pousse toujours un petit soupir
Le point essentiel, c’est quelles mesures. Et je ne sais même pas bien ce qu’il faudrait faire pour empêcher que ce genre de chose se reproduise. On pourrait créer un outil automatisé qui exécute toutes les fonctionnalités, capture les appels système et vérifie qu’aucun fichier n’est ouvert ni écrit, mais pour une app GUI ça paraît tellement difficile que je doute qu’on tente même de le faire. Avec des mesures moins ambitieuses, il semble difficile de garantir que cela ne se reproduira pas
De façon réaliste, il paraît difficile pour un programmeur de faire beaucoup mieux que ça, donc faire porter toute la responsabilité à cette seule personne serait injuste
Cela dit, je ne pense pas que le fait d’avoir écrit brièvement signifie qu’il ne comprend pas l’ampleur de l’erreur. J’attends tout de même qu’un billet de blog approfondi traitant ce type de détails de suivi paraisse plus tard
Ne pas s’excuser serait pire, et ne pas dire qu’on prendra des mesures pour éviter une récidive serait pire aussi. Si toutes les mesures étaient déjà prêtes maintenant, ce serait même étrange. Il faut d’abord A) corriger le bug, B) publier la version corrigée, C) annoncer le bug et la publication du correctif, puis D) faire une analyse post-mortem ; mélanger tout cela donnerait l’impression d’une procédure désordonnée
Il serait aussi étrange de prétendre pouvoir empêcher tous les bugs ou toutes les écritures de fichiers involontaires. Prouver qu’un programme n’écrira absolument jamais dans un fichier est impossible
Un bon point de départ est de supprimer le logging SSH, comme cela a effectivement été fait, puis d’étudier une méthode automatisée pour vérifier les accès aux fichiers. Le développement macOS dispose de nombreux outils très en avance sur les outils communs de l’écosystème : il pourrait exister des approches comme une documentation technique des années 1990 permettant de spécifier un
NSArrayde chemins d’accès autorisés, ou l’intégration dtrace intégrée à Instruments. Les exécuter en CI et obtenir une couverture de tests serait sans doute proche du mieux que l’on puisse faireLe point de débat semble être de savoir si l’on lit « je prendrai des mesures pour que cela ne se reproduise plus » comme « je prendrai des mesures jusqu’à pouvoir garantir absolument, à 100 %, pour toujours, que cela ne se reproduira jamais ». Aux personnes jeunes et influençables, je dirais que ce billet de blog est excellent et qu’il y a très peu de choses qu’il aurait pu mieux faire
La mesure possible consiste à en tirer une leçon et à être plus prudent lorsqu’on emprunte ce chemin de code
console.log, et c’est exactement l’approche que j’adopterais moi aussiEmpêcher l’existence d’états invalides est un principe assez utile
C’est sans doute surtout une question de préférence personnelle, mais en 2025, y a-t-il une raison vraiment convaincante d’utiliser iTerm2 plutôt que le Terminal par défaut de macOS ?
On me l’a souvent recommandé, mais les problèmes de sécurité et de confidentialité comme ce bug SSH m’inquiétaient, donc je restais prudent
Autre point : si je ferme accidentellement un onglet ou une fenêtre, appuyer sur ⌘z dans les quelques secondes la fait réapparaître comme si elle n’avait jamais été fermée
Et le contraste minimal des couleurs est aussi appréciable. Quand le thème de couleurs du terminal et celui du programme en cours d’exécution se combinent mal au point de rendre le texte illisible, iTerm peut le détecter et remplacer automatiquement les couleurs par d’autres offrant un contraste plus élevé
Cela dit, ce ne sont que mes fonctionnalités essentielles. iTerm est un monstre obèse avec des milliers de fonctions, à la manière de Word. Tout le monde n’a pas besoin de tout, mais il n’y a pas non plus de consensus sur les fonctions réellement nécessaires
J’ai aussi cherché
terminaldans plusieurs notes de version de macOS, sans rien trouver. Quelqu’un sait où ces informations sont publiées ? Ou bien ne le sont-elles pas ?[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
Je voulais que ce soit bleu quand je me connecte en SSH à une machine du travail, violet pour une machine à la maison. J’ai essayé de le faire avec le Terminal par défaut, mais selon la manière dont la session se terminait, ça pouvait prêter à confusion, et on m’a recommandé iTerm2 en disant qu’il réglait ce problème. En tout cas, dans mon cas, il l’a effectivement réglé
J’ai aussi entendu beaucoup de bien de https://ghostty.org/, mais je n’ai pas encore vérifié par moi-même
Au passage, j’avais lu la question de travers comme « quelles sont les alternatives ? »
Pour moi, le simple fait de pouvoir utiliser un mode plein écran différent du plein écran natif de macOS a de la valeur. Mais il n’y a peut-être que sept personnes au monde pour qui c’est important
J’ai beaucoup de sympathie pour le développeur qui maintient iTerm avec des moyens relativement modestes. Il a déjà reçu plus de critiques qu’il n’en fallait à cause de l’intégration de l’IA
En même temps, je suis maintenant très inquiet à l’idée de continuer à utiliser iTerm
Quand on accède à des environnements HPC, on peut n’avoir des droits d’accès que pour une courte période, devoir nettoyer soi-même les données après usage, et s’attendre à ce qu’il n’y ait pas de fuite. Si, au cours de l’année passée, j’avais utilisé l’intégration SSH d’iTerm en manipulant des données de recherche personnelles, cela m’aurait mis dans une situation compliquée. J’aurais peut-être dû envoyer un mail embarrassant aux admins pour leur demander de vérifier s’il existe des logs et s’ils me concernent, puis déclarer publiquement qu’il y a eu une fuite de données
J’utilise aussi certaines fonctions avancées, mais je me demande désormais s’il est raisonnable d’utiliser quoi que ce soit au-delà des fonctions de base. Dans ce cas, autant peut-être utiliser un autre terminal. Je n’ai pas encore trouvé de terminal multiplateforme qui donne une impression aussi native sur MacOS qu’iTerm, y compris Ghostty
C’est un peu comme jeter sa voiture parce qu’un pneu a crevé une fois. Vu ses avantages et ses fonctionnalités, iTerm reste peut-être le meilleur choix
Si chacun doit vérifier lui-même la sécurité de tout le système et de tous les logiciels qu’il utilise, alors cette organisation n’a pas de sécurité
Un administrateur système compétent en sécurité peut facilement configurer les choses pour que les fichiers créés via une connexion SSH ne soient pas, par défaut, lisibles par tout le monde. Il peut aussi mettre en place d’autres verrous pour isoler complètement les fichiers des utilisateurs, voire désactiver entièrement les dossiers accessibles en écriture globale comme
/tmp/Si quelqu’un vous reproche d’avoir utilisé un logiciel vulnérable, il faut lui demander pourquoi son système est aussi vulnérable
Il y a quelques années, j’ai signalé qu’iTerm2 divulguait un historique de recherche sensible dans son fichier de configuration, et le problème a été corrigé rapidement
Mais aujourd’hui encore, on peut trouver des personnes qui exposent involontairement leur historique de recherche dans des dépôts dotfiles publics
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
La suggestion « n’utilisez tout simplement pas iTerm2 » me paraît un peu incompréhensible
Ce type de problème peut survenir dans n’importe quel projet, et changer d’outil n’offre pas vraiment une protection significative. Au contraire, après ce genre d’incident, les pratiques de sécurité se renforcent souvent. C’est un peu comme cette vieille blague où l’on demande s’il faut licencier l’ingénieur qui a fait une erreur, et où le manager répond : « Pourquoi le licencier ? Il vient d’apprendre une leçon qu’il n’oubliera jamais »
Si l’on regarde l’historique d’iTerm2, il ne semble pas y avoir eu souvent de failles de sécurité critiques, et il ne semble pas non plus probable qu’ils répètent la même erreur. Si cela se reproduit, on pourra réévaluer à ce moment-là
L’app Terminal de macOS est plus simple et reçoit des mises à jour moins fréquentes, ce qui peut donner l’impression d’un risque plus faible. Mais comme son code source est fermé, il n’est pas possible de l’auditer, ce qui comporte aussi ses propres risques. Au final, tous les outils impliquent des compromis, et il faut choisir en équilibrant les fonctionnalités nécessaires et les risques potentiels
Beaucoup de gens considèrent ces deux idées comme des croyances raisonnables. C’est une position bien plus nuancée que de dire « tous les projets peuvent avoir des bugs ». Ce genre de vision en noir et blanc n’aide pas beaucoup à évaluer le risque
iTerm2 est devenu de plus en plus complexe et lourd, et il semble aussi avoir trop de problèmes de sécurité
Cela fait longtemps que je n’ai pas cherché de nouvel émulateur de terminal sur macOS, mais il semble que le moment soit venu
GNU Screen semble lui aussi stagner, donc il va falloir que je cesse de repousser le passage à tmux
Personnellement, je n’ai pas l’impression qu’iTerm2 corresponde à l’une ou l’autre
Je n’ai pas encore vu d’autre terminal offrant un support de tmux du même niveau
Qu’est-ce qui manque à Terminal au point qu’une autre app améliorerait l’usage quotidien ?
Zellij est un multiplexeur de terminal écrit en Rust, et il vaut le coup d’œil. J’apprécie particulièrement le fait que les raccourcis clavier soient faciles à découvrir. C’est proche de ce dont je rêvais pour une TUI
Cela ne concerne que l’intégration SSH, et pas le cas où l’on exécute simplement
"ssh"dans iTerm, non ?Sur les hôtes auxquels je me suis connecté avec un ssh ordinaire, je n’ai pas trouvé le fichier
/tmp/framer.txtCette dernière condition a de bonnes chances d’être vraie même dans les distributions d’entreprise. Par exemple, RHEL 9 installe Python 3.9 par défaut