ホーム > フォーラム > その他 > PHPの脆弱性について

PHPの脆弱性について
投稿者: wintermute | 投稿日時: 2005/11/2 14:59 | 閲覧: 35013回
wintermute
XOOPSに直接関係する訳ではありませんが、本日PHPに深刻な脆弱性がある事が発見されたらしいですね。

詳しい事はリンク先を見ていただくとして
http://itpro.nikkeibp.co.jp/article/NEWS/20051102/223939/
http://blog.ohgaki.net/index.php/yohgaki/2005/11/02/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp

フォーラムに投稿されている内容を見ると、自宅サーバという環境の方も結構見うけられますが、こういった情報にも目を光らせていなければ、XOOPS 自体のセキュリティが万全でも、水の泡となります。
ご注意を。

コメント(29)

Re: PHPの脆弱性について 
投稿者: keiji | 投稿日時: 2005/11/2 17:41
keiji
wintermuteさんこんにちは

確かに外部に接続している以上このような情報に目を向けるのはとても重要なことだと思います。

私自身、PHP4.3.xを使っているサーバもあるため、アップデートorパッチをあてる必要があるのですが、記事中にPHP4.4.xでは「仕様の変更のためプログラムが動作しなくなる場合がある」という情報もあり、
どうやって対処しようか悩んでおります。

みなさまはどのように対処されましたか?
ご参考までに教えていただければ幸いです。
Re: PHPの脆弱性について 
投稿者: zen | 投稿日時: 2005/11/2 18:03
zen
zenと申します。

とりあえず私のところでは
http://blog.ohgaki.net/index.php/yohgaki/2005/11/02/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp
で紹介されているパッチを4.3.11に当てました。
要検証となっていますが、まだ更新しただけなので不具合があるかないかはちょっとわかりませんが。。。
Re: PHPの脆弱性について 
投稿者: deko2 | 投稿日時: 2005/11/2 22:40
deko2
みなさん こんばんは

貴重な情報ありがとうございます。

玄箱/HGをvine化して自宅サーバとしている者です。
php-4.3.11に大垣靖男氏のパッチ(要検証のようですが)を当ててリビルドしてみました。
今のところ問題なく動いているようです。

ここにrpmパッケージ置いておきます。SRPMも同梱してますので他のプラットフォームでもリビルドすれば使えるかも...
(ご使用に当たっては自己責任でお願いします。)
Re: PHPの脆弱性について 
投稿者: hkazu | 投稿日時: 2005/11/2 23:46
hkazu
うちはXOOPS 2.0.12 JPをPHP 4.3.10で動かしてましたので、
今日、PHP 4.4.1にアップデートしました。

メール送信時のSubject文字化け
が出てしまいましたが、それ以外特に問題なくXOOPSは動作しています。
(コア + 自作の簡単なモジュールのみの環境ですが…)
コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: xnoopy | 投稿日時: 2005/11/4 12:49
xnoopy
上で大垣靖男氏のブログが引用されていますが、追加の記載も出ています。

register_globals=offにすべきですが、いまだにサードパーティモジュールにはonでないと動かないものもあるようですので、注意が必要な方もおられると思います。
XOOPSは、PHP4.4.0以降にするとNoticeの嵐ですし、5.0.4から5.0.5でもかなり不具合がでます。

私はプログラムには疎いので、XOOPSのクラッキングが頻発している最近では心配になります。こうした重大な脆弱性が報告された時には、コアメンバーの方々は早急に、公式ページの分かりやすいところに何らかのアナウンスを出すべきではないでしょうか?
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: wintermute | 投稿日時: 2005/11/4 15:28
wintermute
引用:

私はプログラムには疎いので、XOOPSのクラッキングが頻発している最近では心配になります。こうした重大な脆弱性が報告された時には、コアメンバーの方々は早急に、公式ページの分かりやすいところに何らかのアナウンスを出すべきではないでしょうか?

私はコアの人じゃありませんが、ニュースを見てすぐに投稿しておきましたよ。
オープンソースのプロジェクトというのは、メンバーの方々のボランティアで成り立っているんだし、こういった感じで情報が流れればそれでいいのではないでしょうか?
そもそもコアの方々も、別の自分の仕事を持っているのだし、XOOPS専門のサポートチームでもありませんし。
こういった体制が問題なら、何か別のサポートのあるソリューションを使うなりするべきだと思います。
Re: PHPの脆弱性について 
投稿者: fanrun7 | 投稿日時: 2005/11/4 17:26
fanrun7
XREAで私が使っているサーバは本日未明に軒並み4.4.1にあがってました。PHPデバッグONでメッセージの嵐になる以外は、問題なく動いています。
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: xnoopy | 投稿日時: 2005/11/4 23:31
xnoopy
wintermuteさん、どうも。
引用:
オープンソースのプロジェクトというのは、メンバーの方々のボランティアで成り立っているんだし、こういった感じで情報が流れればそれでいいのではないでしょうか?
そもそもコアの方々も、別の自分の仕事を持っているのだし、XOOPS専門のサポートチームでもありませんし。
こういった体制が問題なら、何か別のサポートのあるソリューションを使うなりするべきだと思います。

私がいいたいのは、そんな事ではありません。
PHPベースのCMSを使っているので、当然PHPの脆弱性の報告には、私のようなプログラムの素人でも注意はしています。それにサードパーティー製のモジュールの事まで面倒見ろなんて言うつもりはありませんよ。

少なくとも、コアのプログラムに精通しているコアメンバーの方々から、今回のようにPHPに重大な脆弱性が報告された場合に、現在のXOOPSがどうのような影響を受ける可能性があるのか(あるいは受ける可能性はないのか)を公式にアナウンスした方が良いのではないかということです。他のオープンソースのソフトウェアでは、開発者が即座に反応しているように思います。

そもそもPHPは0.0.1のバージョンアップですら、かなり大きな変更があり、ここのフォーラムでも4.4.0ではなくて、4.3.11の方が良いなんて話も出ていたりするので、きちんと開発者側からコメントを出す方がユーザは混乱しないのでは?
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: minahito | 投稿日時: 2005/11/5 0:54
minahito
 すみません、ここ数日はいろいろ忙しく、情報をまとめるに至りませんでした。
 再度改めて告知したいと思います。

 ざっと書くと、

 基本的にはPHP4.4.x系はPHPの言語仕様変更によるNoticeエラーが表示されるものの、これは脆弱性とは無関係です。また、registers_globals off 対策のための foreach() ループも過去の段階ですべて修正しており、問題はありません。
 PHP4.4.xのNotice対策は2.0.14ブランチおよび2.1ブランチで作業中です。
 ただし、PHP4.4.1ではメールヘッダの文字化けなどのトラブルが確認されています。

 というところですが、ニュースの方は再度まとめたいと思います。
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: minahito | 投稿日時: 2005/11/5 1:11
minahito
 なお、ユーザーの方からの疑問点については出来る限り応えていけるように努めていますが、「即座に」対応することは現状の体制では難しいことをご理解頂ければ幸いです。
 ひとまずは、wintermuteさんのように情報をフォーラムにあげていただき、事例を持ち寄ってシェアしていただくだけでも相当助かりますし、参考にさせていただいています。m(__)m

 フォークによって jp.xoops(xoopscube.jp) にも「コアチーム」が存在するようになりましたが、かつて jp.xoops に開発チームが存在しなかったように、この世界はやはりコミュニティの世界だと思います。
(ソフトウェアの性質上「コミット権」の問題があり、今それを持たせていただいているわけですが……)
 開発チームの人間としてよりも、このコミュニティの一員として出来るだけ頑張りたいと思いますので、(情けない話かもしれませんが)皆様ぜひ一緒によろしくお願いします。

 ご指摘の点もまったくもってその通りですので、なんにせよ、とりあえず週末に入ったので、検証して報告は出します。
 それでは改めまして。
Re: PHPの脆弱性について 
投稿者: Umachan | 投稿日時: 2005/11/5 2:37
Umachan
このスレッドをみてすぐにさくらインターネットにPHPのバージョンアップの要望を出しました。さくらインターネットも4.4.1にバージョンアップをすることなりました。

さくらインターネットの告知

何か不具合が出たら,改めて報告します。
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: xnoopy | 投稿日時: 2005/11/5 11:09
xnoopy
minahitoさん、ご返答をありがとうございました。
引用:
 なお、ユーザーの方からの疑問点については出来る限り応えていけるように努めていますが、「即座に」対応することは現状の体制では難しいことをご理解頂ければ幸いです。

