X11のスクリーンロッカーが安全でない理由 42
ストーリー by headless
回避 部門より
回避 部門より
本家/.「Why Screen Lockers On X11 Cannot Be Secure」より
Windows NTのセキュリティー機能で誰もが思い出すことの一つとして、ワークステーションのロック解除にCTRL+ALT+DELキーを押すというものが挙げられる(現在でもポリシー設定で有効にできる)。この機能には、他のプログラムが特定のキーの組み合わせに反応できなくすることで、偽のロック画面が表示されることを防止するという目的がある。一方、KDEチームのMartin Gräßlin氏によると、X11は古すぎるためにX11上のスクリーンロッカーでは十分なセキュリティーを確保できないのだという。X11はプロトコルレベルでスクリーンロッカーを認識せず、Xサーバーはスクリーンがロックされているかどうかを判別できない。唯一のスクリーンロッカーとして動作する特権プロセスといったものは存在せず、他のプログラムがスクリーンロッカーと同様の動作をしたり、スクリーンのロックを妨げたりすることも可能だ。たとえば、コンテキストメニューを任意のウィンドウで開くだけで、スクリーンはロックされなくなるとのことだ。つまり、Xサーバーに接続している任意のプロセスがスクリーンロッカーをブロックすることが可能で、偽のスクリーンロッカーとしてふるまうことも可能ということになる。
Gräßlin氏はPlasmaの脆弱性修正に伴ってこの問題を認識し、Waylandベースのプロトコルを使用して問題を解決したとのことだ。
スクリーンロッカーで何が守れるのか (スコア:2)
それには、攻撃プログラムを起動できる脆弱性か、Xサーバーに許可なく遠隔で接続させうる脆弱性が必要になると思います。
そのような脆弱性が有るなら、スクリーンロッカーをいじらずとも、何でも可能な状態なのではないでしょうか。
Re: (スコア:0)
スクリーンロックを解除するためにはパスワード入力が必要です。
確かに何らかのプログラムが必要ですが、単に何らかのプログラムを起動しただけではパスワードを知ることは出来ません。
しかしロック画面を表示することで自然な形でパスワードを収集出来ます。
また一般ユーザ権限のプロセスでも、管理者ユーザのロック画面などに偽装することで、管理者権限を得ることが可能かもしれませんし、
共用PCならばログイン画面に偽装して他ユーザのパスワードを収集することも可能かもしれません。
＃そういった画面に偽装しなくても騙される人はいるからパスワード収集は可能ですが、偽装できればさらに効率は上がるでしょう。
＃ブラウザのアドレスバーやダイアログの偽装とかも類型と言えるかな？
NT系でCTRL+ALT+DELキーが必要なのは、これがプロセスによりトラップするなどで無効化できないものであるからです。
＃ということをユーザが知らなければ意味がないのですけれどね。
Re:スクリーンロッカーで何が守れるのか (スコア:1)
異なる機能のものを比較しても意味があるとは思えません。「NT系でCTRL+ALT+DELキーが必要」というのはローカルの話で、X は基本的にネットワークベースです。
Windows であってもリモートデスクトップ越しにスクリーンロッカーに見えるものを解除する時、Ctrl + Alt + End を受け取ったローカル側のプロセスが、正しいリモートデスクトップなのか、そういった画面に偽装したパスワード収集ソフトなのかを判別できないのではないでしょうか。
Re:スクリーンロッカーで何が守れるのか (スコア:1)
windowsはCtrl+Alt+Delのトラップを無効化してるので
偽のスクリーンロックを見破れますって話でしょ
Re: (スコア:0)
ええとですね、2015年の今現在Xをネットワークに生で流すことは推奨されていないのです。
XはデフォルトではUnixDomainしかlistenせず、tcp:6000を開けるならsshのポートフォワードを使うことが強く推奨されています。
Xはネットワークベース？古き良き時代はそうでした。今はローカルのレンダラですよ。
Re:スクリーンロッカーで何が守れるのか (スコア:3)
ロックされているように見える画面に対し、パスワードを入力する前に、正しい相手かどうかの識別を CTRL-ALT-DEL という特定のキーコンビネーションに反応するかどうかで判断する、というのはローカル OS などキーボードに対し絶対的な権限をもつものの設計としてしか意味がないのでは、という話です。Windows のリモートデスクトップにせよ、X にせよ、（X サーバと通信する）クライアントプロセスがロック解除のためのパスワードを処理するならば、ローカルのキーボードに頼ることはそもそもできないでしょう。
Wayland で UI を握って云々という話は、CTRL-ALT-DEL や Windows キー+電源ボタン並になることはあっても、本質的な解決とは思えません。
そもそも、問題の本質は、ユーザである人間が、パスワードを教えて良い正しいプロセスかどうかを「認証」するにはどうしたら良いか、ということです（別に認証が正しくてもキーロガー等で「盗聴」されているかも、という問題もありますが）。（ネットワークや多様なハードウェアを想定した）ハードウェアの仮想化、例えば Windows や iOS 上のアプリケーションから利用する、そもそも物理キーボードがない場合などを考えると、抜本的にはパスワードを使わずにGoogle Authenticator [wikipedia.org]などで TOTP 認証にするなど、別に「鍵」を用意するぐらいしか無いのは無かろうか。
Re: (スコア:0)
本質的にはそうかもしれませんが、次善の策として、rootで動き基本的にキーボードやディスプレイを握るXサーバが何らかの手立てを準備しても良いかと思います。
まあ、後段にも近いですが、ローカル、すなわちハードを触れる環境であれば間にロガーとかプロキシ的なハードを噛ますことが可能であり、OS含めソフトが絶対的権限を持ちえないともいえます。
UNIXはそういう観点に近かった気がします。
Re:スクリーンロッカーで何が守れるのか (スコア:2)
Re:スクリーンロッカーで何が守れるのか (スコア:1)
「トラップできない操作が存在するということを前提にした仕組みを、そのような操作が存在しない環境に導入しようとすると難しいよね。」
という話だと思うのですが「そうですね」以外にどう答えようもないので、あれこれ雑談するためには例えば、それが役立たない状況を想定してみるとかしないと続かないと思うのだけど、それでは駄目なの？
Re:スクリーンロッカーで何が守れるのか (スコア:1)
キー入力や画面の内容をキャプチャされない、特権モードのウィンドウがあればいいのかな。
ただ、それにはユーザが以下の事を理解して実行する必要があり、かなりの教育が必要になりそうですね。
1. パスワードを要求するウィンドウは「特権モード」である必要がある。
2. 特権モードでウィンドウを作成できるのは、あらかじめ設定されたプログラムだけ。
3. ウィンドウが特権モードかどうかは、ユーザが「特権を確認する操作」を行ない判断できる。
4. ユーザはスクリーンロッカーなどの、パスワードを要求するウィンドウには必ず「特権を確認する操作」を行なった上で、パスワードを入力しなければならない。
(パスワードを守ることで守られる物は何か、という問題もあります。
攻撃プログラムを実行された時点で、パスワードで守りたかった物があらかた盗られている可能性もあります。)
Re: (スコア:0)
Re:スクリーンロッカーで何が守れるのか (スコア:1)
そういったキーロガー的なプロセスにもフックされない「特権モード」を新に作れば解決するのかな、と思った次第です。
「特権モード」ウィンドウに対するイベントはキャプチャできないので、パスワードは盗れません。
「特権モード」ウィンドウのふりをしても、ユーザが「特権を確認する操作」をした時点でバレます。
Re: (スコア:0)
まず、WindowsはNTの時代から上記４点は実現されています。
そして、この話はオレンジブックなどにも載っているセキュリティの基礎、教科書レベルの話であって、今更議論するような内容ではありません。
Xは明らかに脆弱で時代遅れです。誤魔化すのはやめましょう。別にXやLinuxを攻撃する意図はありません。事実を受け入れましょうと言っているだけです。
我々にできることは現状を過信せず、Waylandのような新しいプロジェクトが頓挫しないようできることをするだけです。
Re:スクリーンロッカーで何が守れるのか (スコア:1)
「特権を確認する操作」として、Ctrl+Alt+Del があるという事でしょうか。
ユーザが理解して使っている限り、いい機能だと思います。
ただ「特権を確認する操作」は、本質的に難しいものだと思います。
パスワードを入力できるほど信用できるプログラムと、信用できないプログラムを、信用できないプログラムを起動してから見分けるという事ですから。
Ctrl+Alt+Del のような機能を、スクリーンロックだけでなく端末で sudo にパスワードを聞かれた時などにも適用しなければいけません。
私は X を擁護しているのではありません。
現状、信用できないプログラムの実行や接続を許した時点で、もう駄目だろうと思うだけです。
Xが時代遅れなのは事実でしょうね。Waylandなどには期待しています。
Wayland (スコア:2, すばらしい洞察)
Waylandの意義ってX serverというmiddle-manを無くすだけじゃなくて、こういったX protocolの危険性からより安全なプロトコルやコンポジタを作ろうってことにもあるから積極的にWaylandに移行してほしい。(KDEもGnomeもWaylandへの移行に積極的)
Re: (スコア:0)
エディタやメディヤプレイヤーなら、派生して競争したり
自分好みにカスタマイズしてもいいですが、こういう基本的なところに関わるものは
統一しておかないとまずいんじゃないかなと思います。
派生させたのはCanonicalなので、Waylandを責めるつもりはありませんが。
Re: (スコア:0)
まともに動くものさえ出来ればどっちでもいいよ。そういう意味じゃどっちも失格じゃね？
Re: (スコア:0)
FedoraやArch使ってるならGNOME 3.14がWaylandでさらにWaylandサポートが改善されて、クラッシュしたり使えないっていうことはなくなりましたが、それでも失格ですか? (あら削りなのは認めるが)
Re: (スコア:0)
正直Mirの分裂は痛いよね。
Canonicalには彼らの都合があるから仕方がないとしても、Ubuntuの離脱の影響は少なくはない。
足並みをそろえてWayland/Westonに移行してもらうのが、ユーザにとっても一般の開発者にとっても良かったと思うわ。
で、WinユーザはCtrl-Alt-Del打ってloginしてるの? (スコア:2)
最初は間違ったパスワードを入れるっていう解法もあるが。
Re: (スコア:0)
まあ、それは結局Ctrl-Alt-Del打つ意味理解してないと意味ない対策だし、ほかにパスワード搾取する方法はいくらでもあるし、ってことで、あまり重要ではないってことですね。
＃ただ、それを行う事が出来るかどうか、ってのはあるけど。
ちなみに、そもそもログインプロンプトを偽装してパスワード搾取する方法なんですが、もともとはUNIXのマルウェアというか、ログインスクリプトにログインプロンプト偽装するコード入れるって方法で、
正規のログインプロンプト→ユーザが正しいアカウント・パスワード入力→ログイン成功でログインスクリプトが走る→偽装されたログインプロンプト表示→ユーザは入力ミスと勘違いして再び正しいアカウント・パスワード入力→奪取成功
って流だったり。これだと「最初は間違ったパスワードを入れるっていう」のは解法じゃなかったり。
ま、CLIだからの事でGUIだとそうはいかないけど。
みんな知ってたんじゃないのか (スコア:1)
かなーり前のred hatからtcp:6000のlistenは止められていたし、
相変わらずMagic-Cookieしかセキュリティ機構と呼べるものはないし、
知ってて使ってるわけじゃなかったのか。
Re: (スコア:0)
これ。
X11に設計からどうだとか言われても、セキュリティ的にも使用帯域的にもLAN内部でしか使わない想定で作られたモノに対して設計思想が不味いなんて言い出したらどーしようもない。
sshのトンネリングがなければ経路の暗号化だってない。
XDMCP以外では、自分でXクライアントの起動を行えるインタフェースがないので、他のリモートアクセスプロトコルに依存しないといけない。自分でコントロールできないというのも設計上のセキュリティホールになりうる。
スクリーンロックだって、ロックされていることをXサーバが知らないというのが全て。CtrlAltDelとはレベルが違う。
くだらない (スコア:0)
仕事中に便所に行かなければいいだけのことだ。
Re:くだらない (スコア:5, おもしろおかしい)
くだらなければたしかにそれもできますが、くだっちゃったらそうも言ってられないですよね。
Re: (スコア:0)
便所で仕事すればいいんだよ。
Re: (スコア:0)
Re: (スコア:0)
クソみたいな職場だな。
Linux使わなきゃいいだけ (スコア:0)
くだらない
Re:Linux使わなきゃいいだけ (スコア:1)
Linuxだけの問題ではなく、Unix全般の問題だと思いますが…。
まぁ、ハイエンドのワークステーションもUnixからLinuxへの置き換えが進んでますけども。
Re: (スコア:0)
若干出遅れてる感じですが学術向けではUNIXからMacに移行してるってのをどこかで見た記憶
Re: (スコア:0)
しかしそれでは目的を果たせないかもしれない。
ここは Windows 上で Xサーバを動かす方向で。
いまどき誰が xhost + させるのか (スコア:0)
1980年代はXサーバーにXのクライアントをたくさんぶら下げて使うとか、流行りましたねぇ。今でもXming [osdn.jp]とかもあるようですが。脆弱性? いまどき xhost + しなきゃいいんじゃないの？
それとも、xhost + させて他人に使わさせているような UNIX機を、今回の指摘が問題になるようなクリティカルな用途で使うものかね?
そもそも、XだのKDEが無けりゃ操作できないようなド素人にサーバーを管理させている時点でセキュリティー的に安全じゃないだろうけど。そういう人間はおとなしく自分専用のマシンでOpenOffice + Firefox + Thunderbird 程度を使っとけばいいんじゃないの?
Re:いまどき誰が xhost + させるのか (スコア:1)
なんかずれてる。
1980年代はXサーバーにXのクライアントをたくさんぶら下げて使うとか、流行りましたねぇ。
今でもアプリ（Xクライアント）は複数使うのが普通ですが。
まあ、クライアントじゃなくホストなんでしょうけど。
それとも、xhost + させて他人に使わさせているような
普通それは自分で使うためにしてると思うけど。
これはxhostの様に別プロセス（アプリ)経由でなければ端末たるXサーバに働きかける手段がないってことかと。
せっかくUIデバイス握ってるのに。
Re: (スコア:0)
ずれてるんじゃなくて、多分基礎が分かってない。
X端末を多数つなげるのを「XサーバーにXのクライアントをぶら下げて使う」って思ってるんでしょ
Xを使ったことがある程度の初心者でこのトピックを理解するために必要な知識がないと思うよ
Re: (スコア:0)
確かに xhost を設定した覚えは無いですが、確認したところ
% xhost
access control enabled, only authorized clients can connect
INET:192.168.0.11 (←自分のIP)
INET:localhost
LOCAL:となりましたが、自分で使うのだから特におかしくはないと思いますが。
ところで元の Why screen lockers on X11 cannot be secure には
とあって、Xは1台の
Re: (スコア:0)
違う要素がかぶってる気がするな。
一つはXサーバが走ってるマシン（あなたはそれと物理的につながったディスプレイやマウス・キーボードで操作している）にリモートからログインしてる別のユーザがいて、さらにXサーバの設定が、
INET:192.168.0.11 (←自分のIP)
INET:localhost
これだとそのログインしてる別ユーザは自由にそのマシンのXサーバにアクセスできる＝つながってるディスプレイになんでも自由に表示でき、表示された内容を取得できる状態。
xhostによる制御にはユーザの概念がないので。
ただ、ウィンドウマネージャがあるので、そっちの制御を回避したりオーバーライドできるのかまでは分からない。
これはW
Re: (スコア:0)
ストーリで言ってるのは、 localhost で動いてるプロセスがロック中でも動作できる、ということでそ。それってウイルスが入った後にどうやって悪さするかという話だと思うんだけど、云々して意味があるのかな…
Re: (スコア:0)
偽のログイン画面で生のパスワード盗めるってのは大きいと思います。
まぁそれいうとgksudoだっけ、GUIのsudoなんかもあれなんだろうけど。
昇格とかの動作をユーザレベルの処理と切り替える機能が足りてない的な感じ？
WindowsだとUACでユーザアプリの操作を受け付けないモードに入って処理したりできるが、ああいう方面でちと弱いんじゃないかな。
Waylandのプロパガンダ？ (スコア:0)
別にX11ベースでも、Xサーバーが認識できる拡張プロトコルを新設すればいいだけのような．．．
互換性を保った上で拡張する仕組みはもとからあるわけだし。