2018年12月25日に初出の投稿

Last modified: 2018-12-25

In the past days a vulnerability was discovered in **imap_open** function ([CVE-2018-19518](https://www.cvedetails.com/cve/cve-2018-19518)). The main problem with this issue is that a local user can abuse this vulnerability to bypass some restrictions in hardened servers, and execute OS commands, because this function usually is allowed. This kind of bypass is similar to the one based in ShellShock: someone can inject OS commands inside functions not banned by disable_functions. I wanted to find a way to discover similar bypasses in an automated way.

Searching systematically for PHP disable_functions bypasses

PHP の処理系を安全に運用する基本的なアイデアの一つは、不要なモジュールを読み込まないことや、不要なビルトイン関数を無効にすることだ。特に、exec() のようなプロセス制御関数や file_get_content() のようなファイルシステム関数など、関数そのものというよりも関数を実行するための仕組みに間違いがあるとサーバやコンテンツへ重大な障害が発生し得る関数については、運用するアプリケーションで使う必要が無いとはっきり分かっていれば、php.info の disable_functions ディレクティブに登録して動作しないようにしておくことが望ましい。もちろん、LiteStep でお世話になった O_SAKANA TARO さんのエントリーにもあるように(https://blog.osakana.net/archives/8708)、php をコマンドラインで実行できる状況では、d オプションで disable_functions ディレクティブを無効にしてしまえるため、PHP という処理系の内部だけを保護しても十分ではない。しかし、ひとまず基本はマルチレイヤ―での防御であるから、最初に disable_functions に「phpinfo, eval, system, exec, passthru, popen」といった関数を登録しておくことは推奨してよい。実際のところ、僕がこれまでに従事した(主に関西の)上場企業や大企業の案件で入った「客先サーバ」のうち、PHP が動作する環境で phpinfo() が抑止されているサーバなど一つもなかったわけだが、そんな愚かな実状に歩調を合わせる必要はない。ちゃんと関係各所へ説明して実施すればいいだけのことだ。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook