CVE-2016-5385の様に、module方式に比べてCGI方式の方が脆弱性のリスクが高いという印象を持っています。
その前提が正しければ、なぜCGIの方がセキュリティリスクが高いかご教示頂けませんでしょうか。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答2件
0
PHPを前提に記述します。確かに、Apacheモジュール版のPHPでは問題にならないのにCGI版では問題になるという脆弱性はいくつか存在します。原理的にはその逆もあり得るはずですが、現実にあるかどうかは思いつきません。
では、なぜCGI版固有の脆弱性が出ているかというと、以下のようなシナリオであると思います。
- CGIの場合、コマンド引数の解析を行う必要があり、そこにバグがあった(CVE-2012-1823等)
- PHPからコマンド呼び出しやメール送信の際にシェルが介在し、シェルの脆弱性が影響した(ShellShock)
CVE-2012-1823のような「コマンド引数の解釈」はApacheモジュールでは存在しないので発生し得ません。
ShellShockの方は、CGIモードのPHPの場合は、CGIのためにセットされた環境変数が、PHPから起動されたコマンドにも引き継がれるために、CGIモードの場合に影響がでる結果となりました。Apacheモジュール版では、この「CGI環境変数の引き継ぎ」は起きません。
しかし、だからと言って、「CGIはモジュール版にくらべてセキュリティリスクが大きい」とまでは言えないと思います。上記はいずれも実装上のバグが原因であり、しかも度々発見されるというほどでもないからです。ちょっと例えはよくないですが、「SQLインジェクションは深刻な脆弱性であるし、SQLを使わなければSQLインジェクションの心配はないので、SQLを使わないようにしよう」という意見はあまり見かけないわけで、CGIを使うべき正当な理由があれば、CGIを避けるほどの問題ではないということです。
ただし、CGIを使う正当な理由があるケースがどれほどあるかというと、あまりないと思います。レンタルサーバーの多くはCGIモードのPHPが提供されていますが、それはsuEXECとの組み合わせで、レンタルサーバーのユーザーの権限でPHPを動かすためにそうしているわけで、いわばセキュリティ上の理由(必然性)からCGIモードのPHPを使っているわけです。これ以外の局面では、主に性能上の理由から、(FastCGIでない)古典的なCGIを使う局面はありまないと思います。
まとめると以下の通りです。
- CGI環境でのみ発生する脆弱性は確かにある
- しかし、CGIを避けるほどのリスクではない
- CGIを使うかどうかの判断は、CGIを使う必然性によるものであり、CGI環境でのみ起こる脆弱性の問題は、全体からすると小さな問題である
投稿2017/06/26 00:39
総合スコア11701
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/06/29 14:16
0
ベストアンサー
まず、CVE-2016-5385はCGIのみが影響を受ける脆弱性ではありません。モジュール版PHP(mod_php)もPHP-FPMも脆弱性の影響にあります。これをもってCGIの方が脆弱であるとは言えません。
私の記憶する限り、PHPでCGIのみ対象だった脆弱性で有名なのは2012年に発見されたCVE-2012-1823とCVE-2012-2311(この二つは実質同じで、CVE-2012-1823の修正が不十分だったためCVE-2012-2311が残ったという形です。詳細はPHP の脆弱性に関する注意喚起を参考にしてください)ぐらいです。他にCGIが大きく影響を受けた脆弱性は2014年のShellShockがありますが、こちらもCGIは影響を受けやすいと言うだけで、モジュール版PHPであれば必ず安全であるとは言えなかったはずです(影響を受けるかはアプリの作りによる)。どちらも「リモートから任意のコード実行」という極大の脆弱性だったため印象が強いですが、CGIの仕組み自体に根本的な脆弱性があったというわけではありません。
CGIはWeb技術の初期からある仕組みです。標準入出力と環境変数のみでHTTPサーバーとやりとりするという方法で、極めて単純であり、それ自体が脆弱ではありません。むしろ、単純であるが故に、リクエストをそのまま渡していたと言うこと、リクエストから生成された情報が信頼できないと言うことに対する考慮はCGIのプログラム側がしなければならないと言うことです。ただ、これはCGI以外でも言えることであり、どのような方式であれ、リクエストから生成された情報であるかどうかの意識を持ってWebアプリを作る必要があります。ただ、スクリプトのコードではどうしようもない所、つまり、スクリプトのコードを動かすPHP本体やシェル自体で、その信頼できない情報を信頼できない情報として正しく処理できなかったというのが、PHP-CGIの脆弱性やShellShockだったと言うことです。
投稿2017/06/25 11:36
編集2017/06/25 11:39総合スコア21733
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/06/25 13:05
2017/06/25 15:27
退会済みユーザー
2017/06/29 14:12
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。