「即座に」と書いてしまい申し訳ありません。現状の「体制」のことは十分承知しておりますので、無理を言うつもりはありません。
今後もよろしくお願いします。
PHP 4.4.1 の脆弱性対策について 
投稿者: minahito | 投稿日時: 2005/11/6 2:24
minahito
 解析・検証のうえ、こちらに見解をまとめました。
 以下はそれに関連して、PHP一般の話です(余談とも言う)

 今日は、PHP一般的なセキュリティ話題として(XOOPSとは無関係のところで)、JM2さんとGIJOEさんが調査していたPHP4.4.1の影響度や邦訳情報をシェアし、情報交換できる状態にあったので、あとから参加した僕は PHP の diff 追跡に専念するようなすることが出来ました。

 で、僕は全部人から聞いた状態ですが、今回 ITPro が誤報したりして情報がめちゃくちゃだったみたいですね……結論としては、個人ユースであればアップデートする必要性すら感じない程度の問題だと思うのですが……

 以下、PHP一般の話であり、多分に推測を含みますが、

グローバル変数の上書きと条件
 register_globals = on / off の話ですが、一部情報が錯綜しているみたいなのですが、今回のdiffを見る限り register_globals=off条件下ではグローバル変数へのインジェクションは発生しません。
 php_register_variable_ex() 関数は配列か、もしくはregister_globals on 時にグローバル変数配列にポインタをあてて、そこへ抽出した値をセットしていくもので、この関数は register_globals=off であれば処理を中断します。
 脆弱性の警告情報とパッチ箇所からいくと、問題があったのは main/rfc1867.c で、マルチパートPOSTリクエスト解析にバグがあり、かなり特殊なPOSTリクエストを投げたときに、multipart_buffer_read_bodyに不正パラメータを渡す結果につながるのではないかと推測してます。
(POCが出ていないのでよく分からないのです。いま、GIJOEさんが問い合わせをかけているそうです)
 なので、

