An issue in iTerm2 macOS before 3.6.12 allows a local attacker to obtain sensitive information.

In iTerm2 through 3.6.9, displaying a .txt file can cause code execution via DCS 2000p and OSC 135 data, if the working directory contains a malicious file whose name is valid output from the conductor encoding path, such as a pathname with an initial ace/c+ substring, aka "hypothetical in-band signaling abuse." This occurs because iTerm2 accepts the SSH conductor protocol from terminal output that does not originate from a legitimate conductor session.

iterm2 (https://iterm2.com), a popular Terminal.app replacement for macOS, announced a vulnerability in versions < 3.5.11 whereby input/output from an SSH connection may be logged to the file /tmp/framer.txt on the remote host. To the best of my knowledge, there is no CVE associated with this vulnerability.

The announcement (below) notes that this file "may be readable by other users", presumably depending on the user's umask on that system.

iterm2 is published under the GPL with source code available here: https://github.com/gnachman/iTerm2

Announcement and change log: https://iterm2.com/downloads/stable/iTerm2-3511.changelog

---

Version 3.5.11 of iTerm2 was built on January 2, 2025.

This release contains a critical security fix. I strongly recommend updating immediately.

Who is affected? ---------------- You may be affected if you used the SSH integration feature in any of the following versions:

3.5.6 3.5.7 3.5.8 3.5.9 3.5.10 Any beta versions of 3.5.6 and later.

What is the issue? ------------------ A bug in the SSH integration feature caused input and output to be logged to a file on the remote host. This file, /tmp/framer.txt, may be readable by other users on the remote host.

When does this occur? --------------------- The issue occurs if both of the following conditions are true:

1. Either: a) You used the it2ssh command, or b) In Settings > Profiles > General, the Command popup menu was set to "SSH" (not "Login Shell", "Command", or "Custom Command") AND "SSH Integration" was checked in the SSH configuration dialog. That dialog is shown when you click the Configure button next to the ssh arguments field in Settings. 2. The remote host has Python 3.7 or later installed in its default search path.

What should you do? ------------------- Upgrade immediately to version 3.5.11. Delete /tmp/framer.txt on affected hosts.

How I'm addressing this ----------------------- I deeply regret this mistake and will take steps to ensure it never happens again.

The code to write to log files in SSH integration has been deleted and will not be publicly released again.

If you have questions you can contact me at gnachman () gmail com.

SHA-256 of the zip file is You can use the following to verify the zip file on https://keybase.io/verify:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2 -----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSAPIQGkYVsjnBRo2J0Et0TaFtKrAUCZ3br8gAKCRB0Et0TaFtK rLntAQDqPcKkRA23Wo5/XuB2lymF8n+0GK3E+ZT3MYbTNgsnSQD/Xgt7V9QhP42n QmQpnmb804FrHkCnqIJMvcBAim6AbBM= =Zlrw -----END PGP SIGNATURE-----

---

iTerm2 3.5.6 through 3.5.10 before 3.5.11 sometimes allows remote attackers to obtain sensitive information from terminal commands by reading the /tmp/framer.txt file. This can occur for certain it2ssh and SSH Integration configurations, during remote logins to hosts that have a common Python installation.

In iTerm2 before 3.5.2, the "Terminal may report window title" setting is not honored, and thus remote code execution might occur but "is not trivially exploitable."

An issue was discovered in iTerm2 3.5.x before 3.5.2. Unfiltered use of an escape sequence to report a window title, in combination with the built-in tmux integration feature (enabled by default), allows an attacker to inject arbitrary code into the terminal, a different vulnerability than CVE-2024-38395.

Hi,

I discovered iTerm2 versions 3.5.0 and 3.5.1 (and some beta versions) have a bug where the preference for whether title reporting is enabled is not respected -- the result is title reporting is always enabled.

This is fixed by iTerm2 3.5.2, available from https://iterm2.com/downloads.html -- automatic updates should prompt you to install this version. There is no CVE yet, this is essentially another variant of CVE-2003-0063...

To test if you're vulnerable: printf '\e]0;ivulnerable\a\e[21t'

If you have some of all of the string "vulnerable" (but not just "l") in your input buffer, you're vulnerable. (You can also test via ssh termtest.dgl.cx, which does a variant of the above test and others over SSH, source code at https://github.com/dgl/vt-houdini.)

This is not trivially exploitable (at least in a way that works without user interaction), as it is not possible to echoback a newline or control characters. However as Zsh is the default shell on macOS it may be possible to use some of the vi techniques like I used in xterm CVE-2022-45063[1]. Some of the techniques in solid-snail's previous iTerm2 research[2] could apply too. So treat this as potential remote code execution.

David

: Unless you change the advanced setting "Disable potentially insecure escape sequences" -- which works as a mitigation too, but disables shell integration and some other features.

[1]: https://www.openwall.com/lists/oss-security/2022/11/10/1 [2]: https://blog.solidsnail.com/posts/2023-08-28-iterm2-rce

iTerm2 before 3.4.20 allow (potentially remote) code execution because of mishandling of certain escape sequences related to tmux integration.

iTerm2 before 3.4.20 allow (potentially remote) code execution because of mishandling of certain escape sequences related to upload.

iTermSessionLauncher.m in iTerm2 before 3.5.0beta12 does not sanitize ssh hostnames in URLs. The hostname's initial character may be non-alphanumeric. The hostname's other characters may be outside the set of alphanumeric characters, dash, and period.

iTermSessionLauncher.m in iTerm2 before 3.5.0beta12 does not sanitize paths in x-man-page URLs. They may have shell metacharacters for a /usr/bin/man command line.

iTerm2 before 3.4.18 mishandles a DECRQSS response.

iTerm2 through 3.3.6 has potentially insufficient documentation about the presence of search history in com.googlecode.iterm2.plist, which might allow remote attackers to obtain sensitive information, as demonstrated by searching for the NoSyncSearchHistory string in .plist files within public Git repositories.

A vulnerability exists in the way that iTerm2 integrates with tmux's control mode, which may allow an attacker to execute arbitrary commands by providing malicious output to the terminal. This affects versions of iTerm2 up to and including 3.3.5. This vulnerability may allow an attacker to execute arbitrary commands on their victim's computer by providing malicious output to the terminal. It could be exploited using command-line utilities that print attacker-controlled content.

iTerm2 3.x before 3.1.1 allows remote attackers to discover passwords by reading DNS queries. A new (default) feature was added to iTerm2 version 3.0.0 (and unreleased 2.9.x versions such as 2.9.20150717) that resulted in a potential information disclosure. In an attempt to see whether the text under the cursor (or selected text) was a URL, the text would be sent as an unencrypted DNS query. This has the potential to result in passwords and other sensitive information being sent in cleartext without the user being aware.