【入門編】OSコマンド実行時の環境変数汚染リスク – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは。セキュリティの世界へようこそ。

現場でバリバリコードを書いているエンジニアから「コマンド実行なんて、引数を適切にエスケープすれば大丈夫でしょ？」なんて言葉を聞くことがありますが、私はいつも心の中で「甘いな」と苦笑いしてしまいます。

今日は、多くの開発者が「盲点」にしがちな「環境変数（PATH）を悪用した攻撃」について、身近な例えを交えながら、現場のリアルな視点で紐解いていきたいと思います。

—

まずは、OSコマンドを実行する時の「PATH（パス）」という仕組みを、皆さんの家の「玄関」に例えてみましょう。

皆さんが「ls」や「git」というコマンドを打つとき、OSはどこにあるプログラムを動かせばいいのか迷子にならないよう、あらかじめ「このフォルダの中を探せば、目的の道具（バイナリ）があるよ」という「道具箱の場所リスト」を持っています。これが「PATH」です。

攻撃者は、この「通り道」の仕組みを悪用します。

もし、泥棒があなたの家の敷地内に、「本物の道具箱」よりも先に「偽物の道具箱」を置くことができたらどうなるでしょうか？

1. あなたが「ls（ファイル一覧を見せる道具）」を使おうとする。
2. OSはPATHの順番に従って、最初にヒットした場所にあるプログラムを実行する。
3. 攻撃者が配置した「偽物のls（実は悪意あるスクリプト）」が起動する。

これが環境変数汚染の恐ろしさです。プログラム自体は「自分は正しいlsを呼んだ」つもりでも、実行環境が書き換えられていれば、知らぬ間に裏で攻撃者のプログラムが動いてしまうのです。

—

では、どうすればこの攻撃を防げるのでしょうか？答えはシンプルですが、徹底するのが難しい「フルパス指定」です。

良くない例：システムがPATHを検索して実行する
これだと、攻撃者がPATHを汚染していれば偽物が動く可能性があります
exec(“ls -l /var/www/html”);

// 良い例：実行ファイルの場所を「完全な住所」で指定する
// これなら、PATHがどう汚染されていようと、絶対に本物のバイナリが実行されます
exec(“/bin/ls -l /var/www/html”);

このように、誰が何と言おうと「ここにあるこれを使う！」とフルパスで指定することで、泥棒が通り道に偽物を置いても、あなたは「住所」を知っているため、確実に本物の道具にたどり着くことができます。

—

フルパス指定以外にも、私たちがインシデント現場で必ずチェックする「防衛ライン」があります。

プログラムを実行する際、環境変数（$_ENVなど）をあえて空にする、あるいは必要な最小限のPATHだけに制限して実行する工夫をしましょう。

// PHPでの例：環境変数をクリアして実行する
$descriptorspec = [
0 => [“pipe”, “r”],
1 => [“pipe”, “w”],
2 => [“pipe”, “w”]
];

// 実行時に環境変数を指定する（PATHを最小限にするなど）
$env = [“PATH” => “/usr/bin:/bin”];
$process = proc_open(‘/bin/ls’, $descriptorspec, $pipes, null, $env);

そもそも、ユーザーからの入力値をコマンドの引数にそのまま渡していませんか？
もしどうしてもコマンドを実行する必要があるなら、「ホワイトリスト方式」を採用してください。「許可された引数リスト」以外は一切受け付けない、という門番を置くのです。

悪い例：exec("rm " . $_GET['filename']);
良い例：$allowed = ['file1.txt', 'file2.txt']; if(in_array($input, $allowed)) { ... }

—

セキュリティ対策とは、完璧な鍵を一つ買うことではなく、「もし侵入されたら？」「もし通り道がすり替えられたら？」と、最悪の事態を想定して二重三重の備えをすることです。

OSコマンド実行は非常に強力ですが、その分リスクも高い。だからこそ、開発する際は「このコマンドは本当に安全な場所から呼ばれているか？」と、常に疑いの目を持ってください。

最初は面倒に感じるかもしれませんが、その「一手間」が、将来あなたやあなたの会社を大きなインシデントから救うことになります。一歩ずつ、着実に堅牢なシステムを作っていきましょう！

また次回の記事でお会いしましょう。質問があればいつでもコメントしてくださいね。