コメント:11

ぽっと 13-09-11 (水) 10:50

OpenPNE3.8.1も対象となりますか？
その場合、3.8.7用のパッチをそのまま適用しても
大丈夫でしょうか？

Kousuke Ebihara 13-09-12 (木) 17:32

はい、 OpenPNE 3.8.1 も対象となりますが、修正内容は同一です。カスタマイズの有無にもよると思いますが、特に問題なく適用できるのではないかと思います。

3.8.7 用のパッチを用いた場合、 data/version.php で失敗すると思いますが、そこは無視していただいて問題ないです。

ぽっと 13-09-13 (金) 9:32

ご回答ありがとうございました！
適用を行ってみます

まゆぼ 13-09-16 (月) 14:07

現在OpenPNE3.9.0を使ってます。
これも対策が必要でしょうか？
•opOpenSocialPlugin と•opWebAPIPluginは使用しておりません。

Kousuke Ebihara 13-09-16 (月) 19:27

opOpenSocialPlugin と opWebAPIPlugin を使用していない場合、影響を受けるのは以下の機能です。

* OpenPNE プラグインセットアップ関連機能
* opAuthOpenIDPlugin による OpenID 関連機能

この機能において本脆弱性が存在することによるリスクを受容できるのであれば、対策を適用する必要はありません。

なお、本脆弱性への修正は master ブランチに既に適用されています。
小さな差分ですし、修正内容的に副作用等もまずないでしょう。開発版である（しかもリリース版が現状存在しない） OpenPNE 3.9.x 系列を使用されているということですし、おそらく普段運用していただいているように、都合のよいタイミングで、他の修正と一緒に適宜取り込んでいただければ問題ないのかなと思います。

この脆弱性のリスクを受容できない場合は速やかに修正を取り込む必要がありますが、未リリース版を利用いただいているということで、運用方法によっては本脆弱性の修正「だけ」を取り込むことが今後の master への追従の妨げとなるかもしれません。
今回の脆弱性については PHP から libxml 2.9 を用いることで対策となりますが、今後ソースコード上の修正が必須な脆弱性が出てくるかもしれず、そのときに master への追従が遅れていると困ったことになるかもしれません。

もちろん適切にパッチ管理をおこなったうえで運用されているのであればまったく問題ないのですが、この機会に、安定版の利用についてもご検討いただければと思います。

まゆぼ 13-09-29 (日) 14:13

丁寧な回答ありがとうございました。

導入時に3.8を使用しましたら、タイムラインの表示がエラーになり、対策をwebで検索したところ、masterブランチが修正済みとの寺田屋さまからの回答を見つけてダウンロードして使用してました。
3.8系列のほうが安心であればそちらに切り替えて使用したいと思います。

Akane 13-10-08 (火) 12:01

こんにちは！
OpenPNE3.8.1を使っていますが
opOpenSocialPlugin
opWebAPIPlugin
opAuthOpenIDPlugin
は使用していません。

OpenPNE プラグインセットアップ関連機能が関係あるかと思っています。
カストマイズをしている関係で最小限の適用にしたいと思っているのですが
配布されているパッチのプラグインセットアップ関連
（lib\plugin配下）の更新を行えばよいのでしょうか？

Kousuke Ebihara 13-10-08 (火) 14:02

影響を受けるプラグインを使用していないのであれば、修正対象となる差分は lib/plugin/opPearRest.class.php, lib/plugin/opPlugin.class.php, lib/task/opPluginArchiveTask.class.php, lib/util/opToolkit.class.php になるかと思います。 OpenID 関連部分やドキュメント、テスト、バージョンの更新の追加を除いたほぼすべての差分を適用することになります。

カスタマイズされているということで、これらのファイルの差分のみを抽出した上で適用するのも悪いアイディアではありませんが、一度すべての差分を適用してみて失敗しないかどうかを確認してみるのも手かもしれませんのでご一考ください。今回の修正内容自体に副作用はない（ように修正しています）ので、カスタマイズしている環境下で検討するべき事項となるのは、パッチの適用に失敗する箇所がないかどうかの一点のみになるのかなと思います。
もしかすると data/version.php などのファイルの更新で失敗するかもしれませんが、そのあたりは無視していただいて構わないかと思います。

Akane 13-10-08 (火) 16:01

ご丁寧で早い回答、ありがとうございます。
本当に助かります！
差分について、とても参考になりました
ありがとうございました。

実は、パッチを当てようとしたところ、自作のプラグインのテーブルについて
SQLSTATE[HY000]: General error: 1005 Can’t create table
のエラーが発生して、途中で停止してしまうのです。

2つのテスト環境の片方では上記のエラーで止まり、片方では最後まで動いているように見えます。
schema.ymlの内容もDBの構造も同じなので
このまま本番に適用するのをためらっております…

そこで、今回テーブルの変更などもないはずだし、
最低限の適用はできない物かと思い、質問させていただきました。

Kousuke Ebihara 13-10-08 (火) 16:18

> SQLSTATE[HY000]: General error: 1005 Can’t create table

なるほど、そういった状況なのですね。

パッチによるテーブル定義の変更等も一切発生しないため、その問題はもともと貴サイトに潜在していたものではないかと推察します。ですので、パッチの適用範囲を狭めても問題は解決しない可能性が高いです。

今回はソースコードの変更のみで修正が完了するため、ひとまずパッチによってソースコードを変更した後、問題のエラーの解決とするのがよさそうに思います（が、脆弱性によって被るリスクを一定期間受容できるのであれば、パッチの適用をあえて後回しにするのも一案ではあります）。

Akane 13-10-08 (火) 17:21

分りやすいご説明　ありがとうございます！
リスクを先送りするのもよくないかと考えておりますので
取り急ぎ、ソースコードの変更で一時対応したいと思います。

本当に本当に助かりました！
ありがとうございました！！