# オープニング #寒暖差対策を始める どうもー、セキュリティジョッキーの松戸です。 6回目のセキュリティ会社企業を目指して、サイバーセキュリティの最新ニュースについて解説しております。 ということでね、今日は寒寒差対策を始めるに関する話なんですけども 最近急にまた暑くなりまして ところによって30度ですか、10月末にまさかの真夏日という状況なわけなんですけども 現在僕が減量をしていまして、そうするとですね 代謝が下がってしまうんですね。その影響がありまして 寒暖差にですね、体が対応できないというようなことが起こっています 逆を言えばですね、その代謝をしっかりと維持していればですね 寒暖差対策、それほど難しくないんじゃないかなと思っていまして よく食べて、よく寝るということですね。これをしっかりとやっておけばですね 代謝は一定レベル維持できるんじゃないかなと思っています 暑くなれば汗をかいて放熱すると、寒くなればですね 水から発熱するというようなことですね 本来人間として当然備わっている機能なはずなんですけども それに抗ってしまったというかですね 減量を現在しておりますので、本来ですねそのダイエットはいいんですけども 必要以上に絞らなければいけないと 11月3日のですね草刑版までの我慢です 引き続き頑張っていきたいと思います ということで今回はプログラミング言語PHPに見つかった 重大な脆弱性について取り上げております この放送を通じてリスナーの皆さんはどのような仕組みの脆弱性なのか そしてすぐに更新できない場合に何ができるのかについて 理解を深めていただければと思います それではどうぞ # PHPに認証不要でリモートコード実行が可能になる重大な脆弱性、直ちに更新を呼びかけ PHPに認証不要でリモートコード実行が可能になる重大な脆弱性、 直ちに更新を呼びかけ。 PHPプロジェクトは10月21日、認証不要でリモートコード実行が可能になる 2件の重大な脆弱性を修正したPHP 8.5.12などを公開した。 こちらの記事を簡単に解説お願いできますでしょうか。 はい。PHPプロジェクトは10月21日にPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。 この更新では、認証なしでリモートコード実行が可能になる 2件の重大な脆弱性が修正されています。 影響を受けるのは、PHP FPMやApacheのModPHPなど、 ウェブのリクエストを処理する全てのPHP環境です。 特にModPHPでは、アプリケーションのプログラムが動く前に、 攻撃が成立する実証コードも確認されています。 1件目は、メモリ不足の処理中に内部データが不完全なまま残ることが原因です。 2件目は、解放済みのメモリ上の情報が次のリクエストで使われてしまうことが原因です。 対策は、修正範囲の更新です。 完全な回避策はなく、更新だけが安全な選択だと説明されています。 Linuxの提供元には、事前に修正が渡されていますが、 自分で組み立てた環境では、手動での更新が必要です。 リモートコード実行とは、どのような被害につながるのでしょうか? はい。リモートコード実行とは、外部の攻撃者が遠隔から相手のサーバー上で 好きなプログラムを動かせてしまう状態のことです。 サーバーはログインなどの認証がいらないため、 インターネットに公開されたサーバーなら、誰でも攻撃の対象になり得ます。 成功すると、サーバー内の情報の盗み出しや、ウェブサイトの改ざん、 さらに別の攻撃の踏み台にされる恐れがあります。 ですから、影響の大きい、最も警戒すべき種類の脆弱性なのです。 メモリ不足の処理や古い状態が使われるというのは、どういうことでしょうか? はい。プログラムは、動くたびにメモリという作業場所を借りて、 使い終わったら返しています。 2件目は、その作業場所が足りなくなって処理が中断されたとき、 準備の途中のデータが正常なものとして扱われてしまうものです。 2件目は、すでに返したはずの作業場所の情報が残り、 次のリクエストで使われてしまうものです。 どちらも、内部の状態の食い違いを攻撃者がつくことで、 プログラムの流れを乗っ取られる点が共通しています。 具体的には、どのバージョンに更新すればよいのでしょうか? お使いのバージョンの系列に合わせて、 8.5Kは8.5.12、8.4Kは8.4.27、8.3Kは8.3.36、8.2Kは8.2.35に更新します。 LinuxのディストリビューションやLTSの提供元を使っている場合は、 事前にパッチを受け取っているため、各社の更新パッケージを確認してください。 なお、PHP 8.1以前は、PHPプロジェクトとしての更新が終わっています。 提供元が独自に修正を出している場合もあるので、 連絡して確認するか、対応バージョンへの移行を検討しましょう。 ソースからビルドする方向けには、 7.4、8.0、8.1用の最小限の修正も特例として用意されました。 すぐに更新できないときは、何をすればよいのでしょうか? はい。まず前提として、これらは被害の可能性を減らす手段であり、 安全にするものではありません。 例えば、1件目には、メモリの上限を無制限に設定し、 リクエストのサイズを小さくする方法があります。 2件目には、セッションのアップロード進捗の機能を無効にして、 すべてのワーカーを再起動する方法があります。 PHP発展後では、致命的エラージの詳細表示を止める設定も一部の経路を防ぎます。 さらに、ウェブサーバーやプロ機種の側で、リクエストの大きさや項目数を制限することも有効です。 その間も、更新の準備を最優先で進めてください。 この件から、私たちはどのような教訓を学べばよいでしょうか? はい。1つ目は、自社でPHPが動いているサーバーをすべて把握しておくことです。 ブログやCMSの裏側で、気づかないうちに動いている場合も多いからです。 2つ目は、サポートが終わったバージョンを使い続けないことです。 緊急時に、公式の修正を受け取れなくなってしまいます。 3つ目は、緊急の更新を素早く適用できる手順と担当者を日頃から決めておくことです。 更新の遅れが、そのまま攻撃を受ける時間になります。 また、更新後もサーバーのログを見直し、不審なリクエストがなかったかを確認しておくと安心です。 なるほど。今回は、PHPに認証不要でリモートコード実行が可能になる脆弱性が見つかり、更新だけが確実な対策だと学びました。 自社のPHPの把握とサポート切れの解消、そして素早く更新できる体制作りが大切なのですね。 体調管理と同じで早めの備えが肝心だと分かりました。 また一つ勉強になりました。 # エンディングと今日のまとめ はい、ということでいかがでしたでしょうか。 今回はですね、PHPの重大な脆弱性ということでですね、予定を変えて緊急で収録をさせていただいております。 公開されたRCVSSがですね、9.2ということで、脆弱性の深刻度がですね、極めて高いということになります。 PHPはですね、なかなかバージョンアップが見送られることが多いというところがありました。 理由としてはですね、そのバージョンを上げた際にプログラムが正常に動くかどうか分からないというところですね。 これはあまりセキュリティ対策をしない理由にならないということもあるわけなんですけども、 多くの環境でですね、そのバージョンアップが見送られるケースがありました。 そういった中でもですね、今回こういった深刻度の高い脆弱性が出ていますので、おそらくですね、どのような環境においても緊急で対応することが必要になるというふうに考えています。 そういった中でもですね、正しく情報を把握していただくためにもですね、このCVSSの構成要素であるベクトルですね、ここをしっかり見ていく必要があると思っています。 今回、PHP to Shellということでですね、このShellという名前が脆弱性についてしまうと、やはりですね、リモートから任意のコードが実行されてしまうということがすぐにですね、思い浮かぶということかなと思っているわけなんですけども、 そのCVSSのですね、構成要素であるベクトルですね、これをですね、今最新の情報ですね、GitHubから確認をしたわけなんですけども、攻撃の複雑さを表すACがHですね、これは攻撃の成立には複雑な条件の克服が必要ということになります。 もう一つですね、攻撃成立の前提条件としてATというものがあります。これがPとなっております。攻撃者が制御できない特定条件が必要ということがここから分かるわけです。 結論ですね、9.2という数字が表す通りでもあるわけなんですけども、10点ではないわけですね。それがどういったところが影響しているかなというので見ていたわけなんですけども、いわゆる即時に攻撃が成立するということではなくてですね、そのためには攻撃の難易度だったり前提条件が必要だというのが現状のようです。 ただしですね、これ二重否定になってしまって恐縮なんですけども、難易度の高い攻撃が極めて成立しやすいAIというですね、新たな脅威が現在現れている状況です。 ですから、このCVSSベクトルをですね、見た上でもですね、やはり今回の定着性については緊急でですね、対策を進めていただきますようお願いいたします。 今日の10分セキュリティラジオは月曜から土曜に祝日も休まず配信しております。それではまた明日の配信でお会いしましょう。セキュリティジョッキーの松野でした。See you!