PHP2Shell とは何か

Transcript

1. AIニュース（2026年10月） PHP2Shell とは何か PHP 本体の脆弱性と、今やること 赤神 青空
2. ▪PHP 本体の脆弱性で、外からコードを動かせる PHP2Shell とは PHP Shell：PHP 本体にあった、2つの脆弱性 認証なしで、外からサーバーの上でコードを動かせる（リモートコード実⾏） CVE- - CVE- - 深刻度 9.2（CVSS v . ） アプリのバグではなく、PHP そのものの⽳ PHP は、サーバー側の⾔語が分かっている Web サイトの約7割で使われている （W Techs の集計） 名前の「Shell」は、サーバー上で命令を動かせる、という意味 今ココ はじめに 2/18
3. ▪AI を使ったコードの監査から どうやって見つかったか 7⽉末〜8⽉ AI を使った コードの監査で⾒つかる 8⽉〜9⽉ 複数のチームが PHP に報告 約70⽇ 最初の報告から 修正版の公開まで ⾒つけた⼈たち（それぞれ別に⾒つけた） ‧Calif：OpenAI の「Patch the Planet」の取り組みの中で監査 ‧Wiz：Gemini Argon‧GPT- . Sol と、⾃社のツールを使って監査 ‧OpenAI の Codex Security も、同じ原因を報告 AI だけで⾒つけた、とは⾔えない。Calif は⼈が仮説を⽴てて AI に調べさせた 今ココ はじめに 3/18
4. ▪修正版が出る前から、攻撃は始まっていた 何が起きたか 10⽉17⽇ 10⽉20⽇ 10⽉21⽇ 10⽉26⽇ 攻撃の試みが 観測される 詳細が漏れ、 PHP が修正版を予告 修正版を 前倒しで公開 CISA が 「悪⽤あり」に登録 Amazon の観測 公開は22⽇の予定だった ⽇本時間では21⽇の夜 ⽶国の政府機関の⼀覧 修正版が出る前から、攻撃は始まっていた 直す側と攻める側が、ほぼ同時に動いている 今ココ はじめに 4/18
5. ▪差分を見れば、穴の場所が分かる 修正より先に情報が出た 修正したコード が出る 何を直したか （差分）を⾒る ⽳の場所が 分かる 攻撃の⽅法を 組み⽴てる 修正の公開は、攻撃する側にとっても⼿がかりになる 今回起きたこと（報道による） ‧予定より前に、詳細が SNS などに漏れた ‧⼀部の配布元が修正済みのビルドを先に出し、差分が⾒えた ‧正式な公開の前に、攻撃のコードや解説が出回り始めた 修正版が出た時点で、攻撃の準備ができていた可能性がある 今ココ はじめに 5/18
6. ▪作りかけのデータを、後片付けが使ってしまう 穴1：メモリ不足で壊れる CVE- - ：メモリが⾜りなくなったときの壊れ⽅ リクエストの 準備をする 途中で メモリが⾜りなくなる データが 作りかけで残る 後⽚付けの処理が それを信じて使う 攻撃する側は ‧わざとメモリが⾜りなくなるリクエストを送り、壊れた状態を作る ‧Apache の mod_php では、アプリのコードが動く前に起こせる ‧mod_php では1回のリクエストで1回試せる（成功するかは条件しだい） 2024年の監査で兆候は⾒つかっていたが、悪⽤の⽅法が⽰されず直っていなかった 今ココ 2つの穴 6/18
7. ▪同じワーカーの次のリクエストで使われる 穴2：前のリクエストの状態が残る CVE- - ：前のリクエストの状態が残る リクエスト1 リクエスト2（同じワーカー） 使い終わってメモリを返したのに、 その場所を指す状態が残る 残った状態を使ってしまう （解放後のメモリを使う） コードの実⾏だけでなく、メモリの中⾝も読まれうる 認証なしでワーカーのメモリを読めることが実証された。パスワードやトークンも含まれうる （Qualys の解説による） 今ココ 2つの穴 7/18
8. ▪動かし方も、フレームワークも問わない どこが影響を受けるか Web のリクエストを受けている PHP は、どの動かし⽅でも対象 PHP-FPM Apache mod_php php-cgi LiteSpeed FrankenPHP mod_php がいちばん急ぎ：アプリのコードが動く前に攻撃が成り⽴つことがある 対象の版：PHP . （2012年）から 8.5 まで 10年以上前の版から、ずっと⼊っていた フレームワークやアプリが何でも関係ない （WordPress‧Laravel‧⾃作のコードも、下で動く PHP が古ければ対象） 今ココ 2つの穴 8/18
9. ▪条件しだいで成功している 攻撃は難しい、でも 攻撃の難しさは「⾼い」 それでも成功の報告がある メモリの並び⽅‧ビルド‧ どのワーカーが受けるか、 で成否が変わる 10⽉24⽇、3台のおとりのサーバー （PHP . . ‧mod_php）で 合わせて35回、シェルの実⾏に成功 ワーカーが多く、アクセスが多い サーバーほど、試す回数が増える 攻撃に都合のよい構成だった、と 報告した⼈⾃⾝が注意している 今ココ 悪用の状況 9/18
10. ▪探りが多いが、CISA 悪用の状況 も悪用を確認した Delft ⼯科⼤学の観測（The Register の報道） 5万件超 攻撃のリクエスト 600超 送ってきた IP アドレス 攻撃のコードまで送った IP 10⽉26⽇：CISA が2つとも「悪⽤が確認された脆弱性」に登録 ⽶国の政府機関は、10⽉29⽇までに直すよう求められている ほとんどは探りや失敗した試み。ただ、成功の報告も出てきた どの組織が被害を受けたかは、公表されていない 今ココ 悪用の状況 10/18
11. ▪サポート中の4つの系列に修正版が出た 直った版 サポート中の版：この版以上に上げる 8.5 系 .. 8.4 系 .. 8.3 系 .. 8.2 系 .. サポートが切れた版 ‧7.4‧8.0‧8.1：公式の配布物はなし（ソースの修正だけ公開） ‧7.3 以前：PHP からの修正はない → サポート中の版に上げるか、ディストリや延⻑サポートの修正版を使う Qualys の顧客の環境では、PHP の約7割がサポートの切れた版だった 今ココ 対策 11/18
12. ▪番号・再起動・別の不具合 上げるときの注意 ディストリのパッケージは、版の番号で判断しない 修正だけを取り込んで、番号は古いままのことがある。配布元のお知らせを⾒る ⼊れ替えたら、PHP のワーカーを再起動する 動いているプロセスは古いまま。PHP-FPM や Apache を再起動して初めて効く 8.4.27‧8.5.12 には、別の不具合がある SimpleXML を使う⼀部のアプリで落ちることがある（10/26 時点で、修正の⼊った版はまだ出ていない） 今ココ 対策 12/18
13. ▪設定の変更は時間稼ぎ 設定で防げるか PHP の⾒解：設定を変えるだけでは、完全には防げない 完全な対策は、修正版に上げることだけ すぐに上げられないときの時間稼ぎ（PHP や各社の解説が挙げた例） ‧session.upload_progress.enabled = （109619 の経路を減らす） ‧メモリの上限を外し（memory_limit = - ）、POST の⼤きさを絞る（109618 向け） ‧外からのアクセスを絞る、サービスを切り離す WAF のルールも時間稼ぎ。すり抜けようとする攻撃も報告されている 上げられないサーバーには、誰がいつまでに上げるかを決める 今ココ 対策 13/18
14. ▪10月21日の修正版では直っていない、別の穴 続報：CVE-2026-115560 10⽉23⽇：PHP が、別のリモートコード実⾏の⽳を告知 CVE- （セッションのアップロード進捗の機能） 21⽇の修正版では直っていない ① 設定でセッションの保存形式を php_binary か php_serialize にしている ② コードの中で、session_start() の前に ini_set() で php に切り替えている ③ セッションのアップロード進捗が有効（既定は有効） 3つそろうのはまれ。対策は session.upload_progress.enabled = 修正は次の定期リリースで。悪⽤の報告は、今のところない 今ココ 対策 14/18
15. ▪上げる、再起動する、確かめる 自分のサーバーで確かめること PHP の版を確かめて、修正版に上げる 外に公開しているサーバーから。とくに Apache の mod_php ワーカーを再起動して、版が変わったことを確かめる 上げられないなら、upload_progress を切り、アクセスを絞る レンタルサーバーなら、事業者のお知らせを⾒る 攻撃は10⽉17⽇から⾒られている。その⽇からのログも⾒ておく 今ココ 対策 15/18
16. ▪設定ではなく、版を上げて再起動するのが唯一の完全な対策 まとめ PHP 本体の⽳で、認証なしでコードが動く 何が 版を上げて、ワーカーを再起動する 対策 CVE- 続報 Web で動く PHP なら動かし⽅を問わず対象。CISA も悪⽤を確認した 8.5.12‧8.4.27‧8.3.36‧8.2.35。設定の変更だけでは防げない - は別の⽳ まれな設定のときだけ。upload_progress を切って次の版を待つ 今ココ まとめ 16/18
17. ▪一度止めて考えてみてください。答えは次のページで 今回のクイズ PHP2Shell への対応で、唯一の完全な対策とされているのはどれ？ A php.ini の設定を変え る 今ココ まとめ B 修正版に上げて、ワー カーを再起動する C WAF で怪しいリクエ ストを止める D アプリのコードを見直 す 17/18
18. ▪設定の変更だけでは防げない。版を上げて、再起動して初めて効く クイズの答えは「B」 今回のクイズ PHP Shell への対応で、 唯⼀の完全な対策と されているのはどれ？ PHP は、設定を変えるだけでは 完全には防げないとしている。 版を上げて、再起動して初めて効く 答えは B 今ココ まとめ の設定を変える A php.ini 設定は時間稼ぎで、完全には防げない B 修正版に上げて、ワーカーを再起動する PHP が挙げる唯⼀の完全な対策 で怪しいリクエストを⽌める C WAF 時間稼ぎ。すり抜けようとする攻撃もある D アプリのコードを⾒直す ⽳は PHP 本体。アプリのコードが動く前に起こりうる 18/18