クリップボードを覗いたのは誰か — Zoom、X11、そしてQt
クリップボードを覗いたのは誰か — Zoom、X11、そしてQt
アプリがクリップボードを黙って読んだとき、責任はそのアプリにあるのか、それともそれを許したプラットフォームの設計にあるのか?
導入
2026年9月12日(UTC)、Hacker Newsのトップに「Linux版Zoomクライアントが、X11クリップボードに書き込まれるものをすべて先回りして読んでいる」という投稿が上がり、433ポイントを集めた。元になったのは、Simon Tathamが9月2日にMastodon(hachyderm.io)へ投稿した一連の書き込みである。
彼の観察は単純だ。Linux版Zoomを6.6から7.1.5へ更新して以降、誰かがCLIPBOARDセレクション(Ctrl+Cでコピーし、Ctrl+Vで貼り付ける側)を新たに所有するたびに、Zoomが即座にその所有者へ貼り付け要求を送るようになったというのである。ユーザーが何も貼り付けていないにもかかわらず、だ。Tathamは、パスワードマネージャーがクリップボード経由でパスワードを渡すケースに直接触れ、クリップボードに興味深い秘密を置く人なら知っておくべきことだと書いた。
この件は二系統の反応を生んだ。一方は「Zoomがまたやった」という反応で、もう一方は「X11ならもともと誰でもできる、Waylandを使え」という反応である。ところが一か月後、三つ目の答えが出てきた。Zoom側が原因をサードパーティのライブラリ、すなわちQtのバグだと名指ししたのだ。本稿では、アプリ、プラットフォーム、ライブラリという三つの候補を順に検討する。
現象の分析 — 「ワンショット貼り付け」が暴いたもの
Tathamがこの挙動に気づいた経緯が興味深い。彼は「ワンショット貼り付け」ツールを愛用している。クリップボードの所有権を取得し、貼り付け要求をちょうど一回だけ処理して即座に終了するプログラムである。Webフォームの複数の欄を埋めるとき、貼り付ける値を順番にキューへ積んでおき、各欄で貼り付けを押すだけで済む。ところがapt updateの後、このツールが起動した途端に終了するようになった。デバッグしてみると、クリップボードを所有した瞬間にZoomが貼り付け要求を送り、その「一回」を使い切っていたのである。
この観察が可能だったのは、X11のセレクション(selection)の構造による。Tathamの説明では、X11の貼り付けは「現在のセレクション所有者に連絡し、データを送ってもらうよう要求する」形で行われる。Hacker Newsのst_goliathも同じ点を指摘している（直接の引用ではなく、コメントの要旨の要約）。Windowsのように中央のリポジトリにデータが溜まるのではなく、コピーしたクライアントがデータを保持し、貼り付けたいクライアントがXサーバーを介してそのクライアントとやり取りする。だから元のプログラムを終了するとデータは消え、現代のデスクトップ環境は所有権の変化を検知してデータを即座に引き取るクリップボードマネージャーのデーモンを別に置いている。
この構造には副作用がある。所有者は、誰がいつ貼り付けたかを知ることができる。Tathamはこれを利用して、貼り付けた「瞬間」の時刻を返すといった芸当もできると書いている。裏を返せば、所有者側のツールさえあれば「誰が要求したか」を観測できるということだ。彼は標準ツールで再現する方法を残している。
sudo apt install xclip
echo -n foo | xclip -selection clipboard -loop 1 -verbose-loop 1は、要求を一回処理したら終了せよという意味である。正常であれば、ユーザーがどこかに貼り付けるまで待つはずだ。Zoom 7.1.5が同じXサーバー上で動いていると、このコマンドは即座に終了する。
Tathamの観察で事実として確認できる範囲を整理しておく。対象はCLIPBOARDのみで、マウスで選択して中ボタンで貼り付けるPRIMARYには触れない。変更の検知はXFIXES拡張を通じて行われているように見える。要求を送ったウィンドウはZoomのメインウィンドウではなく、汎用的な名前を持つ補助ウィンドウで、彼はxkillでそのウィンドウを殺し、どのアプリが消えるかを見てようやくZoomだと確認したという。さらに、Web版の設定でクリップボード関連のオプションをオフにしてクライアントを再起動しても、挙動は変わらなかった。
確認されていないことも明確にしておく。Zoomが読み取った内容を外部へ送信したかどうかは、誰も示せていない。Mastodonのスレッドでは、クリップボードにデータを流し続けてZoomの送信トラフィックが増えるか見てみようという提案や、Zoomのリンクを検知して会議参加を促す機能だろうという推測が出たが、いずれもこのスレッド内では検証されていない。「読んだ」と「漏洩させた」は別の主張である。
深層分析 — アプリの問題か、プラットフォームの問題か
Hacker Newsの議論の中心軸はこの問いだった。Waylandが解決するという側の論理はこうだ。Mastodonのスレッドでshrub900は、Waylandでは一般にキーボードフォーカスを持つアプリしかクリップボードにアクセスできないため、バックグラウンドのZoomにはこうした挙動はできないと説明した（直接の引用ではなく、コメントの要旨の要約）。実際、Waylandのコアプロトコルは、コンポジターがクライアントにキーボードフォーカスを与える「直前」に現在のセレクションを通知するよう定めている。この規定は、後で取り上げるQtのバグ報告がwayland.xmlを引用してそのまま記している。
反論もいくつも出た。一つは迂回路である。デスクトップがWaylandでも、アプリはXWayland上でX11クライアントとして動けるし、そうすればX11の流儀でクリップボードを扱えるという指摘だ（dotstdy、直接の引用ではなく、コメントの要旨の要約）。もう一つは機能の喪失である。Tatham自身がこう問うている。それならxclip -oのようなコマンドラインの貼り付けツールも動かなくなるのではないか、と。彼はそうしたワークフローを多用しているため、Waylandへ移行する際には大きなトレードオフになると書いた。Hacker Newsのteravorは、Waylandでもセキュリティコンテキストで特権プロトコルを禁止しない限り一般に安全とは言えず、禁止すればアプリはフォーカスを得るまでクリップボードを読めないか、フォーカスを奪うために短命のウィンドウを出す試みが目立つことになると述べた（直接の引用ではなく、コメントの要旨の要約）。bandramiは、その能力を断つことがWayland開発の理由の一つだったが、人々が望んでいた機能まで削った結果、コンポジターが元の欠陥を再び複製していると皮肉った（直接の引用ではなく、コメントの要旨の要約）。
この論争を整理すると、Waylandはクリップボードへのアクセスを「不可能」にしたのではなく、「フォーカスという時点」に縛ったのである。これは攻撃の窓を狭めるが、閉じはしない。そしてクリップボードマネージャーやワンショット貼り付けツールのように、フォーカスなしでクリップボードを扱う必要がある正当なツールのために、データコントロール系のプロトコルという裏口が再び開く。「誰がその裏口を使う資格を持つか」を判定する基準がアプリ単位の権限体系でない限り、問題は形を変えて残る。
X11側の限界はより根本的だ。Tathamは9月12日の返信で、クリップボードへのアクセスをアプリごとに防ぐ防御がなぜ難しいかを説明している。X11プロトコルでは、貼り付けを要求したクライアントをウィンドウIDの範囲で識別するのは容易だ。しかしそれが「どのアプリなのか」を確定するのは難しい。範囲内でタイトルやWM_COMMANDといった識別情報を持つメインウィンドウを見つけること自体が自明ではなく、何より、ウィンドウとプロパティのどこにも偽造不可能なものがない。だから彼は、こうした防御は「雑に作られた」アプリには効いても、本当に悪意のあるアプリは身元を偽れると想定すべきだと結論づけた。
ここで今回の件の性格が見えてくる。X11の信頼モデルは、同じXサーバーに接続したすべてのクライアントを同じ信頼レベルで扱う。セレクションを読むことは「無作法だが許されている」行為である。したがってX11上では、この挙動はプラットフォームが防げないのではなく、そもそも防ぐ対象として定義されていないのだ。この観点に立てば、「Zoomの問題かプラットフォームの問題か」は二者択一ではない。プラットフォームが境界を置かなければ、境界は各アプリの自制に委ねられる。そしてアプリの自制は、そのアプリが使うライブラリのデフォルト動作にさらに委ねられる。
その最後の委任が、今回の件の結末だった。10月8日、Hacker Newsのスレッドにtommygaesslerというアカウントが Zoom側の立場を伝えた（直接の引用ではなく、コメントの要旨の要約）。Zoom Workplace for LinuxがX11クリップボードに想定より頻繁にアクセスするバグを認識しており、原因となったサードパーティのライブラリを特定してそのメンテナーと対処し、修正は9月18日にリリースされた7.2.0に含まれている、という内容である。彼がリンクしたのはQtのQTBUG-149610だ。このアカウントがZoomの公式な代弁者かどうかは、HNのコメントだけでは確認できないことを記しておく。
QTBUG-149610は8月29日に登録された。タイトルは「TextInputのcanPasteがQClipboard::dataChanged()で即座に再計算される」である。報告によれば、Qt QuickのQQuickTextInputはクリップボードが変わるたびに「貼り付け可能かどうか(canPaste)」を再計算しているが、ある変更(6c07e2a762)以降、空のクリップボードを除外するためにQMimeData::text()を呼ぶようになった。形式だけを確認するhasText()と違い、text()はクリップボードの「中身」を実際に転送させる。報告はこのリグレッションがQt 6.10.3と6.11.0から含まれたと記している。報告の主な記述は、Waylandでフォーカスを得るたびに中身の転送が起き、最大で約2秒UIが固まるという性能問題である。X11でTathamが見た「所有権が変わるたびの即時要求」が同じ経路だというのは、Zoom側の主張とメカニズムの一致から導いた推論であり、Zoomが使っているQtのバージョンを本稿で直接確認したわけではない。
この報告で目を引く点が二つある。第一に、9月10日に参加者の一人が、これは性能問題にとどまらずセキュリティ・プライバシーの問題であり、TextInputを持つQt Quickアプリが多くの場所でマルウェアと見なされかねないと指摘した。第二に、Waylandでもこのリグレッションは「フォーカスを得るたびに」中身を読んでいた。つまりWaylandのフォーカス制限は読む時点を狭めただけで、読む理由のない中身を読むコードそのものは止められなかったのである。
展望と示唆
この件が示す第一の教訓は、「意図」と「結果」の分離である。Zoomの説明が事実なら、どのプロダクトマネージャーもパスワードを収集せよとは指示していない。テキスト入力欄一つが貼り付けボタンを有効にすべきか判断するために、クリップボードの中身を丸ごと取得したのだ。しかしユーザーから見れば結果は同じである。パスワードマネージャーがクリップボードに載せた秘密が、会議アプリのプロセスのメモリに入った。プライバシー事故の多くは悪意からではなく、「利便のためのデフォルト」から生まれる。
第二は責任の連鎖である。X11は境界を置かず、Qtはリグレッションを入れ、ZoomはそのQtをそのまま出荷した。各段階はそれぞれの言い分を持つ。X11は古い信頼の前提に従っただけであり、Qtは性能リグレッションに分類されたバグを直し、Zoomはサードパーティのライブラリのせいにした。しかしユーザーに見えるのは「Zoom」という名前だけだ。Hacker NewsとMastodonの反応の多くが、過去のZoomのmacOS権限問題やローカルWebサーバーの件を持ち出して信頼を引き揚げたのもそのためである。ライブラリのバグという説明は技術的には妥当かもしれないが、出荷した側の検証責任を消すものではない。
第三はLinuxデスクトップの権限モデルである。Hacker Newsのameliusと Lucasoatoは、スマートフォンは何年も前からより良い権限体系を持っているのに、なぜLinuxディストリビューションはアプリをきちんとサンドボックス化しないのかと問うた（直接の引用ではなく、コメントの要旨の要約）。ryandrakeはさらに踏み込み、今日のクリップボードという概念が新たに発明されたなら、どれほど寛容なプライバシーレビューも通らないだろうと主張した（直接の引用ではなく、コメントの要旨の要約）。実務的な対応としては、ブラウザのタブでZoomのWebクライアントを使う方法、Qubes OSのようにVMで隔離する方法、iPadのような別デバイスを使う方法が挙がった。ブラウザはクリップボードの読み取りをサイトごとの権限として扱うため、逆説的にデスクトップのネイティブアプリより境界が明確である。
(9月13日以降の追記:Qtの修正は9月13日にdevと6.12ブランチへ、9月15日に6.11ブランチへ統合された。6.8へのバックポート要求に対し、担当者は公開版の6.8ブランチにはこのリグレッションは存在しないと回答し、10月7日には商用LTS 6.8ブランチにも関連する変更が統合されたという記録が残っている。Zoom 7.2.0の9月18日リリースはHNコメントの主張であり、本稿ではリリースノートで確認していない。)
結論
「Zoomの問題か、プラットフォームの問題か」という問いへの答えは、「両方であり、その間にライブラリがある」である。X11は同じサーバー上のすべてのクライアントがセレクションを読めるよう設計されており、アプリを信頼できる形で識別する手段も与えない。その上では、プライバシーは各アプリとそれが使うツールキットの自制に任される。今回は、Qtの一行のリグレッションがその自制を崩した。
Waylandはこの問題をフォーカスの時点に狭めるが、同じQtのリグレッションがWayland上でもフォーカスのたびにクリップボードの中身を読んでいたという事実は、プロトコルだけでは十分でないことを示している。そしてこの件を見つけたのはセキュリティ監査ではなく、一人の開発者が自作したワンショット貼り付けツールが妙に早く終わるという些細な観察だった。
あなたのパスワードマネージャーは、クリップボードを経由してパスワードを渡しているだろうか。もしそうなら、いま同じデスクトップで動いているアプリのうちいくつが、どのライブラリのバージョンで、その瞬間クリップボードに手を伸ばしうるのかを把握しているだろうか。
出典: