Process Control

信頼できないプログラムやトランザクション、または信頼できない環境にプログラムコントロールが転送されると、アプリケーションが攻撃者に利用されて悪意のあるコマンドを実行する原因になることがあります。

Process Control の脆弱性には、次の 2 つの形態があります。

- 起動するプログラムの名前、または呼び出すトランザクションのコードを攻撃者が変更可能である。この場合、攻撃者はプログラムの名前またはトランザクションコードを明示的に制御することになります。

- プログラムを起動する環境、またはトランザクションを呼び出す環境を攻撃者が変更可能である。この場合、攻撃者は、起動したプログラムまたはトランザクションで利用可能になるコミュニケーションエリアを暗黙的に制御することになります。

この場合は主に最初のシナリオが懸念されます。つまり、起動するプログラムの名前、または呼び出すトランザクションのコードを攻撃者が制御できる可能性があります。このタイプの Process Control の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。



2. データが、起動されるプログラムまたは呼び出されるトランザクションコードを表す文字列 (またはその一部) として使用された場合。



3. アプリケーションは、起動されたプログラムやトランザクションのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えます。

例 1: 権限を必要とするシステム ユーティリティの次のコード引用では、HTTP リクエストから値が読み取られ、呼び出すトランザクションのコードが決定されています。

...
tid = request->get_form_field( 'tid' ).

CALL TRANSACTION tid USING bdcdata  MODE 'N'
                         MESSAGES INTO messtab.
...

攻撃者はこのコード部分を使用して、あらゆるトランザクションをコールでき、アプリケーションの昇格された権限で任意のコードを実行する可能性があります。このプログラムでは HTTP リクエストから読み取った値の検証が実行されないため、攻撃者がこの値を制御できる場合、アプリケーションを操って悪意のあるコードを実行し、システムを制御できます。

信頼できないソースから、またはそのような環境下でライブラリまたは実行可能ファイルをロードすると、アプリケーションが攻撃者に利用されて悪意のあるコマンドを実行することになる場合があります。

Process Control の脆弱性には、次の 2 つの形態があります。

- プログラムがロードするライブラリまたは実行可能ファイルの名前を攻撃者が変更可能である。この場合、攻撃者はライブラリまたは実行可能ファイルの名前を明示的に制御することになります。

- ライブラリまたは実行可能ファイルがロードされる環境を攻撃者が変更可能である。この場合、攻撃者はライブラリまたは実行可能ファイルの名前の意味を間接的に制御することになります。

この場合は主に最初のシナリオが懸念されます。つまり、ロードされるライブラリの名前を攻撃者が制御できる可能性があります。このタイプの Process Control の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。



2. データが、アプリケーションがロードするライブラリまたは実行可能ファイルを表す文字列 (またはその一部) として使用された場合。



3. アプリケーションは、ライブラリまたは実行可能ファイルのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えます。

例 1: 権限を必要とするシステム ユーティリティの次のコードは、アプリケーション構成プロパティ APPHOME を使用して、指定されたディレクトリからの相対パスに基づいてネイティブ ライブラリをロードします。

  ...
  string lib = ConfigurationManager.AppSettings["APPHOME"];
  Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
  ...

このコードは、悪意ある LIBNAME が含まれる別のパスを参照するようにアプリケーション構成プロパティ APPHOME を変更することにより、ライブラリまたは実行可能ファイルをロードして、任意のコードをアプリケーションの上位権限で実行することを攻撃者に許可します。このプログラムは環境から読み取った値の検証を行わないので、システム プロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

信頼されていないソースから、またはそのような環境下でライブラリをロードすると、アプリケーションが攻撃者に利用されて悪意のあるコマンドが実行される原因となる可能性があります。

Process Control の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するライブラリを攻撃者が変更可能である。この場合、攻撃者はライブラリの名前を直接的に制御します。

- ライブラリがロードされる環境を攻撃者が変更可能である。この場合、攻撃者はライブラリ名の意味を間接的に制御することになります。

