5.2.4セキュリティパッチが適用されてました。動作的には問題ないようなので、パッチ検証環境以外にも適用します。
このほかに、5.3 Release Candidate が出ています。特にほしい機能があるわけではないので、取り換えず様子見です。
そして、以前に旧版へセキュリティパッチの話を書きましたが、5.1.3が同時にリリースされていました。パッチリリースのところには情報公開されないのですね。ちょっと不親切な感じがします。
タグ: WordPress
WordPress 5.3 Betaリリース、 旧版へのセキュリティパッチは？
2019年9月23日にWordPress5.3Beta1がリリースされていますが、旧版へのセキュリティパッチの情報は特にありません。WordPressは新版をリリースするときは１か月くらいかけて毎週のように更新版を出してきます。開発のほうに力を入れていて、セキュリティへの対処へ使うパワーがあまりない感じがします。
セキュリティ対処は外部の人の力に頼っていて、自己対処ができていないのではないかと思われます。このような状態では、新規開発部分に作りこまれる脆弱性は減らず、脆弱性がどんどん増えていく状態になるのではないでしょうか？
さて、追加でWordPress 5.2.3 で対処された脆弱性について確認します。 影響度と影響範囲の情報について追加情報が出ていますが、あまり詳しくありません。 CVE-2019-16220 （JVNDB-2019-009141）の場合、影響バージョンは WordPress 5.2.3 未満 となっています。該当機能が、初期バージョンから存在するのか疑問ですが、該当機能はかなり以前からあるので事実上すべてのバージョンに影響があるといってもよいのかもしれません。それから9/12の午後以降にJVNの情報公開がされていました。今後のセキュリティパッチはWordPress5.3に対して提供されることになると思われるので、どのタイミングでWordPress5.3に上げるのか、検証計画を立てておくなど検討しておいたほうがよさそうです。
WordPress セキュリティパッチのみ自動適用するには
WordPressのセキュリティパッチに関して検討および対処してきましたが、多数のプラグインの利用とWordPressのパッチリリースのスタンスや情報公開の仕方を考慮してパッチリリース状況の監視と適用の手順を見直しました。
セキュリティパッチのみを適用するということが、WordPressの場合は「セキュリティ修正が含まれているのにメンテナンスパッチ」となっていたり、「プラグインのセキュリティ問題の対処をセキュリティ修正としない」とされていたりする状況からあまり妥当でないとなっていると判断しました。
つまり、ポイントは次の2点です。
・WordPressがいうところのメンテナンスリリースとセキュリティリリースとを区別して別の取り扱いをする意味はあまりない。メンテナンスリリースとされていてもセキュリティの対処が含まれている場合がある。
・ メンテナンスリリースとセキュリティリリースのどちらも適用しないと問題があるかどうかを確認できない場合がある。
以上の状況から、つぎのようにします。
「テスト用サイトを立ち上げておいて、テスト用のサイトについてはパッチを自動適用する設定にしておく、パッチ適用のメールが来たら動作確認を行い、本番環境に適用するかどうかを吟味し適用手順を確立したうえで適用作業を行う。」
WordPress 5.2.3 セキュリティパッチの適用
2019年9月5日にリリースされたセキュリティ＆メンテナンスパッチWordPress5.2.3について書きます。 wp-config-sample.phpが更新されていましたが、動作に影響がある変更はなく実質的には気にする必要はありませんでした。5.2.1のように白画面になることもありませんでした。
しかし、” Page Visit Counter ”がエラー（具体的に何のエラーなのか情報がない）で止まっていました。この停止問題はプラグインを設定ページで有効化することで解決しています。
WordPress 5.2.3 で対処された脆弱性について確認します。 WordPressのサイトの情報では1件ごとに明確にされるべき影響度とか影響範囲の情報がなく、問題検出者への感謝？の公開の場でしかありません。何とかしてほしいが、他のサイトで確認してみましょう。 9/12時点でJVNのほうにはまだ登録されていないように見えます。NVDの情報では、つぎの7件がWordPress5.2.3で対処されたことが分かります。
| CVE-2019-16223 | WordPress before 5.2.3 allows XSS in post previews by authenticated users. |
| CVE-2019-16222 | WordPress before 5.2.3 has an issue with URL sanitization in wp_kses_bad_protocol_once in wp-includes/kses.php that can lead to cross-site scripting (XSS) attacks. |
| CVE-2019-16221 | WordPress before 5.2.3 allows reflected XSS in the dashboard. |
| CVE-2019-16220 | In WordPress before 5.2.3, validation and sanitization of a URL in wp_validate_redirect in wp-includes/pluggable.php could lead to an open redirect. |
| CVE-2019-16219 | WordPress before 5.2.3 allows XSS in shortcode previews. |
| CVE-2019-16218 | WordPress before 5.2.3 allows XSS in stored comments. |
| CVE-2019-16217 | WordPress before 5.2.3 allows XSS in media uploads because wp_ajax_upload_attachment is mishandled. |
9/11にDBに登録されたばかりで影響範囲など詳しい情報はまだありませんでした。
想像ですが、9/12時点で過去バージョンに対してセキュリティ修正のみ（WordPress5.1.2?）を提供しようと準備しているように見えます。5.2.3のリリースには「In addition to the above changes, we are also updating jQuery on older versions of WordPress. This change was added in 5.2.1 and is now being brought to older versions. 」の記述があります。しかし明示的には5.1.2について特にアナウンスしているようには見えないので、本当にリリースされるかはわかりません。どうしても欲しければチームに入って推進すればよいかもしれません。
WordPress脆弱性の再現方法 再現検討
脆弱性 CVE-2019-8943は対処済みなのかどうか情報がふにゃふにゃしているので再現検証してみようかと少し調べてみました。
NVDによると再現方法などの情報があるブログにあるということで、それを参照してみました。
このサイトの再現確認状況の情報は影響バージョンは4.9.9と5.0.1でが未対処の情報しかなく最近の情報がないようにみえます。以下翻訳文面です「 影響範囲： この記事で説明されている脆弱性は、バージョン4.9.9と5.0.1のセキュリティパッチによって悪用されないようにされました。ただし、Path Traversalはまだ可能で、現在パッチは適用されていません。不適切なPost Metaエントリを処理するプラグインがインストールされているWordPressサイトは、悪用を依然として可能にします。私たちは、WordPressのセキュリティ月の準備中に、過去何百万ものアクティブなインストールを含むプラグインがこの間違いをしているのを見ました。 WordPressのダウンロードページによると、このソフトウェアはインターネット上の全Webサイトの33％を超える割合で使用されています。プラグインが問題を再導入し、古いサイトなどの要素を取り込む可能性があることを考慮すると、影響を受けるインストールの数は依然として数百万にのぼります。 テクニカル分析 パストラバーサルとローカルファイルインクルージョンの両方の脆弱性は、ボタンをクリックするだけでスキャン時間3分以内に当社の主要なSASTソリューションRIPSによって自動的に検出されました。しかし、一見したところバグは悪用できないようでした。脆弱性の悪用ははるかに複雑ですが可能であることが判明しました。 」
煮え切らない情報の原因は、つぎの複合で発生しているように思われます。
・検出者が、具体的にどのバージョンで対処されているかのをレポートしていない。→”2019/2/14：WordPressがパッチ提供し、そのパッチで対処済みであることを確認した”ししかなく、対処されたWordPressの特定バージョンでの検証悔過を公開していない。
・検出者は単純な？再現方法を公開していない。→誰でも検証できる状態になっていない？
・WordPressが2019/2/14よりあとにリリースしたセキュリティパッチは5.1.1しかないが、パストラバーサルの対処をしたと明言していない。→脆弱性はWordPress自体ではなくプラグイン側のAPI使用方法にあると考えているのが原因かもしれません。
・WordPress単独では脆弱性を悪用されることはなく、ある機能を不適切に使用したプラグイン（該当するプラグインは複数（多数？）ある）を組み込んでいる場合に脆弱性を悪用される。
このように脆弱性の作り込み原因の責任がどこにあるのか不明確な状態であるためこのような状態になっているといえます。WordPress側で対処したのだから明確に情報公開をするべきでしょう。
WordPress脆弱性 、対処するも白画面そして解決
WordPress脆弱性はプラグインでの新たな情報が出ていますが、本体とこのサイトで使用しているプラグインについての新たな情報はありませんでした。代わりといっては何ですがWordPress5.2.1の修正内容をチェックしました。重要な修正の内容は5.2で作りこまれたバグの修正でしたが、他の修正内容も確認しました。
5件は作りこみバージョンの情報がないもので、6件はWordPress5.1.1以前が作りこみバージョンのもの、それ以外はWordPress5.2で作りこまれたものです。作りこみバージョンがWordPress5.1.1とされた修正で、”jQuery Update 3.4.0”のアップデートがありました。これはWordPressで作りこんだバグではありませんが、jQueryでは”vulnerbility”とされているので、WordPressもこの脆弱性の影響があると判断したほうが良いでしょう。これは、 jQuery 3.4.0で対処された CVE-2019-11358 のことでしょう。ということでWordPress5.1.1も、 jQuery におけるクロスサイトスクリプティングの脆弱性の影響を受けるということなので、コメントを介して攻撃を受ける可能性があると判断し、WordPress5.2.1に更新します。
WordPress5.1.1から5.2.1にアップデートしましたが、 困ったことに 更新処理の途中で失敗し白画面となってしまいました。管理画面も白画面となり対処不能となったので仕方なくバックアップから書き戻していったん復旧しました。 類似の事象がないかチェックしましたがほぼ同じパターンのアップデートが成功していそうな情報がありました。違う条件はPHPのバージョンでした。そこで、PHP5.6をPHP7.2に上げて再度確認しましたが、アップグレード途中で失敗し白画面（500エラー）になる問題が再発しました。5.2.2で対処されることを期待して5.2.2を待とうかと思いましたが、うまくアップロードができている事例があるので、ログとかを見て調査することにしました。
まず、画面内容を再確認。
wordpress-5.2.1.zip から更新をダウンロード中…
更新を展開しています…
展開したファイルをチェックしています…
最新版をインストールする準備をしています…
メンテナンスモードを有効にします…
必要なファイルをコピーしています…
メンテナンスモードを無効にします…
更新が必要な翻訳が一部あります。更新が終わるまでしばらくお持ちください。WordPress (ja) の翻訳を更新しています…
翻訳が正常に更新されました。
ファイルをコピーできませんでした。: wp-admin/site-health.php
インストール失敗
WordPress のご利用ありがとうございます。 バージョン 5.1.1
インストール前の状態で、” site-health.php ”のファイルは存在しないので、ファイルを書き込み出来ていないのが原因でしょう。 wp-admin/ のフォルダの書き込み権限がないのでそれが原因でしょう。セキュリティ強化としてこのフォルダの書き込み権限を落としていました。書き込み権限を付加して、再度WordPress5.2.1へのアップグレードを行うことでアップグレードに成功しました。 アップグレード後は ” site-health.php ”などのファイル が作成されていました。書き込み権限を落として作業完了しました。
WordPress5.2.2については次回チェックします。5.1からのバグの修正があります。現時点では優先度はいずれもNormalなので近く公開されようとしている理由となっている修正はこの一覧にはないのかもしれません。
WordPress投稿のパスワードって何？ まとめ
まるめると「投稿ごとにパスワード設定可能なユーザIDが共通のフォーム認証」ということです。Webエンジニアならこの表現で大体の挙動は理解できると思います。
Web技術的な表現で書くと、次の通りです。
・WordPressで共通のポストデータでパスワードを指定する ユーザIDの指定がない フォーム認証。
サイトで固定のクッキーを使っているのか、それともページごとに指定するクッキーで指定するのかと推測しましたが、パスワードをWordPress固定のポストデータで指定して、WordPressのクッキーでセッション維持をしていました。
これにより次の動作をします。ある投稿のパスワード入力フォームに別の投稿用のパスワードを入力すると、パスワードを入力した投稿は参照できないが、パスワードが一致した投稿は参照できるようになる。また、ある投稿Aを参照できる状態で、別の投稿Bを参照するためのパスワードを入力すると投稿Bは参照可能となると同時に投稿Aは参照できない状態に変わります。
結局、この機能、どこかで投稿参照用のパスワードを利用者に渡して参照可能にするというものでしょう。 実際に使っているというか、有効に使えているところがあるのでしょうか。
WordPress 投稿の非公開ってどう使う？
この機能って、公開、非公開をあとで切り替える機能ってこと? つまり、主な目的は公開済みのものを後で削除ではなく非公開に切り替えるということ？ 見せないようにするのに削除するのではなくスイッチを切り替えて見せないようにする。証拠保存が目的でしょうか？
非公開にすればタイトルさえ表示されなくなる。
機能名が、なんか変。 つまり「公開する」なのに「非公開」ってなっている点です。日本語に翻訳したところで変なことになっているのか？
やっぱり読み通りでした。英語だと、
「公開する」→Published
「非公開」→Private
です。
「私的：Private（プライベート）」の反対語は 「公的：public（パブリック）」なので、英語だと違和感がありません。 Privateを日本語に翻訳するときに”非公開”としたことで、機能名的な違和感が発生したわけです。