iTerm2 anuncia una actualización de seguridad crítica

• iTerm2 3.5.11 es una versión compilada el 2 de enero de 2025, y se recomienda actualizar de inmediato por una corrección de seguridad crítica relacionada con la integración SSH
• El alcance del impacto incluye a usuarios de las versiones 3.5.6 a 3.5.10 que usen la función de integración SSH, y a usuarios de todas las versiones beta posteriores a 3.5.6
• Cuando ocurre el bug, la entrada y la salida se registran en /tmp/framer.txt en el host remoto, y otros usuarios del mismo host remoto pueden leer este archivo
• Las condiciones son usar it2ssh, o que en el perfil Command esté configurado como "SSH" y esté seleccionada "SSH Integration"; además, debe haber Python 3.7 o superior en la ruta de búsqueda predeterminada del host remoto
• Los usuarios deben actualizar a 3.5.11 y luego eliminar /tmp/framer.txt en los hosts remotos afectados

---

Alcance del impacto y condiciones de aparición

• iTerm2 3.5.11 es una versión que incluye una corrección de seguridad crítica, por lo que se recomienda actualizar de inmediato
• Las versiones que pueden verse afectadas son las siguientes cuando se usa la función de integración SSH
  • 3.5.6
  • 3.5.7
  • 3.5.8
  • 3.5.9
  • 3.5.10
  • Todas las versiones beta posteriores a 3.5.6
• El bug hace que la función de integración SSH registre la entrada y salida en /tmp/framer.txt en el host remoto
  • Este archivo podría ser leído por otros usuarios del host remoto
• El problema ocurre cuando se cumplen todas las condiciones siguientes
  • Se usa el comando it2ssh
  • O bien, en Settings > Profiles > General, el menú emergente Command está configurado como "SSH" y, en el cuadro de diálogo de configuración de SSH, está seleccionada "SSH Integration"
    • Las opciones "Login Shell", "Command" y "Custom Command" no están incluidas en esta condición
  • El host remoto tiene instalado Python 3.7 o superior en su ruta de búsqueda predeterminada

Actualización y verificación

• Los usuarios deben actualizar de inmediato a iTerm2 3.5.11
• En los hosts remotos afectados, se debe eliminar el archivo /tmp/framer.txt
• Se eliminó el código que escribía archivos de log en la integración SSH, y no volverá a publicarse en una versión pública
• El valor SHA-256 del archivo zip es el siguiente
  • 655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
• Para verificar el archivo zip, se puede usar https://keybase.io/verify

[xguru]

Al revisarlo por curiosidad me sorprendió: mi versión es la 3.4.3. Últimamente casi no uso la terminal y, como no le presto atención, tampoco actualizo bien.

[GN⁺]

Opiniones en Hacker News

• Parece un caso de depuración con print() que terminó en producción
  https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
  https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...

  • El código en sí no es extraño; está hecho para escribir en el archivo solo cuando está activado el modo verbose
    El commit que apaga el modo verbose es este, justo antes de eliminar por completo el log de framer: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
    El commit que activa el modo VERBOSE es este: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
    Probablemente durante la implementación o la depuración lo cambiaron a VERBOSE=1 y olvidaron regresarlo a VERBOSE=0 antes de hacer el commit
  • En desarrollo con TypeScript hacemos que console.log sea un error de lint para que no se pueda hacer merge, y cuando de vez en cuando hay una necesidad legítima usamos console.info
    La depuración con print en sí está bien y a veces sirve, pero conviene poner salvaguardas para no dejarla por accidente. Es un error realmente fácil de cometer
  • ¿Esto estuvo ahí durante 3 años?