この場合は主に最初のシナリオが懸念されます。つまり、ロードされるライブラリの名前を攻撃者が制御できる可能性があります。このタイプの Process Control の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションによりロードされたライブラリ名を表す文字列の一部として使用された場合。

3. アプリケーションはライブラリのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えます。

例 1: 次の例に示す権限が必要なアプリケーションのコードは、レジストリ エントリを使用してインストール先ディレクトリを決定し、指定したディレクトリからの相対パスに基づいてライブラリ ファイルをロードします。

	...
	RegQueryValueEx(hkey, "APPHOME",
                      0, 0, (BYTE*)home, &size);
	char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
	if (lib) {
		strcpy(lib,home);
		strcat(lib,INITCMD);
		LoadLibrary(lib);
	}
	...

このコード例では、攻撃者はレジストリキーを改変して悪意ある INITLIB を含む別のパスを参照させて任意のライブラリをロードし、アプリケーションの昇格権限を使ってライブラリのコードを実行できるようになっています。このプログラムでは環境から読み取った値の検証が実行されないため、攻撃者は APPHOME の値を制御できれば、アプリケーションを操作して悪意のあるコードを実行させることができます。

例 2: 次のコードは、ユーザーにインターフェイスへのアクセスを許可する Web ベースの管理ユーティリティから引用したものです。ユーザーはこのインターフェイスを介してシステム上にあるユーザー プロファイルを更新できます。このユーティリティでは、標準システムディレクトリに格納された liberty.dll という名前のライブラリを使用します。

LoadLibrary("liberty.dll");

しかしながら、このプログラムでは liberty.dll への絶対パスが指定されていません。攻撃者が liberty.dll という名前を付けた悪意のあるライブラリを、目的のファイルより優先順位の高い検索場所に配置し、Web サーバー環境ではなく攻撃者の環境でプログラムを実行できる方法を確立すると、アプリケーションによって信頼されたファイルの代わりに悪意のあるライブラリがロードされます。こうしたアプリケーションのタイプは昇格した権限で実行されるため、攻撃者の liberty.dll の内容は昇格した権限で実行され、攻撃者に完全なシステム制御の権限を与える可能性があります。

このタイプの攻撃は、絶対パスが指定されていない場合に、LoadLibrary() で使用される検索順によって可能になります。Windows の最近のバーションまで該当したことですが、現在のディレクトリがシステム ディレクトリより前に検索される場合は、攻撃者がローカルにプログラムを実行できても、このタイプの攻撃はそれほど影響はありません。検索順は使用オペレーティングシステムのバージョンによって異なりますが、新しいオペレーティングシステムでは次のレジストリキーの値によって制御されます。

HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

このキーは Windows 2000/NT および Windows Me/98/95 の各システムでは定義されていません。

キーが存在するシステムでは、LoadLibrary() は次のように動作します。
SafeDllSearchMode が 1 の場合、検索順序は次のようになります。
(Windows XP SP1 以降でのデフォルト設定、および Windows Server 2003。)
1. アプリケーションのロード元のディレクトリ。
2. システムディレクトリ。
3. 16 ビットのシステムディレクトリ (存在する場合)。
4. Windows ディレクトリ。
5. 現在のディレクトリ。
6. PATH環境変数にリストされているディレクトリ。
SafeDllSearchMode が 0 の場合、検索順序は次のようになります。
1. アプリケーションのロード元のディレクトリ。
2. 現在のディレクトリ。
3. システムディレクトリ。
4. 16 ビットのシステムディレクトリ (存在する場合)。
5. Windows ディレクトリ。
6. PATH環境変数にリストされているディレクトリ。

信頼できないアプリケーションプログラムや信頼できない環境にプログラムコントロールが転送されると、アプリケーションが攻撃者に利用されて悪意のあるコマンドを実行する原因になることがあります。

Process Control の脆弱性には、次の 2 つの形態があります。

- 起動するプログラムの名前を攻撃者が変更可能である。この場合、攻撃者はアプリケーションプログラムの名前を明示的に制御することになります。

- プログラムを起動する環境を攻撃者が変更可能である。この場合、攻撃者は、起動したプログラムで利用可能になるコミュニケーションエリアを暗黙的に制御することになります。

この場合は 1 つ目の状況、つまり呼び出すプログラムの名前を攻撃者が制御する可能性が最も懸念されます。このタイプのプロセス制御が発生するのは、次のような場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。



2.データは、呼び出されるプログラムを表す文字列の一部または全体として使用されるか、またはプログラムが呼び出される環境に対する何らかの制御を決定します。



3. アプリケーションは、起動されたプログラムのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えます。

例 1: 権限を必要とするシステム ユーティリティの次のコードは、ターミナルから値を読み取って、コントロールの転送先となるプログラムの名前を決定しています。

...
ACCEPT PROGNAME.
EXEC CICS
  LINK PROGRAM(PROGNAME)
  COMMAREA(COMA)
  LENGTH(LENA)
  DATALENGTH(LENI)
  SYSID('CONX')
END-EXEC.
...

攻撃者はこのコードを使用して、プログラムにコントロールを転送でき、アプリケーションの昇格された権限で任意のコードを実行する可能性があります。このプログラムではターミナルから読み取った値の検証が実行されないため、攻撃者がこの値を制御できる場合、アプリケーションを操って悪意のあるコードを実行し、システムを制御できます。

信頼されていないソースから、またはそのような環境下でライブラリをロードすると、アプリケーションが攻撃者に利用されて悪意のあるコマンドを実行する原因になることがあります。

Process Control の脆弱性には、次の 2 つの形態があります。

- プログラムがロードするライブラリ名を攻撃者が変更可能である。この場合、攻撃者はライブラリ名を明示的に制御することになります。

- ライブラリがロードされる環境を攻撃者が変更可能である。この場合、攻撃者はライブラリ名の意味を間接的に制御することになります。

この場合は主に最初のシナリオが懸念されます。つまり、ロードされるライブラリの名前を攻撃者が制御できる可能性があります。このタイプの Process Control の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。



2. データが、アプリケーションがロードするライブラリを表す文字列 (またはその一部) として使用された場合。



3. アプリケーションはライブラリのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えます。

例 1: 次のコードでは、現在ドキュメントに記載されていない Express の「機能」を使用して動的にライブラリ ファイルをロードしています。Node.js は、引き続き通常のライブラリ ロード パスでこのライブラリが含まれるファイルまたはディレクトリを検索します [1]。

var express = require('express');
var app = express();

app.get('/', function(req, res, next) {
  res.render('tutorial/' + req.params.page);
});

Express では、Response.render() に渡されるページが、未知の拡張機能のライブラリがあればロードします。これは通常、"foo.pug" のような入力であれば問題ありません。これはよく知られたテンプレート エンジンである pug ライブラリのロードを意味するためです。ただし、攻撃者がページを制御しているために拡張機能もその制御下にある場合、Node.js モジュールのローディング パス内でライブラリをロードすることを選択できます。このプログラムでは URL パラメーターから受け取った情報が検証されないため、攻撃者はアプリケーションを操って悪意のあるコードを実行し、システムを制御できます。

信頼されていないソースから、またはそのような環境下でライブラリをロードすると、アプリケーションが攻撃者に利用されて悪意のあるコマンドを実行する原因になることがあります。

Process Control の脆弱性には、次の 2 つの形態があります。

- プログラムがロードするライブラリ名を攻撃者が変更可能である。この場合、攻撃者はライブラリ名を明示的に制御することになります。

- ライブラリがロードされる環境を攻撃者が変更可能である。この場合、攻撃者はライブラリ名の意味を間接的に制御することになります。

この場合は主に最初のシナリオが懸念されます。つまり、ロードされるライブラリの名前を攻撃者が制御できる可能性があります。このタイプの Process Control の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。



2. データが、アプリケーションがロードするライブラリを表す文字列 (またはその一部) として使用された場合。



3. アプリケーションはライブラリのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えます。

