Yum だと PHP のバージョンが古い
CentOS において yum の標準リポジトリで PHP をインストールすると、CentOS 6.x だと PHP 5.3.3 が、CentOS 7.x だと PHP 5.4.16 がインストールされてしまうが、公式のセキュリティサポートはいずれのバージョンも終了している。1
標準インストールとはリリース番号がかなり離れているが、脆弱性の対応などセキュリティは果たして大丈夫なのか。
最終リリース日と公式サポート期限
| OS | PHP(yum) | PHP(最終リリース) | PHP公式サポート期限 |
|---|---|---|---|
| 7.x | 5.4.16 (2013/06/06) | 5.4.45 (2015/09/03) | 2015/09/14 |
| 6.x | 5.3.3 (2010/07/22) | 5.3.29 (2014/08/29) | 2014/08/14 |
| 5.x | 5.1.6 (2006/08/24) | 5.1.6 (2006/08/24) | 2006/08/24 |
| ※ 括弧内の日付はいずれもリリース日。 |
結論
基本的には問題ない。
CentOS の公式 Wiki の FAQ には「CentOS は企業向けであり、最先端よりも安定性と長期的なサポートが優先される。主なパッケージのバージョンは製品のライフサイクル全体を通じて保持される。」「最新バージョンのパッケージがないのは欠陥ではなく特徴である。」2 （意訳） とあり、バージョンが古いままなのは意図的である。
また、「セキュリティパッチやバグ修正が出荷バージョンにバックポートされている。」「単にバージョン番号を見るだけでは、脆弱性があるとは言えない。」3 （意訳）とあり、脆弱性の対応も行われていることが分かる。
ただし、CentOS 5.x の php53 パッケージはメンテナンスされていないので直ちに使用を中止した方がよい。「サポート期限」を参照のこと。
バックポート
PHP 本体のセキュリティサポートは、例えば PHP 5.4 だと 2015/09/14 で終了4しているが、ディストリビューション側が脆弱性の対応を独自に行っている。5
RHEL/CentOS では例えば以下の様な対応が行われている。（参考：CentOSのPHPセキュリティパッチ履歴）
ここ最近の対応は 2012 年から Red Hat 社に在籍しているフランス人開発者 Remi Collet によるもののようだ。彼は Package monkey を自称し、 PHP などの最新パッケージを提供する外部リポジトリの Remi's RPM repository を公開しているナイスガイだ。
RHEL/CentOS 7 (PHP 5.4.16)
| リリース日 | リリース | チェンジログ |
|---|---|---|
| 2018/01/23 | 43.1 | - gd: fix buffer over-read into uninitialized memory CVE-2017-7890 |
| 2017/10/04 | 43 | - gd: fix DoS vulnerability in gdImageCreateFromGd2Ctx() CVE-2016-10167 - gd: Signed Integer Overflow gd_io.c CVE-2016-10168 |
| 2016/08/05 | 42 | - bz2: fix improper error handling in bzread() CVE-2016-5399 |
RHEL/CentOS 6 (PHP 5.3.3)
| リリース日 | リリース | チェンジログ |
|---|---|---|
| 2016/11/07 | 49 | - fix php-soap fails to connect to HTTPS web service sporadically as stream_socket_enable_crypto() uses NONBLOCK #1283153 |
| 2016/07/25 | 48 | - don't set environmental variable based on user supplied Proxy request header CVE-2016-5385 |
| 2015/12/09 | 47 | - fix wrong warning in openssl_encrypt() for missing IV when IV is not required #1260315- fix segfault's when you try and allocate an SplFixedArray with size >= 9999 #1071344- segfault in php_pgsql_meta_data CVE-2015-4644 #1234434- add options to enable TLS in curl #1255920 - fix segfault in gc_collect_cycles #1122681 |
サポート期限
RHEL / CentOS
RHEL/CentOS の各バージョンごとのサポート期限は以下の通り。
サポート期限内であれば、PHP のバックポートはおそらく行われるはずである。
| OSバージョン | リポジトリ | PHPバージョン | 最新バックポート | OSサポート終了日 |
|---|---|---|---|---|
| 7 | updates | 5.4.16-43.1 | 2018/01/23 | 2024/06/30 |
| 6 | updates | 5.3.3-49 | 2016/11/07 | 2020/11/30 |
| 5 | updates | php53-5.3.3-26 | 2014/10/26 |
|
| 5 | updates | 5.1.6-45 | 2014/10/29 |
|
| 4 | update | 4.3.9-3.36 | 2012/02/03 |
|
php53
CentOS 5.x の標準リポジトリにおける php53 パッケージは、2014/10/26 のリリース 26 を最後に更新されておらず、CentOS 6 の php-5.3.3-41 以降に相当する 26 件の対応がまったくバックポートされていない。
Red Hat Software Collections (RHSCL)
RHSCL はリリースから原則2〜3年間サポートされる。
CentOS では SCLo としてクローンされており、リポジトリはパッケージ名 centos-release-scl-rh でインストールできる。
| リリース | パッケージ | バージョン | 最新バックポート | リリース開始日 | サポート終了日 |
|---|---|---|---|---|---|
| RHSCL 3.2 | rh-php72-php | 7.2.24-1 6 | 2019/10/30 | 2018/11 | 2020/11 7 |
| RHSCL 3.0 | rh-php71-php | 7.1.30-2 8 | 2019/10/29 | 2017/10 |
|
| RHSCL 2.3 | rh-php70-php | 7.0.27-2 9 | 2019/10/29 | 2016/11 | 2019/11 7 |
| RHSCL 2.0 | rh-php56 | 5.6.25-1 10 | 2016/09/06 | 2015/04 |
|
| RHSCL 1.1 | php55 | 5.5.21-5 11 | 2016/07/22 | 2014/06 |
|
| RHSCL 1 | php54 | 5.4.40 12 | 2016/07/22 | 2013/07 |
|
※ 2019/11/27 確認更新
対応スピード
ディストリビューション側のバックポートは実際どれくらいのスピードで対応されるのか調べてみた。
例えば CVE-2015-4024 13 への対応は以下の流れをたどっている。
| 日付 | 経過日数 | 状況 |
|---|---|---|
| 2015/05/14 | 0日 | PHP 5.4.41 リリース 14 |
| 2015/05/18 | 4日後 | CVE-2015-4024 エントリー作成 13 |
| 2015/06/05 | 22日後 | RedHat社での対応（ChangeLog記載の日付） 15 |
| 2015/06/23 | 40日後 | RHEL 7 の php (PHP 5.4.16) のパッチ公開 16 17 |
| 2015/07/09 | 56日後 | RHEL 6 の php (PHP 5.3.3) のパッチ公開 16 17 |
見ての通りあまり迅速な対応ではないようだ。PHP 5.3.3 に至っては56日を経過しており、約2ヶ月遅れということになる。
上記はあくまで問題の一つに対する例に過ぎないので、すぐに対応される場合もあるだろうし、もう2〜3例は調査したいところ。
結局本当に安全なのか
前述の通り、下手すると2ヶ月放置なので、問題ないとは言いがたい。
ソースからビルドする方が脆弱性に対してより堅牢になるのは間違いないが、あとはコストパフォーマンスの問題だろう。
ちなみに CentOS の場合、 yum-plugin-security による --security オプションでのアップデートは意味がないらしいので注意。18
なぜ中途半端に古いリリースを維持するのか
PHP 5.3.3 / 5.4.16 と中途半端なリリースバージョンを維持する理由がよくわからない。
今のところ調べても明確な記述が見つけられていないので、誰か教えろください。
他のライブラリとの整合性などメンテナンス上の理由と考えていたが、単に決め打ちなだけなのだろうか。
古いバージョンでお困りの方へ
最近のPHPフレームワークは比較的新しいバージョンのPHPを要求するのでRHEL/CentOSで提供されるものでは厳しいことがよくある。 19
利用するアプリケーションやライブラリで新しいバージョンの PHP を要求されることは多い。
そのような場合は「Yum で任意のバージョンの PHP をインストールする」で紹介している外部リポジトリを利用すると良いだろう。
がたがた抜かす奴はこんな記事など読まずにソースからコンパイルしろ。
PHP 関連記事
- GitHubで人気の高いCMSランキング
- PHPのリリース日とサポート期限
- CentOSのPHPは本当に安全か
- CentOSのPHPセキュリティパッチ履歴
- CentOS に yum で任意の PHP をインストールする
-
21. Where can I get the latest version of XyZ.rpm for CentOS? I cannot find it anywhere. ↩
-
22. A PCI audit says I am running a version which has CVE exploits in it ↩
-
https://access.redhat.com/documentation/en-us/red_hat_software_collections/3/html/3.2_release_notes/chap-RHSCL#tabl-RHSCL-Components ↩
-
https://access.redhat.com/support/policy/updates/rhscl ↩ ↩2 ↩3 ↩4
-
https://access.redhat.com/documentation/en-us/red_hat_software_collections/3/html/3.0_release_notes/chap-RHSCL#tabl-RHSCL-Components ↩
-
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html/2.3_Release_Notes/chap-RHSCL.html#tabl-RHSCL-Components ↩
-
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html/2.0_Release_Notes/chap-RHSCL.html#tabl-RHSCL-Components ↩
-
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html/1.1_Release_Notes/chap-RHSCL.html#tabl-RHSCL-Components ↩
-
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html/1.0_Release_Notes/chap-RHSCL.html#tabl-RHSCL-Components ↩