• Que por un bug en la función SSH integration la entrada y la salida se hayan registrado en el archivo /tmp/framer.txt del host remoto, y que otros usuarios de ese host remoto pudieran leer ese archivo, es bastante grave
  Incluso podría haber archivos así en máquinas a las que uno se conectó por SSH en el pasado pero a las que ya no tiene acceso

  • Para que ocurriera, debían cumplirse ambas condiciones
    1. Haber usado el comando it2ssh, o tener el menú emergente Command en Settings > Profiles > General configurado como "SSH" y marcada la opción "SSH Integration". "Login Shell", "Command" y "Custom Command" no aplican
    2. El host remoto debía tener Python 3.7 o superior instalado en la ruta de búsqueda predeterminada
  • Parece muy poco probable que este bug afecte a mucha gente. Es una función muy específica, al punto de que el 99% de los que están aquí probablemente ni la conocen ni la han usado
    Aun así, si eres del tipo que usa ssh como comando predeterminado del terminal en vez de bash o zsh, probablemente también uses muchas funciones poco comunes en otras apps, así que no solo deberías preocuparte por iTerm sino también por otras superficies de ataque

• He usado iTerm2 durante mucho tiempo para trabajo y uso personal, y pienso seguir usándolo y volver a donar como hice antes

• Cuando veo frases como “Lamento profundamente este error y tomaré medidas para asegurarme de que no vuelva a ocurrir”, siempre suelto un pequeño suspiro
  La clave es qué medidas, pero ni siquiera tengo claro qué habría que hacer para impedir que algo así vuelva a pasar. Se podría crear una herramienta automatizada que ejecute todas las funciones y capture las llamadas al sistema para verificar que no abre ni escribe archivos, pero en una app GUI eso parece tan difícil que probablemente ni lo intentaría. Con medidas menores, me cuesta sentir que realmente se pueda garantizar que no vuelva a suceder

  • Se ha invertido muchísimo dinero en el fuzzing de Chrome/Chromium, y aun así cada año siguen apareciendo decenas de vulnerabilidades graves. Lo mismo pasa con otros productos importantes
    Siendo realistas, parece difícil que los programadores puedan hacerlo mucho mejor que eso, y si es así, no sería justo cargarle toda la responsabilidad a una sola persona
  • Por lo corta que es la nota de seguridad, parece que el autor quiso publicar cuanto antes los detalles relacionados con el incidente
    Aun así, no creo que haberla escrito breve signifique que no entienda la gravedad del error. De todos modos, esperaría que más adelante salga una entrada de blog en profundidad tratando este tipo de detalles posteriores
  • Esa frase es, a la vez, lo menos malo que se puede decir y también lo mejor que se puede decir
    No pedir disculpas sería peor, y no decir que se tomarán medidas para evitar que se repita también sería peor. Si ya tuvieran listas todas las medidas en este momento, hasta sería extraño. Primero hay que A) corregir el bug, B) distribuir la versión corregida, C) avisar del bug y del lanzamiento de la corrección, y luego D) hacer el análisis posterior; mezclar todo eso haría que el proceso pareciera desordenado
    También sería raro afirmar que se puede impedir cualquier bug o cualquier escritura involuntaria en archivos. Es imposible demostrar que nunca se escribirá en un archivo
    Un buen punto de partida es eliminar el registro SSH, como efectivamente se hizo, e investigar métodos automatizados para verificar si hay acceso a archivos. En desarrollo para macOS hay muchas herramientas bastante más avanzadas que las herramientas comunes del ecosistema, así que quizá haya formas como documentación técnica de los años 90 para especificar el NSArray de rutas permitidas de acceso, o la integración incorporada de dtrace en Instruments. Si eso se corre en CI y se consigue cobertura de pruebas, probablemente sea lo más cercano a hacer lo mejor posible
    Parece que el punto de discusión es si se lee “tomaré medidas para asegurarme de que no vuelva a ocurrir” como “tomaré medidas hasta poder garantizar al 100% que jamás volverá a pasar”. Para la gente joven e influenciable: esta entrada de blog es excelente y casi no hay manera de hacerlo mejor desde aquí
  • Si eres ingeniero de software, estas cosas siguen pasando sin importar la escala. Al final vas a cometer errores
    La medida que sí puedes tomar es usar esto como lección para ser más cuidadoso cuando vuelvas a entrar en ese tipo de ruta
  • En otro comentario mencionaron usar un linter para impedir que se haga merge a un PR si tiene console.log, y yo probablemente elegiría exactamente ese enfoque
    Es un principio bastante útil evitar que puedan existir estados no válidos