例 1: 権限を必要とするシステムユーティリティの次のコードでは、システムプロパティ APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいてネイティブライブラリがロードされます。

	...
	$home = getenv("APPHOME");
	$lib = $home + $LIBNAME;
	dl($lib);
	...

このコードでは、悪意ある LIBNAME が含まれている別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はライブラリをロードしてアプリケーションの任意のコマンドを昇格された権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードでは dl() を使用して、sockets.dll という名前のライブラリからコードをロードします。これは、インストールや構成に応じて、さまざまな場所からロードされる可能性があります。

	...
	dl("sockets");
	...

ここでの問題は、dl() がロードされるライブラリの、パスではなくライブラリ名を受け取ることです。

攻撃者が sockets.dll の悪意あるコピーを、アプリケーションがロードしようとするファイルより前の検索場所に配置することが可能な場合、アプリケーションは目的のファイルの代わりに悪意あるコピーをロードします。アプリケーションの性質上、このバイナリは昇格された権限で実行されます。つまり、攻撃者の sockets.dll の内容もその昇格された権限で実行されるため、攻撃者はシステムを完全に制御してしまう可能性があります。

信頼されていないソースから、またはそのような環境下でライブラリをロードすると、アプリケーションが攻撃者に利用されて悪意のあるコマンドを実行する原因になることがあります。Ruby 内には、Process Control および Command Injection 攻撃の両方がよく発生する場所があります。

Ruby 内で Process Control がよく発生するのはコマンドが実行されるときです。このとき 2 つの異なる攻撃が可能になります。

1. Process Control
Process Control の脆弱性には、次の 2 つの形態があります。

- プログラムがロードするライブラリ名を攻撃者が変更可能である。この場合、攻撃者はライブラリ名を明示的に制御することになります。

- ライブラリがロードされる環境を攻撃者が変更可能である。この場合、攻撃者はライブラリ名の意味を間接的に制御することになります。

この場合は主に第 2 のシナリオが懸念されます。攻撃者は環境を制御してライブラリを指定し、悪意あるコピーをプログラムにロードさせることができる可能性があります。

1. 攻撃者はアプリケーションに対して悪意あるライブラリを提供します。

2. アプリケーションは、絶対パスを指定せず、ロードするファイルの検証もしないため、悪意あるライブラリをロードします。

3. アプリケーションはライブラリのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えます。

Windows プラットフォームでは、コマンドの実行に使用されるシェルが環境変数 RUBYSHELL または COMSPEC を介して選択されるため、Process Control は外部プログラムの実行時に発生する可能性があります。攻撃者が現在の環境内でこのいずれかの環境変数を変更できる場合、これらの環境変数で参照されるプログラムは、実行中の Ruby プログラムの権限で実行されます。

2. Command Injection
Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は主に第 2 のシナリオが懸念されます。攻撃者は環境変数を変更したり、悪意のある実行可能ファイルを検索パスの最初の方に置くことにより、コマンドの意味を変更できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 攻撃者がアプリケーションの環境を変更する場合。

2. アプリケーションが、絶対パスを指定しないか、実行されるバイナリを検証しないでコマンドを実行する場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: 次のコードでは Kernel.system() を実行して、通常は標準システム ディレクトリ内にある program.exe という実行可能プログラムを実行します。

...
system("program.exe")
...

この問題には 2 つの要素があります。
1. Windows プラットフォームでは、Kernel.system() は実行にシェルを使用します。攻撃者が環境変数 RUBYSHELL または COMSPEC を操作できる場合、変数から悪意のある実行可能プログラムを参照でき、それが Kernel.system() へのコマンドでコールされる可能性があります。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の program.exe もその権限で実行されるため、攻撃者はシステムを完全に制御してしまう可能性があります。
2. すべてのプラットフォームで、このシナリオの問題は、プログラムが絶対パスを指定しておらず、Kernel.system() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、program.exe という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の program.exe もその権限で実行されるため、攻撃者はシステムを完全に制御してしまう可能性があります。