## Securing X Windows

John
Fisher
UCRL-MA-121788

              fisher@llnl.gov

CIAC-2316 R.0
August, 1995
jf

この文書は X ウィンドウにおける多くのセキュリティ上の問題とその 解決法を探究します。

## はじめに

X ウィンドウは、様々な環境において、幅広いユーザの支持を得ています。 そこでのクライアント・サーバモデルによるアプリケーション管理は、ユー ザとコンピュータとの間を、パワフルかつ柔軟に取り持つ能力を有してい ます。しかし、残念なことに、この能力はセキュリティの犠牲の上に成り 立っています。X ウィンドウは、適切に管理されない場合、セキュリティ 上の深刻な脆弱さを生むことがあります。この文書は X ウィンドウにお けるそうしたセキュリティ上の問題とその解決方法を探求します。

この文書は WWW 上のCIAC2316 から入手できます。

### 免責

This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes.

Reference to any specific commercial product does not necessarily constitute or imply its endorsement, recommendation or favoring by CIAC, the University of California, the United States Department of Energy, or the United States Government.

Work performed under the auspices of the U. S. Department of Energy by Lawrence Livermore National Laboratory under Contract W-7405-Eng-48.

> 参考訳：

> この文書は、合衆国政府の一機関の資金援助を受けた仕事に関する報 告書として準備されたものです。合衆国政府、カリフォルニア大学、 およびそれらの職員は、明示的・黙示的な如何なる保証もするもので はありません。また、情報・装置・製品・示されたプロセスについて の、正確さ・完全性・利便性に関する如何なる法的責任も負いません。 この文書の使用は個人の権利を侵害しないというつもりもありません。 特定の商品および、商号・商標・製造元が付されたプロセスやサービ スについて言及したり、もしくはされたりした場合でも、それは必ず しも、合衆国政府やカリフォルニア大学による裏書きや推薦や引き立 てを示すものでも暗示するものでもありません。ここで表明された著 者の見解や意見は、必ずしも合衆国政府やカリフォルニア大学がそれ を述べたり、反映したりしているものではないので、それを宣伝や商 品の推奨目的に使用することのないようにしてください。

> 引用した特定の商品すべては CIAC、カリフォルニア大学、合衆国エ ネルギー省、合衆国政府の明示的・暗示的な推薦でも推奨でも好みで もありません。

> 合衆国エネルギー省の援助の下、Lawrence Livermore National Laboratory の契約書番号 W-7405-Eng-48 に基づき、作業がなされま した。

### CIAC について

UCRL-MA-118453

CIAC のホームページ

  http://ciac.llnl.gov/ciac/CIACHome.html

免責

  http://www.llnl.gov/disclaimer.html

## X ウィンドウはどのように動作するのか

グラフィカルユーザインターフェースが潜在的にセキュリティ上の深刻な 脆弱さを持つと言うと奇妙に思われるかもしれません。だから手始めに、 X ウィンドウがどのように動作しているかを観察し、どのような問題があ るかを検証していきましょう。

X ウィンドウの最下層レベルは、実は、通信プロトコルなのです。これは X プロトコルという分かり易い名前で呼ばれています。このプロトコルは、 一台のコンピュータの内部で使用されることもあれば、ネットワークを通 じて複数のコンピュータで使用されることもあります。それは、特定のオ ペレーティングシステムに縛られたものではなく、様々なプラットフォー ムで利用できます。また、X ウィンドウは、ネットワーク通信モデルとし てクライアント・サーバモデルを使っています。このモデルを使うことで、 ユーザは、ある場所でプログラムを実行しつつ、それを別の場所から制御 するということが可能になります。