• En general será cuestión de preferencia personal, pero ¿hay alguna razón realmente convincente para usar iTerm2 en 2025 en vez de la Terminal predeterminada de macOS?
  Me lo han recomendado mucho, pero me preocupaban temas de seguridad y privacidad como este bug de SSH, así que dudaba en usarlo

  • Para mí, la función clave es Edit > Selection Respects Soft Boundaries. Permite copiar texto dentro de paneles definidos dentro de la terminal, por ejemplo divisiones de tmux o emacs, y iTerm reconoce cosas como el carácter de tubería como límite de panel
    Otra es que, si cierras una pestaña o ventana por accidente, puedes presionar ⌘z en unos segundos y la ventana reaparece como si nunca la hubieras cerrado
    Y también está el contraste mínimo de color. Si el tema de colores de la terminal y el tema de colores del programa en ejecución se mezclan mal y dejan el texto ilegible, iTerm puede detectarlo y sobrescribirlo automáticamente con colores de mayor contraste
    Pero esas solo son mis funciones clave. iTerm es un monstruo enorme y recargado con miles de funciones, como Word. No todo el mundo necesita todas, pero tampoco hay consenso sobre cuáles son las necesarias
  • Iba a preguntar si Terminal no ha tenido nunca problemas de seguridad, pero intenté encontrar una página de notas de versión y no pude
    También busqué terminal en varias notas de versión de macOS y no encontré nada. ¿Alguien sabe dónde se publica esa información? ¿O no se publica?
    [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
  • La única razón por la que me cambié a iTerm2 fue porque quería que los colores de la terminal cambiaran al conectarme por SSH a otros hosts
    Quería que al hacer SSH a una máquina del trabajo se pusiera azul, y a una de casa se pusiera morado. Intenté hacerlo en la Terminal predeterminada, pero había confusiones según cómo terminara la sesión, y la gente me recomendó iTerm2 porque resolvía eso. Al menos en mi caso, sí lo resolvió
  • Llevo años usando Kitty(https://sw.kovidgoyal.net/kitty) como principal y va excelente junto con tmux
    También he oído mucho que https://ghostty.org/ es bueno, pero todavía no he podido probarlo
    Por cierto, leí mal la pregunta como si fuera “¿qué alternativas hay?”
  • Al final depende de cuánto tiempo lleves usando macOS y de qué pequeños hábitos y rarezas hayas adquirido
    Para mí, solo poder usar un modo de pantalla completa distinto al nativo de macOS ya vale la pena. Aunque quizá en todo el mundo solo haya como siete personas a las que eso les importe

• Siento mucha empatía por el desarrollador que mantiene iTerm con un presupuesto relativamente modesto. Ya había recibido más críticas de las necesarias por la integración de IA
  Al mismo tiempo, ahora me preocupa bastante si seguir usando iTerm
  Al conectarte a entornos de HPC, puede que solo tengas acceso por un periodo corto, que debas limpiar los datos tú mismo después de usarlos y que se espere que no haya filtración de datos. Si en el último año hubiera usado la integración SSH de iTerm mientras trabajaba con datos de investigación personal, habría quedado en una situación complicada. Tal vez habría tenido que mandar un correo incómodo al administrador pidiéndole que revisara si había logs, si eran míos, y luego anunciar que hubo una filtración de datos
  Uso algunas funciones avanzadas, pero ahora me pregunto si debería usar algo más que las funciones básicas. Si no, quizá mejor usar otra terminal. Incluyendo Ghostty, todavía no he encontrado una terminal multiplataforma que se sienta tan nativa en macOS como iTerm

  • Recomiendo muchísimo wezterm
  • ¿De verdad hay motivo para cambiar de terminal porque hubo un problema en todo el larguísimo tiempo que ha existido?
    Es como tirar el coche porque se ponchó una llanta una vez. Considerando sus ventajas y funciones, iTerm quizá siga siendo la mejor opción
  • Si eres investigador, mantener un entorno de cómputo seguro no es responsabilidad individual
    Si una persona tiene que verificar por sí misma la seguridad de todo el sistema y de todo el software que usa, entonces esa organización no tiene seguridad
    Un administrador de sistemas competente y con conocimientos de seguridad puede configurar fácilmente que los archivos creados al conectarse por SSH no tengan por defecto permisos de lectura para todo el mundo. También puede poner otros mecanismos de aislamiento total para los archivos de los usuarios, e incluso desactivar por completo carpetas globalmente escribibles como /tmp/
    Si alguien critica a otra persona por usar software con fallas de seguridad, habría que preguntarle por qué sus sistemas son tan vulnerables a eso
  • Uso Prompt de Panic

• Hace unos años reporté que iTerm2 filtraba historial de búsqueda sensible en archivos de configuración, y ese problema se corrigió rápidamente
  Pero incluso ahora todavía se puede encontrar gente que filtra sin querer su historial de búsqueda en repositorios públicos de dotfiles
  [1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
  [2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...

• La sugerencia de “simplemente no usar iTerm2” no me termina de cuadrar
  Este tipo de problema puede pasar en cualquier proyecto, y cambiar de herramienta no ofrece una protección significativa. De hecho, muchas veces las prácticas de seguridad se fortalecen después de un incidente así. Se parece al viejo chiste de si despedirías al ingeniero que cometió el error, y el gerente responde: “¿Por qué lo despediría? Acaba de aprender una lección que no va a olvidar”
  Viendo el historial de iTerm2, no parece que haya tenido problemas de seguridad críticos con frecuencia, ni que vaya a repetir el mismo error. Si se repite, entonces se puede reevaluar en ese momento
  La app Terminal de macOS puede parecer de menor riesgo por ser más simple y actualizarse con menos frecuencia. Pero al ser de código cerrado, no se puede auditar, y eso también implica su propio riesgo. Al final, todas las herramientas tienen trade-offs, y hay que elegirlas equilibrando las funciones que necesitas con los riesgos potenciales

  • ¿Crees que las prácticas de desarrollo influyen en la tasa de aparición de bugs de seguridad? ¿Y crees que el historial pasado refleja esa tasa?
    Mucha gente sostiene esas dos creencias de forma razonable. Es una postura mucho más matizada que decir “todos los proyectos pueden tener bugs”. Esa visión en blanco y negro no ayuda mucho a evaluar riesgos

• iTerm2 se ha vuelto cada vez demasiado complejo y recargado, y además parece tener demasiados problemas de seguridad
  Llevo tiempo pensando en buscar un nuevo emulador de terminal para macOS, pero ahora sí parece que llegó el momento
  Como GNU Screen también parece estancado, creo que ya va siendo hora de dejar de posponer el cambio a tmux

  • Probé Ghostty hace poco y desde entonces dejé iTerm2 por completo. Se siente familiar y está muy bien logrado
  • “Demasiado complejo” y “recargado” son expresiones comodín, así que haría falta explicarlas con más detalle
    En lo personal, no siento que iTerm2 encaje en ninguna de las dos
  • Uso bastante la integración con tmux de iTerm2. Hace que el scroll con el mouse funcione de forma natural en las ventanas de tmux
    Todavía no he visto otra terminal que ofrezca soporte para tmux al mismo nivel
  • He usado Terminal.app desde la 10.0 y nunca he sentido la necesidad de reemplazarla
    ¿Qué le falta a Terminal como para que usar otra app mejore el uso diario?
  • ¿Todavía usas GNU Screen? Tanto GNU Screen como tmux han tenido problemas de seguridad en el pasado, pero los de GNU Screen fueron peores, y por eso yo me cambié
    Zellij es un multiplexor de terminal hecho en Rust que vale la pena revisar. En especial, me gusta mucho que permita descubrir fácilmente los atajos de teclado. Se acerca bastante a lo que siempre quise en una TUI

• ¿Esto aplica solo a la integración SSH, y no al caso de simplemente ejecutar "ssh" en iTerm?
  No encontré el archivo /tmp/framer.txt en los hosts a los que me conecté usando ssh normal

  • Por las notas de la versión, parece que esto solo aplicaba cuando se usaba la integración SSH incorporada y cuando el servidor tenía una versión relativamente reciente de Python
    Esa segunda condición probablemente también se cumple en la mayoría de las distribuciones empresariales. Por ejemplo, RHEL 9 trae Python 3.9 instalado por defecto