PHP 8.1.28リリース対応 PHPセキュリティ保守サービス パッチ配布開始

ESIのPHPセキュリティ保守サービス（PHP 5.2〜8.0対応）では既知のセキュリティ問題を修正した古いバージョンのPHPをご利用頂けます。PHPプロジェクトによるPHP 8.0のメンテナンス期間は2023年12月のリリースで終了しました。今後、PHP 8.0以下の利用を継続されるには既知のセキュリティ問題を修正したPHPを利用する必要があります。

以下はPHP 8.1.28に対応したPHPセキュリティ保守サービスのリリースノートです。

PHP 8.1.28

=================================================================================
Standard:
Fixed bug GHSA-pc52-254m-w9w7 (Command injection via array-ish $command parameter of proc_open). (CVE-2024-1874)

Windows環境のproc_open()のコマンドパラメーターがエスケープされていないため、入力値のバリデーションがない場合に任意コマンドを実行される。

■ 影響バージョン
PHP 4.3.0 以降

■ 互換性
Windows環境のみに影響
既にエスケープして渡している場合、ダブルエスケープに注意する
複雑なコマンドは実行できなくなる

■ 解説
PHPでは「CVE-2024-1874」はWindows環境のみでの脆弱性で基本的にはUNIX系OSには影響しません。ただし、Windows環境ではシェルでの引数処理が統一されていない為、
コマンド引数はバリデーションかつエスケープした引数でないと安全性を保証できません。この為、Rustでは正しくエスケープできないケースでは無効な入力としてエラーにしています。
かなり昔に修正されたPHPのWindows版のescape_shell_arg()でも同じ議論がされましたが、妥当でない入力を渡したユーザーの責任（CWE-20）とすることで対応しています。
参考1： CWE-20 Improper Input Validation https://cwe.mitre.org/data/definitions/20.html
参考2： 全ての入力を完全にコントロールするのがベストプラクティスです。 https://cwe.mitre.org/top25/mitigations.html#Mit-M1
   (Fail Fast原則に従い、無効な入力はできる限り早く排除します）

UNIX系OSでもWindowsのような非標準な形（特殊なシェルで引数処理するなど）でコマンド引数処理がされ
同じような問題が起きるケースも想定できます。

=================================================================================
Standard:
Fixed bug GHSA-wpj3-hf5j-x4v4 (__Host-/__Secure- cookie bypass due to partial CVE-2022-31629 fix). (CVE-2024-2756)

■ 影響バージョン
すべてのPHP

■ 互換性
問題なし
通常は__Host-/__Secure-で始まるクッキーをPHP開発者が設定する必要がない

■ 解説
ブラウザがセキュリティ機能として利用している特殊クッキーをPHPから設定でき、入力値のバリデーションがあまいプログラムの場合にセキュリティ設定を回避できる可能性がある。

参考： https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies

Cookie の接頭辞
Cookie の仕組みの設計では、 Cookie が安全なオリジンに設定されているかどうか、 Cookie が当初はどこに設定されたのかをサーバーが確認することができないようになっています。

サブドメイン上にある脆弱性のあるアプリケーションが Domain 属性を使用して Cookie を設定すると、ほかのすべてのサブドメインで Cookie にアクセスできるようにすることができます。この仕組みはセッション固定攻撃で悪用される可能性があります。主な対策方法はセッション固定化を参照してください。

しかし、多層防御として、 Cookie に関する特定の事実を主張するために Cookie の接頭辞を使うことが可能です。以下の 2 つの接頭辞が利用可能です。

__Host-
Cookie 名にこの接頭辞がついている場合、 Set-Cookie ヘッダーが受け入れられるのは Secure 属性で指定されており、安全なオリジンから送信されており、 Domain 属性を含んでおらず、 Path 属性が / に設定されている場合のみです。この場合、これらの Cookie は「ドメインにロックされている」と見なすことができます。

__Secure-
Cookie 名にこの接頭辞がある場合、 Set-Cookie ディレクティブが受け入れられるのは、 Secure であり、安全なオリジンから送信されている場合のみです。これは __Host- 接頭辞よりも弱いものです。

これらの接頭辞が付いていて、制約に適合していない Cookie は、送られてもブラウザーが拒否します。これにより、仮にサブドメインで接頭辞の付いた Cookie を作成した場合、サブドメインに限定されるか、完全に無視されるかします。アプリケーションサーバーは、ユーザーが認証されているか、あるいは CSRF トークンが正しいかどうかを判断するときに、特定の Cookie 名をチェックするだけなので、これはセッションの固定化に対する防御手段として効果的に機能します。

 

=================================================================================
Standard:
Fixed bug GHSA-h746-cjrr-wfmr (password_verify can erroneously return true, opening ATO risk). (CVE-2024-3096)

Bcryptを使った場合、ヌル文字を含んだパスワードが設定可能で空のパスワードを設定できる。

■ 影響バージョン
PHP 5.5.0以降

■ 互換性
問題なし

■ 解説
Bcryptを使ったpassword_hash()はヌル文字インジェクションにより、パスワード文字列が丸められる。これにより一見複雑に見えるパスワードでも空のパスワードや短く非常に脆弱なパスワードを設定することが可能となる。

通常、適切な入力値バリデーションにより、パスワード文字列にヌル文字が設定されることは有り得ない。アプリケーションが脆弱な場合は「コピー＆ペースト」などにより攻撃される可能性がある。