一般的なクライアント・サーバの慣習とは違い、ユーザは、実際には、X サーバ上で直に作業をしています。スクリーン・キーボード・マウスの機 能を提供しているのは、X サーバなのです。この場合にもそれをサーバと 呼ぶのは、X サーバがクライアントに対するインプットを生成し、クライ アントからのアウトプットを管理するものだからです。ここで X クライ アントとは、xterm や emacs, xclock といったア プリケーションのことです。これらが X サーバからのインプットを受け 取って処理した上で、アウトプットを X サーバに戻しています。

[訳注：文章だけでは分かりにくいので、絵を書きました。

       ___________
      /__________/|
      |;--------;||             +-----------+ インプット +--------------+
      ||スク    |||       <-管- |           | ---------> |              |
      ||  リーン|||             |           |            |              |
      ||________|||       <-  - | X サーバ  |            |X クライアント|
      [___ooo____]/             |           |アウトプット|              |
                    _%_   <-理- |           | <--------- |              |
      _____%_____  ////         +-----------+            +--------------+
     /::::::::::/ /__/                             xterm, emacs, xclock 等
    *----------*  マウス
     キーボード

      物理的なデバイス <--- | ---> プロセス

]

ほとんどの場合、サーバとクライアントは同じコンピュータ (ホスト) 上 で動作します。しかし X プロトコルは柔軟性に富んだもので、多くの異 なる構成が可能です。実際に、X 端末はスクリーン・キーボード・マウス から成り、コンピュータらしい能力はありません。これは、他のシステム 上で動作しているクライアントから来る X プロトコルのメッセージを処 理することしかできません。サーバがあるホスト上で現在稼働している場 合であっても、クライアントはそれとは離れたホスト - たとえそのホス トが別のビルや州に置かれていたとしても - の上で実行するのが望まし いことがあるからです。

それで、これがコンピュータのセキュリティとどういう関係があるのでしょ うか？サーバ上で実行が可能なクライアントというのは、注意深く制御さ れるべきです。複数のクライアントが同じサーバ上で動作しているわけな ので、それらクライアント間通信には、注意深い制御が不可欠です。ある クライアントが別のクライアントに情報を送れたり、あるクライアントが 別のクライアントの大事な情報を捕捉できるなら、そのシステムは脆弱な 可能性があります。

## 保護されていない X ウィンドウ

X サーバと X クライアント間の通信の例をいくつか示します。

- X 端末の変化 - フォント管理、マウスの感度、カラーマップ、キー ボードマップ

- X イベント - キーボード、マウスなど

- X データ - 文字を書いたりウィンドウを作成したり画像を描くと いった X 端末のスクリーン上の変化

サーバにアクセスできるクライアントというのは、潜在的に、そのサーバ 上で行われている X 通信のすべてにアクセスし、それを変更する能力を 持っているといえます。つまり、以下の事柄が可能かもしれません。

- セッションパラメータの修正

- ウィンドウの作成・破壊 - 文書を保存する前にウィンドウがどう いうわけか消滅したことはありませんか？

- X イベントの捕捉 - 例えば xterm ウィン ドウ上のキーストロークを読むことで、ログインとパスワードのキー ストロークも読めます。

- X イベントの作成 - 例えば emacs や xterm のウィンドウにキーストロークシー ケンスを送ることで、コマンドを実行できます。

はっきり言って、X サーバは本質的に危険なのです。なお一層悪いことに、 多くのサーバは、初期設定だと、どこからでもアクセス可能な状態で出荷 されているのです。

## セキュリティ強化の方法

X サーバのセキュリティを強化する一番いい方法は何でしょう？二つの異 なる方法が利用できます - ホスト認証とトークン認証です。それぞれに ついて以下で述べます。

### ホスト認証

ホスト認証はコネクションの始点に基づきコネクションを承認するもの です。一般的にこの承認はコネクションを張るホストの IP アドレスに より決定されます。ユーザが X サーバにログインすると、サーバはど のホストからのコネクションも受け入れる可能性があります。 xhost と呼ばれるプログラムは、どのホストが その X サーバ上にクライアントを表示できるかという host-by-host レベルの制御のために用意されています。しかし、ほとんどのホスト はマルチユーザをサポートしているので、あるホスト上の任意ユーザ に対してアクセス制御を行うことは不可能です。