1.ファイルアップロードとみせかけた、というか、かなり特別なマルチパートPostリクエストを送信
2.PHPはそれをマルチパート解析にかける
3.boundary解析にミスし、multipart_buffer_read_body がまずい値を返す
4.ここでは safe_php_register_variable を直接コールしている
* php_register_variable_ex は元々配列に対してか、register_globals on 時にしか機能しない
* ここでのコールは配列に対しての登録を期待したもの
* しかし boudary 解析ミスのバグを突かれ、配列への指定が解除?
* このとき register_globals off なら関数処理は終了するので安全
* register_globals on なら大域変数用ハッシュにポインタをあてて処理を継続する

 という、極めて特殊な攻撃がPOCではないのかと。(超推測

# ちなみにグローバル変数へのインジェクション=即・XOOPS攻撃可では
# 全然ないです

 PHP 側からみると、

* まず multipart_buffer_read_body という関数にバグがあった。
* こちらも修正したけど、念のため register_globals on 時の「通常の条件」として GLOBALS という変数名を拒否するようにした
* ついでなので foreach や extract は注意しようと呼びかけた(もしくはこれが攻撃が成立するための必要条件か)
* その告知をPHPのセキュリティニュースに混ぜたためにいろいろ混乱が起きた

 ということではないでしょうか。(超推測(2)

 この流れからいくと、 main/rfc1867.c に不備がなければphp_register_variable_ex() 内でのガードは不要なのかもしれませんが、念には念を入れたということだと思います。なにしろごちゃごちゃしていて、またどこに不備があるか分かりませんので、php_register_variable_ex()で防いでおこうというのは順当だと思います。
 大垣さんのパッチはこのガード側のみを PHP 4.4.1 から抽出したナイスなもので、 rfc1867.c 側を修正しなくても、これで防げます。

 また register_globals が off であれば関数のコード上問題にはなりません。
 4.3.11に大垣さんのパッチをあててもいいし、 register_globals を off から絶対に変更しないのであれば、そのパッチの該当コードが実行される機会はありません。そんな感じで判断すればいいのではないかと思います。
 もう 4.4.0 デビューしちゃっている場合は、PHP 4.4.0 -> 4.4.1 は一般的なパッチもあるようなので、これはやったほうがいいと思います。

ファイルアップロード云々
 http_post_files 周辺の処理では該当関数に投げる前に一旦 register_globals=off 設定に切り替えてからコールしており、関数の性質上や 4.4.0/4.4.1 diff で修正入っていない点からいっても、こっち経路の場合は安全かと。
 あくまでマルチパートPOSTリクエストから入っていく攻撃だと思います。
(PHPの情報にははっきりそう書いてあるのですが)

import_request_variables()などの動作変更に関して
 これらの関数にもPHP側でパッチがあたり、グローバル配列を上書きできないようにガードが入っています。しかし、これはそのようなPHPコードがなければ発生しません。
 これは、PHP自体の脆弱性への対応というより、php_register_variable_ex()でグローバルを弾くというコードを入れたため、PHP全体のポリシーを調整するために、こちらにガードを入れたのではないかと勝手に考えてます。。。
 「そういうガードが発動するPHPスクリプトのほうが脆弱性だ」というのはそういう話だと思います。

 PHP内部ではこのパッチと先のパッチは完全に独立した話で、
 この後者の話が一部で「register_globals=off 時でもインジェクションが発生する」という情報に変形しているらしいのですが、ソース見る限りでは全然違う話です。
 もともと脆弱性とは無関係に、展開関数は GLOBALS 配列の上書きを行ってきました。それが今回の調整でできなくなったが、同義のコードは foreach でも書けます。
 それを PHP 側が PHP スクリプトの書き方を含めて注意喚起したため、日本などでは、前述のマルチパートPOSTリクエストの話と混濁して情報が錯綜しまくったのではないかと思います。

余談
 GLOBALS で始まる全変数名をけっ飛ばしているので、4.4.1および相当パッチを当てると、register_globals=on 時に index.php?GLOBALSTAR=hogehoge とか index.php?GLOBALSTANDARD=hogehoge とか受け取れないっぽいです。(^^;
 いずれにせよ off 運用で。

 ここに書いてもしょーがないんですが、
 GIJOEさんとも言ってたんですけど、PHP4.4.1の該当部のそのif文、いろんな意味でミスってるような……(もちろん脆弱性関係の問題はないです)

 最後にこの場を借りて、さまざまな場所で情報交換させていただいた、GIJOEさん、JM2さん、nobunobuさん、ohwadaさんにお礼申し上げます。
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: puchi | 投稿日時: 2005/11/6 8:16
puchi
引用:

xnoopyさんは書きました:
少なくとも、コアのプログラムに精通しているコアメンバーの方々から、今回のようにPHPに重大な脆弱性が報告された場合に、現在のXOOPSがどうのような影響を受ける可能性があるのか(あるいは受ける可能性はないのか)を公式にアナウンスした方が良いのではないかということです。他のオープンソースのソフトウェアでは、開発者が即座に反応しているように思います。


PHPの脆弱性なのであれば、XOOPS Cubeがどうこう以前にPHPをバージョンアップしなくてはいけないので、情報としてはあったら嬉しいですが、コアチームの方が特別に何かするべきということもないかと思います。
仕様変更などでXOOPS Cubeに特別に影響を受ける場合は別かと思いますが。

引用:
コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは?


すぐ出すべきか、べきじゃないか、で言えば、僕は「アナウンスをすぐ出すべき」というのはおかしいと思います。別に義務でもないですし、すぐというのを求めるのも情報の真偽を確かめたり、ソースを追ったりしなくてはいけないので、無理があるのでは?
もちろん、出した方が良いということなら、出さないよりは、出した方が良いのでしょうけども。

[追記]

引用:
「即座に」と書いてしまい申し訳ありません。現状の「体制」のことは十分承知しておりますので、無理を言うつもりはありません。


って書いてありましたね…
よく読んでいませんでした。すみません。
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: ksyuu | 投稿日時: 2005/11/7 18:45
ksyuu
収束したところ,蒸し返すようで申し訳ないですが,ちょっとだけ書かせてください。

PHP は XOOPS と切り離せない存在なので,セキュリティホールの問題はコアチームからアナウンスがほしい(必須)と思います。
#他の Webサーバや OS は,種類も多いし,変えることも出来るので自己責任にして良いと思います。

ただ,必要なのは「コアチームからの出来るだけ早いアナウンス」であって,「即座の対応」ではありません。今回のように,ユーザからの情報が先行して,そのあとでコアチームからのアナウンスが出るので充分です。


また,提案が二つあります。

1.フォーラムに「セキュリティ」カテゴリをつくれませんか。
セキュリティと言った重要な話題が,雑談と一緒に語られるのでは見逃される危険があります。
専用のカテゴリがあれば,OS や Webサーバのセキュリティ情報も書きやすくなると思います。

2.コアチームにセキュリティ専門の担当を置いてください。
セキュリティ関連の対応は,外部からの評価に直結します。
「新機能は良く出るが,セキュリティの対応が遅い」という評価になれば,玄人のツールになってしまいます。
専門の担当がいれば,少しでも早くセキュリティの情報を出せると思います。
体制が整っていないのは判っているので,すぐに,とは言いません。


以上です。
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: tadashi | 投稿日時: 2005/11/7 18:54
tadashi
提案ありがとうございます。
引用:

また,提案が二つあります。
1.フォーラムに「セキュリティ」カテゴリをつくれませんか。
(略)
2.コアチームにセキュリティ専門の担当を置いてください。
(略)

現状で、XOOPSCUBEは、セキュリティ対応的にかなり弱いように見えるのでしょうか?

他の方は、どのように見られていますか?




Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: ksyuu | 投稿日時: 2005/11/7 19:03
ksyuu
引用:

tadashiさんは書きました:
現状で、XOOPSCUBEは、セキュリティ対応的にかなり弱いように見えるのでしょうか?


かなり弱い,といったことではなく,看板です。

XOOPS のセキュリティに関する問題を発見したときに,「セキュリティ担当者」がいれば,発見者は悩むことなく適切なメンバーに連絡が取れます。

セキュリティ情報の発信にしても,「セキュリティ担当者」が発信することで,受け取り方も多少変わってくる,と思います。
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: dendeke | 投稿日時: 2005/11/7 19:20
dendeke
みなさん、こんにちわ。

自分も、セキュリティ関係のアナウンスをコアチームが報告することについては、ないよりはあった方がいいという意味で賛成ですが、今回のようにユーザが投稿した後であっても問題はないと思っています。
(現在でもXOOPS Cubeのコアにセキュリティホールが発見された場合はいち早く対応していただいていますし、それで個人的には充分だとも思っています)

セキュリティ担当がコアチームにいるべきかどうかは、いないよりはいた方がいいでしょうが、あまり細かく担当を分けてしまうことやコアチームに依存しすぎる姿勢は、XOOPS Cubeプロジェクト全体の理念からすると避けるべきではないかとも思います。今回のように気づいた人(それがコアチームの人であれば尚よしですが)がスレッドを立てて報告する(=コミュニティひとりひとりがXOOPS Cubeに携わっている)ことも大事だと思います。

現在は既に

引用:

ニュースに書かれてありますように、更新後のサイトにおけるニュースは大きく「公式のニュース」と「セキュリティのニュース」に分かれており、トップページではそれぞれ個別にリストアップする方式をとりました。

このうち「セキュリティのニュース」は、モデレータの承認は必要ですが、ユーザーの皆さんから情報を投稿していただけます。主に、モジュールに脆弱性があった場合に、モジュール開発者あるいはパッチ作者が目立つ位置で告知を行えるような運用を想定しています。


という形でモデレータの承認が必要(=すぐに反映されない)というジレンマはあるものの、一般ユーザであってもセキュリティに関するニュースは投稿できる仕組みになっているので、まずはこれを利用しながら、問題があるなら改善していくという方向でもいいのではないでしょうか?
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: Marijuana | 投稿日時: 2005/11/7 19:43
Marijuana
引用:
PHP は XOOPS と切り離せない存在なので,セキュリティホールの問題はコアチームからアナウンスがほしい(必須)と思います。
#他の Webサーバや OS は,種類も多いし,変えることも出来るので自己責任にして良いと思います。


httpd(Apache,iis)の方がよっぽどクリティカルな穴出たりすると思うけど・・・
しかも、レンタルサーバ使ってたら、ユーザは何も出来ないんじゃない?(要望出したり出来るけど)
それにXOOPS Cubeの公式サイトであって、AMPの駆け込み寺じゃないんだから
そんなに気にするってか、自宅サーバ含めてサーバ管理やってんなら、それなりのMLに入るなりするべきでしょ
レンタルサーバなら、そこのサポートでしょ


引用:

1.フォーラムに「セキュリティ」カテゴリをつくれませんか。
セキュリティと言った重要な話題が,雑談と一緒に語られるのでは見逃される危険があります。
専用のカテゴリがあれば,OS や Webサーバのセキュリティ情報も書きやすくなると思います。

上にも書いたけど、AMPの駆け込み寺じゃありません。
AMPのセキュリティより、よっぽど3rdモジュールの方がやばいって


引用:
2.コアチームにセキュリティ専門の担当を置いてください。
セキュリティ関連の対応は,外部からの評価に直結します。
「新機能は良く出るが,セキュリティの対応が遅い」という評価になれば,玄人のツールになってしまいます。
専門の担当がいれば,少しでも早くセキュリティの情報を出せると思います。
体制が整っていないのは判っているので,すぐに,とは言いません。

自分がやるとは言い出さないんですね。

セキュリティの対応が遅いって、Cubeになってからありました?
問題になるほど遅いこと無いと思いますけど
(本家はレポートしてから1ヶ月も放置したけどね)


引用:
かなり弱い,といったことではなく,看板です。

どの辺りが、看板になるほど脆弱なのか詳細を、コアチームに教えてあげてください。

引用:
XOOPS のセキュリティに関する問題を発見したときに,「セキュリティ担当者」がいれば,発見者は悩むことなく適切なメンバーに連絡が取れます。

100や200人居るわけじゃないので、悩むほどじゃないでしょ?
誰かに報告して放置でもされた?それなら悩むのもしょうがないと思うけど
報告なんて誰にしても問題ないでしょ?


ここはXOOPS Cubeの公式サイトなんだから、XOOPS Cubeの情報が集まれば、それで良いじゃん。
それ以外が欲しいなら、それぞれのサイトで情報集めれば良いだけでしょ?手抜きしたいだけじゃない?
XOOPS Cubeの公式サイトに何を望んでんだか・・・
Re: コアメンバーの方々はこういった場合、何らかのアナウンスをすぐ出すべきでは? 
投稿者: puchi | 投稿日時: 2005/11/8 1:27
puchi
引用:

ksyuuさんは書きました:
PHP は XOOPS と切り離せない存在なので,セキュリティホールの問題はコアチームからアナウンスがほしい(必須)と思います。


他の方の意見にほぼ同意です。
いいだしっぺの法則ということで、これからPHPのセキュリティ関連のニュースがあった場合、ksyuuさんが「セキュリティのニュース」へ書き込むということで問題は解決するように思いますが、いかがでしょうか?

引用:

ただ,必要なのは「コアチームからの出来るだけ早いアナウンス」であって,「即座の対応」ではありません。今回のように,ユーザからの情報が先行して,そのあとでコアチームからのアナウンスが出るので充分です。


PHPの問題であれば、コアチームからのアナウンスである必要性はないような気がします。

引用:

1.フォーラムに「セキュリティ」カテゴリをつくれませんか。


これはあってもいいかなぁと思います。
でも、セキュリティニュースがあるし、フォーラムを見ている感じだと話題もそんな多くないと思いますが。

引用:

2.コアチームにセキュリティ専門の担当を置いてください。
セキュリティ関連の対応は,外部からの評価に直結します。
「新機能は良く出るが,セキュリティの対応が遅い」という評価になれば,玄人のツールになってしまいます。
専門の担当がいれば,少しでも早くセキュリティの情報を出せると思います。


専門の担当って今のコアチームの中からですかね?
担当の方がいても、その方がお仕事で何日もお忙しかったら対応は早くならないような気がします。早くという意味では有効に機能しないのではないでしょうか?
フルタイムの方を雇うという意味であれば、コスト負担を誰がどのようにするのか?という問題があるかと思います。

XOOPS Cubeや、XOOPS 2系のコアのセキュリティ問題でサイトがcrackされたという事例ってありましたっけ?

最近フォーラムを見ていると、XOOPSは、セキュリティ的に弱いみたいに思われている感じを受けますね。

投票(0)

新しいものから | 古いものから | RSS feed
 
To Top