Mac OS Xのターミナルの「セキュアキーボードエントリ」はどのくらい安全ですか？
私は何年もMac OS Xでターミナルを使用してきましたが、どういうわけかこの機能を見つけることができませんでした：
これは実際にはどのように機能するのでしょうか？100％安全ですか？そうでない場合、キーストロークを取得するためにどのようなテクニックを使用できますか？
「Secure Keyboard Entry」は、概念が説明されているEnableSecureEventInput関数にマップされます here 。基本的に、アプリケーションはハードウェア自体にアクセスしません。彼らはオペレーティングシステムからevents（例えばキーストロークについて）を取得します。 OSの一部の要素は、アクセス権とGUIの状態に応じて、どのアプリケーションがどのイベントを取得するかを決定します（「フォアグラウンド」にあるアプリケーションに応じて詳細があります）。
アプリケーションは相互に「スパイ」できます。つまり、（この場合）マシン上で実行されているアプリケーションは、他のアプリケーション向けであっても、すべてのキーストロークのコピーをOSに送信したり、挿入したりすることができます。独自の合成イベント。これはfeatureです。「パスワードウォレット」（アプリケーションの観点から、ユーザーが入力したかのようにパスワードを入力する）または「キーボードビューア」（マウスで文字を「入力」できるGUIベースのキーボードで、いつでも実際に押されているキーを表示します）。 EnableSecureEventInputは、この機能を呼び出すアプリケーションに対してこの機能をブロックします。それを試してみてください ！ Terminal.appを実行し、「キーボードビューア」を有効にします。「セキュアキーボードエントリ」を有効にすると、キーボードビューアが機能しなくなることがわかります。
これらすべてのイベントルーティングは、rootとして実行されるいくつかのユーザー空間プロセスで行われます。これは依存カーネルによって強制されるプロセス分離に関するものです。通常のユーザープロセスは、ルートプロセスに割り当てられたメモリを思いのままにいじることはできません。カーネル自体は、「イベント」のユーザーレベルの概念を認識していません。イベントの管理、特にEnableSecureEventInputの強制（または強制ではない）は、カーネル以外のコードによって行われます。
上記のリンクの興味深い抜粋は次のとおりです。
EnableSecureEventInputの元の実装では、プロセスが安全な入力エントリを有効にし、キーボードフォーカスがある場合、キーボードイベントがインターセプトプロセスに渡されませんでした。ただし、セキュアエントリプロセスがバックグラウンドに移動された場合、キーボードフォーカスはセキュアエントリプロセスではなくなったため、システムは引き続きこれらのインターセプトプロセスにキーボードイベントを渡します。最近、セキュリティホールが発見され、安全なイベント入力が有効で、安全なイベント入力プロセスがバックグラウンドにある場合でも、傍受プロセスがキーボードイベントをキャプチャできるようになりました。この問題の修正は、プロセスがフォアグラウンドまたはバックグラウンドにあるかどうかに関係なく、任意のプロセスが安全なイベント入力を有効にしたときはいつでも、インターセプトプロセスへのキーボードイベントの受け渡しを停止することです。つまり、安全なイベント入力を有効にし、プログラムの実行中は安全なイベント入力を有効にしたままにするプロセスは、安全なイベントプロセスがバックグラウンドに移動した場合でも、すべてのキーボードインターセプトプロセスに影響を与える可能性があります。
これは、イベントルーティングシステムが機能の最初の記事で実際に間違ったことを意味します。これは修正されることになっています。
イベントルーティングが適切かつ安全であることを前提としても、つまりEnableSecureEventInputのセマンティクスが実際に適用されている場合、これはプロセス分離システムと完全に関連しています。すべてのルートプロセスは、他のすべてのプロセスのメモリを自由に検査して変更でき、特にすべてのイベントを確認できます。また、ルートプロセスはカーネルにフックして、イベントの概念を完全にバイパスしてキーボードから実際のデータを検査することもできます。 rootとしてインストールできるキーロガーはそれを行うだけであり、「Secure Keyboard Entry」はそれに対して無防備になります。オープンソースの概念実証については this を参照してください。
したがって、「Secure Keyboard Entry」は、マシン上で独自のコードを実行できる攻撃者に対してのみ安全ですが、ローカル権限をルートレベルに上げることはできません。ローカル権限の昇格は一般的に可能になる傾向があるため、これはかなり制限的なシナリオです。
ローカルプロセスは多くのマシンを認識できるため、その場合、防御する「セキュリティ境界」は巨大です。 remote攻撃者からの侵入を防ぐのははるかに簡単ですが、それでもすでにかなり困難です。
Appleは、ローカルの特権昇格ホールの場合、いくつかの 反応の欠如 を示す傾向があります。
要約：「Secure Keyboard Entry」が、たとえば公共の共有コンピュータのキーロガーに対して十分なセキュリティを提供すると信じるのは、あまりにも楽観的です。これは悪い機能ではありませんが、ルートとカーネルに悪意のある変更がない場合にのみその約束を果たします。これは非常に大きな「if」です。
心に留めておく価値のある他の考えがいくつかあります。そして、私には広く認識されていません。POSIXシステムでは、どの端末にも独自の「テレタイプ」デバイスがあります。そして、実行するすべてのプロセスは、「セキュアキーボードエントリ」を有効にするかどうかに関係なく、そのデバイスから読み取ることができます。（LinusÅkessonが nixシステムが端末デバイスを処理する方法 。）
そのようなデバイスの名前と権限はシステムによって異なります。 macOSは、バージョン10.14以降、それらにtty[p-w][0-f]{1,3}そして、ターミナルを実行するユーザーに読み取り/書き込みアクセス権を付与します（およびttyグループのメンバーに書き込み専用アクセス権を付与します）。
たとえば、iTerm.appで「Secure Keyboard Entry」をアクティブにし、ttyを呼び出して端末デバイスを表示することで、これを自分で試すことができますそれは使用していて、たとえばTerminal.appを開いて、catを使用してそのデバイスから読み取ります。 iTerm.appがいくつかの文字を受け取り、Terminal.appであることがわかりますその他。