### トークン認証

認証方法の二つめはそれぞれのクライアントが提供するトークンに基づ きそれらを確認します。xauth と呼ばれるプログラムを用い、それぞれ のクライアントに 'magic cookie' を与えます。'magic cookie' は乱 数で、アクセスを許可してもらう X サーバに提供しなければなりませ ん。

## ホスト認証

X のセキュリティ強化のために最も広く使われている仕組みはもちろん xhost プログラムです。簡単に使える反面、 xhost はやや柔軟性にかけます。

### xhost の使い方

xhost プログラムの使い方は複雑ではありませ ん。それぞれの X サーバはアクセスを許可もしくは拒否するホストの 一覧を管理します。xhost プログラムはその一 覧を修正するために使われます。コマンドラインの構文を次に示します。

- この X サーバがアクセスを許可しているホストの一覧を表示し ます。

  xhost

- bar.foo.org というホストを追加するために、次を入力します。

  xhost +bar.foo.org

  その結果そのマシン上のどんなユーザのどんなプログラムも X サーバと通信できるようになります。

- 先程と同じホストを削除するために、次を入力します。

  xhost -bar.foo.org

- アクセス制御を無効にして X サーバを世界に向けて開きます。 [訳注：非常に危険なので、軽々しく試してはいけません。]

  xhost +

- アクセス制御を再度有効 (つまり現状のホストの一覧を再び利用 します) にするために、次を入力します。

  xhost -

引き数が無い場合、xhost は アクセス制御を有 効にしているかどうかと、どのマシンにアクセスを許しているか戻しま す。これはリモートから実行できる xhost の唯 一の用法で、たとえそのリモートマシンがアクセスリスト上にあったと してもこれしかできません。認められていないホストのユーザが接続を 試みるために xhost を利用すると、次に示す応 答が表示されるでしょう。

              Xlib: connection to "display:0.0" refused by server
              Xlib: Client is not authorized to connect to Server

コネクションが張られた後、そのホストアクセスを無効にしても既存の コネクションには影響しないことに注意してください。確立 (establish) されたコネクションを切るには、そのサーバをリセットし なければなりません。

しかし実のところ、これは便利な機能でもあります。 xhost を使うスマートな方法は、あるホスト上 のクライアントを起動する間だけそのホストのアクセスを許すことです。 そして、アクセスを無効にします。そのクライアントは動きつづけます が、ホストのアクセスは再び無効になります。

### 長所：

xhost のアクセス制御の仕組みはもちろん使い やすいことです。単純な構文のプログラムが一つ必要なだけです。

### 短所：

xhost の簡素さは長所と短所をあわせもちます。 あるホストからのすべてのコネクションはすべて受け入れられるか、す べて切断されるかのどちらかで、user-by-user, program-by-program, connection-by-connection を基準にしたものではありません。多くの 環境では、無数のユーザが特定のホストへのアクセスを許可されている ため、これでは解決法としては不十分です。そしてもちろん、X サーバ を実行しているほとんどのコンピュータは複数のユーザアカウントを持 ち、コンピュータにログインできるユーザは localhost の X サーバと して、完全に xhost のアクセス制御を迂回して X サーバにアクセスできます。

残念ながら、NCD サーバ、SGI システム、Macintosh 用 Mac X といっ た多くの X サーバは、初期設定で、アクセス制御が無効になっていま す。X サーバの脆弱さについてよく分かっていないユーザたちにとって、 これは深刻なセキュリティ上の問題を生じさせるかもしれないものです。

Xhost はトークン認証に優先します。特別な権 限やシステム管理者からの援助なしに、ユーザはあるシステムを xhost のアクセスリストに追加できます。

## トークン認証

