iTerm2、重大なセキュリティアップデートを発表
(iterm2.com)- iTerm2 3.5.11は2025年1月2日にビルドされたリリースで、SSH統合に関する重大なセキュリティ修正のため、直ちにアップデートすることが推奨されている
- 影響範囲は、SSH統合機能を使用している3.5.6〜3.5.10および3.5.6以降のすべてのベータ版ユーザー
- バグが発生すると、入力と出力がリモートホストの /tmp/framer.txt に記録され、同じリモートホストの他のユーザーがこのファイルを読める可能性がある
- 条件は、
it2sshの使用、またはプロファイルでCommandが"SSH"かつ"SSH Integration"が選択されている場合で、リモートホストのデフォルト検索パスに Python 3.7以上 が存在する必要がある - ユーザーは 3.5.11へアップグレードした後、影響を受けたリモートホストで
/tmp/framer.txtを削除する必要がある
影響範囲と発生条件
- iTerm2 3.5.11は重大なセキュリティ修正を含むリリースであり、直ちにアップデートすることが推奨されている
- 影響を受ける可能性があるバージョンは、SSH統合機能を使用している次のバージョン
- 3.5.6
- 3.5.7
- 3.5.8
- 3.5.9
- 3.5.10
- 3.5.6以降のすべてのベータ版
- バグにより、SSH統合機能で入力と出力がリモートホストの
/tmp/framer.txtに記録される- このファイルは、リモートホストの他のユーザーが読める可能性がある
- 問題は、次の条件がすべて真の場合に発生する
it2sshコマンドを使用している- または
Settings > Profiles > GeneralでCommandポップアップメニューが"SSH"に設定されており、SSH設定ダイアログで"SSH Integration"が選択されている"Login Shell"、"Command"、"Custom Command"の設定はこの条件に含まれない
- リモートホストのデフォルト検索パスに Python 3.7以上 がインストールされている
アップデートと検証
- ユーザーは直ちに iTerm2 3.5.11 へアップグレードする必要がある
- 影響を受けたリモートホストでは
/tmp/framer.txtファイルを削除する必要がある - SSH統合でログファイルを書き込むコードは削除されており、再び公開リリースされる予定はない
- zipファイルのSHA-256値は次のとおり
655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
- zipファイルの検証には
https://keybase.io/verifyを使用できる
2件のコメント
確認してみたら、自分のバージョンは3.4.3でした。最近はターミナルをあまり使っていないので、気にも留めず更新もあまりしていませんでした。
Hacker Newsの意見
本番環境にprint()デバッグが入ってしまった事例のように見える
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...
verboseモードをオフにしたコミットは、framerログ全体を削除する直前のこのコミット: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
VERBOSEモードをオンにしたコミットはこちら: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
おそらく実装やデバッグ中に
VERBOSE=1に変えて、その後コミット前にVERBOSE=0に戻すのを忘れたのだろうconsole.infoを使っているprintデバッグ自体は問題ないし使う場面もあるが、うっかり残さないように防護策を置くのがよい。本当に起こしやすいミスだ
SSH integration機能のバグにより、入力と出力がリモートホストの/tmp/framer.txtファイルに記録され、そのファイルをリモートホスト上の別ユーザーが読める可能性もあったというのはかなり深刻だ以前SSHで接続したが、今はアクセス権のないマシンにもこうしたファイルが残っているかもしれない
it2sshコマンドを使った、または Settings > Profiles > General で Commandポップアップメニューが"SSH"に設定され、"SSH Integration"にチェックが入っていた場合。"Login Shell"、"Command"、"Custom Command"は該当しないただし
bashやzshの代わりにsshをデフォルトのターミナルコマンドとして使うタイプなら、他のアプリでも変わった機能を多用している可能性が高く、iTermだけでなく他の攻撃対象領域にも気を配るべきだiTerm2は長年、仕事でも個人用途でも便利に使ってきたし、今後も使い続け、以前そうしたようにまた寄付するつもりだ
「このミスを深く後悔しており、二度とこのようなことが起きないよう対策を講じる」といった文を見ると、いつも少しため息が出る
重要なのはどんな対策かだが、こうしたことを再発させないために何をすべきかもよく分からない。すべての機能を実行してシステムコールを捕捉し、ファイルを開いたり書いたりしていないか確認する自動化ツールを作ることもできるだろうが、GUIアプリでは難しすぎて試みすらしない気がする。それより弱い対策では、再発しないと保証するのは難しく感じる
現実的にプログラマーがこれよりはるかにうまくやるのは難しそうで、そう考えると、この一人にすべての責任を負わせるのは不公平だ
ただ、短く書いたからといってミスの大きさを理解していないという意味ではないと思う。それでも、この種のフォローアップの詳細を扱う詳細なブログ記事は後で出るべきだと期待している
謝罪しなければもっと悪いし、再発防止策を講じると言わなくてももっと悪い。今この時点ですべての対策が準備できていたら、むしろおかしい。まず A) バグを直し、B) 修正版を配布し、C) バグと修正版の配布を告知し、その後 D) 事後分析をするべきで、これらを一緒くたにすると手順が乱れたアプローチに見える
すべてのバグや、すべての意図しないファイル書き込みを防げると主張してもおかしい。ファイルに絶対書き込まないと証明するのは不可能だ
よい出発点は、実際に行ったようにSSHロギングを削除し、ファイルアクセスの有無を検証する自動化方法を調査することだ。macOS開発にはエコシステム共通のツールよりはるかに進んだツールが多く、アクセス許可パスの
NSArrayを指定する1990年代の技術文書や、Instrumentsの組み込みdtrace統合のような方法があるかもしれない。これをCIで回し、テストカバレッジを確保すれば、できる限り最善に近い「二度とこのようなことが起きないよう対策を講じる」を「絶対に100%永遠に再発しないと保証できるまで対策する」と読むかどうかが論点のようだ。若く影響を受けやすい人たちに言うなら、このブログ記事は素晴らしく、ここからさらに良くできることはほとんどない
できる対策は、この出来事を教訓にして、その経路に入るときにより注意深くなるようにすることだ
console.logがあるとマージできないようにリンターを使う方法が述べられていたが、自分もまさにそういうアプローチを取ると思う無効な状態が存在できないようにするのは、かなり有用な原則だ
おおむね個人の好みだろうけど、2025年にmacOS標準のTerminalではなく iTerm2 を使う強い説得力のある理由はあるのだろうか？
いろいろ勧められてはきたが、今回のSSHバグのようなセキュリティやプライバシーの問題が心配で慎重になっていた
もう一つは、うっかりタブやウィンドウを閉じても、数秒以内に⌘zを押せば閉じなかったかのようにウィンドウが戻ってくる点
それから 最小カラーコントラスト も良い。ターミナルのカラーテーマと実行中プログラムのカラーテーマが悪く組み合わさって読めなくなると、iTermがそれを検知して自動的により高コントラストの色で上書きできる
ただし、これはあくまで自分にとってのキラー機能。iTermはWordのように何千もの機能を持つ肥大化した怪物だ。誰もが全部を必要としているわけではないし、どの機能が必要かについても合意はない
複数のmacOSリリースノートでも
terminalで検索したが何も見つからなかった。この情報がどこで公開されているのか知っている人はいる？ 公開されていないのだろうか？[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
会社のマシンにSSHしたら青、家のマシンにSSHしたら紫に変わるようにしたかった。標準Terminalでも試したが、セッションがどう終わったかによって紛らわしくなる問題があり、人々からiTerm2ならこれを解決できると勧められた。少なくとも自分の場合は実際に解決した
https://ghostty.org/ も良いとよく聞くが、まだ確認できていない
付け加えると、質問を「代替は何があるか」と読み間違えていた
自分にとっては、ネイティブのmacOSフルスクリーンとは別方式のフルスクリーンモードを使えるだけでも価値がある。ただ、これを重要視する人は世の中に7人くらいしかいないかもしれない
iTermを比較的少ない資金で開発している開発者には深く共感する。すでにAI統合の件で必要以上に多くの批判も受けていた
同時に、今は自分がiTermを使い続けてよいのか大きく不安になっている
HPC環境に接続するときは、短期間しかアクセス権がないこともあり、使用後は自分でデータを整理する必要があり、データ漏洩がないことを期待している。この1年、個人情報を含む研究データを扱いながらiTermのSSH統合を使っていたら困ったことになっていただろう。管理者にログがあるか、自分のものかを確認してほしいという気まずいメールを送り、その後データが漏洩したと公表しなければならなかったかもしれない
高度な機能も一部使っているが、今では基本機能以上を使ってよいのか疑問に思う。そうなると、いっそ別のターミナルを使ってもよさそうだ。Ghosttyを含め、iTermほどmacOSでネイティブのように感じられる クロスプラットフォームターミナル はまだ見つけられていない
タイヤが一度パンクしたから車を捨てるようなものだ。持っている利点や機能を考えると、iTermはいまでも最良の選択かもしれない
個人がシステム全体と使用するすべてのソフトウェアのセキュリティを自分で検証しなければならないなら、その組織にはセキュリティが存在しないということだ
セキュリティ知識のある有能なシステム管理者なら、SSHで接続して作成したファイルがデフォルトで誰でも読める権限を持たないよう簡単に設定できる。ユーザーファイルを完全に隔離する別のロックダウンも設けられるし、
/tmp/のようなグローバルに書き込み可能なフォルダをそもそも無効化することもできる誰かがセキュリティ上脆弱なソフトウェアを使ったと責めるなら、なぜ彼らのシステムがそれほどセキュリティに弱いのかを問い返すべきだ
数年前、iTerm2が 機微な検索履歴 を設定ファイルに漏らす問題を報告し、その問題はすぐに修正された
しかし今でも、公開dotfilesリポジトリで検索履歴を意図せず漏らしている人たちを見つけられる
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
「単に iTerm2 を使うな」という提案は少し理解しがたい
この種の問題はどんなプロジェクトでも起こり得るし、ツールを変えても意味のある保護にはならない。むしろ、こうした事故の後にセキュリティ慣行がより強化されることも多い。ミスをしたエンジニアを解雇するのかという昔からの冗談で、マネージャーが「なぜ解雇するんだ？ 忘れられない教訓を今まさに学んだところなのに」と答えるのに似ている
iTerm2 の履歴を見る限り、致命的なセキュリティ問題が頻繁にあったようには見えず、同じ過ちを繰り返すようにも思えない。繰り返すなら、その時点で改めて評価すればよい
macOS の Terminal アプリはより単純で更新頻度も低いため、リスクが低いように見えるかもしれない。しかしクローズドソースなので監査できず、それ自体のリスクもある。結局、どのツールにもトレードオフがあり、必要な機能と潜在的なリスクのバランスで選ぶべきだ
多くの人は、この2つを合理的な信念として持っている。「どんなプロジェクトにもバグはあり得る」という言い方より、はるかに微妙な見方だ。そうした白黒式の見方はリスク評価にはあまり役に立たない
iTerm2 はだんだん複雑になりすぎ、肥大化しすぎており、セキュリティ問題も多すぎるように見える
macOS で新しいターミナルエミュレーターを探さなくなって久しいが、そろそろその時期かもしれない
GNU Screen も停滞しているようなので、そろそろ先延ばしにしていた tmux への移行もやるべきかもしれない
個人的には、iTerm2 がそのどちらにも当てはまるとは感じない
同じレベルの tmux サポートを提供する他のターミナルはまだ見たことがない
他のアプリを使うと日常利用が改善されるほど、Terminal には何が足りないのか？
Zellij は Rust 製のターミナルマルチプレクサなので、見てみる価値がある。特にキーバインドを見つけやすい点がとても良い。TUI で夢見ていた形に近い
これは SSH 統合にだけ該当し、iTerm で単に
"ssh"を実行した場合の話ではないのか？自分が普通の ssh で接続したホストでは
/tmp/framer.txtファイルを見つけられなかった後者の条件は、エンタープライズ向けディストリビューションでもおおむね当てはまる可能性が高い。たとえば RHEL 9 には Python 3.9 が標準でインストールされる