X サーバは magic cookie を使って、ユーザの X サーバへのアクセスを 制御できます。これは本質的に機械向けに書かれた、乱数から生成され たアクセスコードです。各クライアントはアクセスの許可をしてもらう前 に同じ magic cookie の値をサーバに提供しなければなりません。この値 はファイル .Xauthority に保持されます。それは 各セッションの開始時に X Display Manager かユーザのどちらかによっ て作成されます。

一台のマシンへのログオンしかしないユーザなら、セキュリティの強化と いう課題は残ってはいますが、話は簡単です。そのマシン上のユーザによっ て実行されたそれぞれの新しいクライアントはその magic cookie を見つ けて問題無く起動するでしょう。しかし、多くのユーザは同時に複数のマ シン上で作業します。リモートマシン上の X クライアントはその magic cookie が何かどうやって知るのでしょう？これは xauth プログラムの機 能が解決します。

### xauth

xauth プログラムはユーザの magic cookie の認証情報を変更および表 示するために使われます。magic cookie が人に読める形で表示されれ ば、リモートホストに送ることができます。そのリモートホスト上でユー ザの .Xauthority ファイルの中に magic cookie をマージするために、xauth をもう一度使います。ユーザ用の .rhosts ファイルが設定されているなら、リモートホスト (ahost.foo.org とします) へ認証情報を押入れることは次の一行のコ マンドでできます。

              xauth extract - $DISPLAY | rsh ahost.foo.org xauth merge -

最初のコマンドは使用中のホスト (&dollar;DISPLAY) 用の magic cookie を標準出力 (ダッシュ) に印字します。次にこの情報はリモー トシェルコマンドへパイプされて、マシン ahost.foo.org 上で xauth プログラムを実行します。そして magic cookie は標準入力 (二つ目の ダッシュ) から読まれて、.Xauthority ファイ ルの中にマージされます。その結果、このコマンドを実行したユーザは ahost.foo.org 上の X クライアントを起動し、それらを X サーバ上に 表示できるようになります。.Xauthority ファ イルのパーミッションを正しく設定することが重要です。所有者だけが 読み書きできるようにします ('-rw-------' に 設定します)。さらに、ホームディレクトリをリードオンリーでも NFS でエキスポートしないように気をつけてください！マウントされるかも しれず、.Xauthority ファイルを読むことを許 してしまいます。

ここで、何が主に改善されたのかに注意してください。現在、このコマ ンドを実行したユーザは、ahost.foo.org 上のそのユーザ唯一人で、彼 だけがその X サーバへ X クライアントを接続できます。依然として ahost.foo.org 上の他のすべてのユーザはこの X セッションの外にブ ロックされます。

### X Display Manager

X Display Manager, xdm はログインスクリーン を複数の X サーバに供給するクライアントです。ユーザが X Display Manager を介してログインする時、xdm はユー ザのホームディレクトリにあるファイル .Xauthority の中へ magic cookie を書きます。 X サーバは独立型のコンピュータであるとは限りません。唯一の機能が 他のシステムからのクライアントを実行する X 端末でも可能です。こ の手のマシンは xdm が最初のログインスクリー ンを表示することを必要とします。独立型のコンピュータでも xdm を利用するかもしれません。多くのユーザ に使いやすいログイン手順を提供する以外に、 xdm は magic cookie による認証のサポートも 提供します。この認証は初めにファイル /usr/lib/X11/xdm/xdm-config 内の次に示す X リソースのエントリをオンにしなければなりません -

              DisplayManager*authorize:     true

これで xdm はユーザがログインするたびに新し い magic cookie を生成して、ユーザの .Xauthority ファイルの中にその値を格納しま す。

xdm を使わない場合でも、この認証方式を使う ことができます - このことは次の項で述べます。

### Xdm なしで magic cookie を生成する

Xdm はあなた用の .Xauthority ファイルを管理しますが、 xdm を使わなくても magic cookie 認証は可能 です。多くのサーバ上で、ユーザが magic key の値を生成する必要が あるということが問題なだけです (OpenWindows は例外の一つで、起動 された時にそれは magic cookie を生成します)。これは様々な方法で 行うことができます。例えば、Korn シェルを使っている場合、シェル に組み込まれている乱数生成機能を使えます -

              randomkey=`ksh -c 'echo $(( $RANDOM * $RANDOM * 2 ))'`
              xauth add ${HOST}:0.$randomkey

ksh を使ってない場合、clock が '乱数 key' を得るために使えるでしょ う -

              randomkey=`date +"%y%m%d%H%M%S"`
              xauth add ${HOST}:0 . $randomkey

### X11R5 における Xrsh

Xrsh は X11R5 が提供するスクリプトで contrib/clients/xrsh ディレ クトリにあります。rsh を介しリモートのクライアントを実行するユー ザにとって、これは便利なスクリプトです。これはリモートのクライア ントを実行する前に自動的にリモートマシンへ magic cookikie code をコピーするために xauth を利用します、例えばホスト foo 上の xterm ウィンドウを実行するには -

              xrsh -auth xauth foo xterm

と入力します。

### 長所：

認証は host-by-host ではなく、user-by-user の基準で行われます。 一つのホストがとても多いユーザをサポートする環境において、これは 非常に重要なことです。

### 短所：

xdm と xauth プログラムは管理者とエンドユー ザが使用および維持するのに時間のかかるものです。ユーザの方で X のクライアントサーバモデルをよく理解していることが必要です。

magic cookie 認証は xhost のセキュリティに 加えて、使わなければなりません。実際にはすべてのホストに基づくア クセスを無効にするために 'xhost -' を使わな ければなりません。

## Xterm の脆弱性

xterm プログラムはユーザにコマンドラインプロ ンプト (Unix のシェル) を提供するために使われます。コマンドライン プロンプトを介して多くの重要なユーザとコンピュータとのやりとりが行 われるので、このプログラムを安全に実行できることが重要です。 xterm プログラムにあるいくつかのセキュリティ 上の脆弱性について述べます。

一つは、xterm が提供する write-access 機能で これを利用するべきではありません。SendEvent はキーとボタンのイベン トで人為的に生成されます (要するにキーボードやマウスによるものでは ありません)。デフォルトで xterm は X サーバか らの SendEvent 要求をすべて拒否します。しかし、これは二つの方法で 変更可能です。方法の一つ目は、.Xdefaults ファ イルか app-defaults/Xterm ファイルのどちらか の X リソースの定義に次の行を追加します。

            xterm*allowSendEvents: True

方法の二つ目は、xterm のメインオプションメニュ ー (CTRL キーを押しながらマウスの左ボタンを押すことで表示できます) を介して X サーバに X イベントを送ることを許可することです。 これら二つの方法は、xterm を起動した人以外からの通信を可能にしてしまうので、 絶対に行うべきではありません。

しかし、read access は異なった仕組みを介して制御されます。メインオ プションメニュー上の 'Secure Keyboard' オプションです。オンにした 時、すべてのキーボードのイベントはその xterm ウィンドウにのみ送られます (マウスのやりとりは変更されません)。こ れは他のクライアントがパスワードの入力といった重要なキーボードのイ ベントを捕捉することを妨げます。もちろん、一時期にこのオプションを オンにしてもいいのは一つの X クライアントだけです。このオプション は重要なデータ入力に役立ちますが、他のウィンドウとやりとりするため にはオフにしなければならないので、継続使用するには実際的ではありま せん。

## X ウィンドウのセキュリティに関する情報

以下に示す CIAC の掲示は X ウィンドウに直接関連するもので公開され ています。

- E-04: X11R5 のパッチレベル 26 があたっていない Xterm のバージョンは、ログ機能にセキュ リティ上の脆弱さがあります。この脆弱さは認証されていないユー ザが root を取ることを許してしまいます。 xterm プログラムに 's' (setuid) のパー ミッションビットが設定され、コマンド 'xterm -l' がファイル 'XtermLog.axxxx' を作成するなら、その脆 弱さが存在するかもしれません。

- B-11: OpenWindows 2.0 (今ではとても古いバージョンです) を実行して いる Sun のコンピュータのセキュリティ上の脆弱さは重要なファ イルの盗用を許します。これを除去する方法を述べています。 E-05, D-11: これらは SunOS と Solaris 用のリリースの発表です。 これら二つのパッチは OpenWindows システムにおけるセキュリティ ホールを修復します。特に loadmodule パッチは広く利用されてい たバグも修正するので、重要です。

- F-19: SATAN と呼ばれるよく知られた脆弱さの探査プログラムは X ウィ ンドウの脆弱さを探索します。この掲示は SATAN 探査から HP-UX の X ウィンドウサーバを保護するために Hewlett-Packard HP-UX に関連した情報を提供します。

- F-21: この掲示は F-19 と同様ですが、SUN OS に固有の情報です。

- F-23: この掲示は F-19 と同様ですが、IBM AIX に固有の情報です。

- F-24: この掲示は F-19 と同様ですが、SGI IRIX に固有の情報です。

以下に示す CIAC の注記は X ウィンドウに直接関連するものです。

- Notes 7: SATAN の詳細を述べた非常に長い論文で、その探査は X ウィンド ウ固有の情報を網羅します。

上記の掲示と注記のすべては http://ciac.llnl.gov にある CIAC のウェ ブサーバ上で利用できます。

## APPENDIX A: CONTACTING CIAC

            Phone                (510) 422-8193

            Fax                  (510) 423-8002

            STU-III              (510) 423-2604

            Electronic mail       ciac@llnl.gov

            Emergency SKYPAGE     800-SKYPAGE pin# 855-0070

            Anonymous FTP server  ciac.llnl.gov (IP 128.115.19.53)

            BBS                   (510) 423-3331 (9600 Baud)
                                  (510) 423-4753 (2400 Baud)

### READER COMMENTS

CIAC updates and enhances the documentation it produces. If you find errors in or have suggestions to improve this document, please fill out this form. Mail it to CIAC, Lawrence Livermore National Laboratory, P.O. Box 808, Mail Stop L-303, Livermore, CA, 94551-9900. Thank you.

        List errors you find here. Please include page numbers.

        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________

        List suggestions for improvement here.

        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________
        ________________________________________________________________________

        Optional:

        Name _____________________________________________  Phone ______________
        Securing X Windows CIAC-2316 R.0       September, 1995

## 日本語訳について

日本語訳は Linux Japanese FAQ Project が行いました。 翻訳に関するご意見は JF プロジェクト <JF@linux.or.jp> 宛に連絡 してください。

この文書は LDP 文書 Remote X Apps mini-HOWTO (日本語訳) で紹介されています。この mini-HOWTO はリモート X アプリケーションを実行する方法について説明 しているもので、関連した読み物として、この文書を読むことを勧めてい ます。この文書自体は CIAC に html 文書として掲示されていたものを JF で公開するために、DocBook 化し、著者の了承を得たものをソースと して使用しました。内容は 1995 年当時の X である X11R5 と linux で はない Unix をベースに書かれているので、現在の linux の各ディスト リビューションと、コマンドやファイルパスなど多少違いがあります。し たがって、この文書は Remote X Apps mini-HOWTO を補う読みものとして 活用してください。

### R.0j

翻訳:

  野本 浩一 hng@ps.ksky.ne.jp

保守(2004/03/05):

  小林 雅典 zap03216@nifty.ne.jp

校正:

  - 佐野 武俊さん kgh12351@nifty.ne.jp

  - 千旦 裕司さん ysenda@pop01.odn.ne.jp

  - さいとう かんさん cans@i-cann.org

  - 中島 幹夫さん minakaji@osaka.email.ne.jp