PEAK XOOPS - News

Protectorのログを見て驚いたのですが、SA20176を利用した攻撃がさっそく、それも大量にやって来てますね。

82.53.119.185 CONTAMI Attempt to inject 'xoopsOption' was found. Attempt to inject 'xoopsConfig' was found. Injecting Null-byte '../../../../../../../../../../var/log/error_log ' found.

最初のAttackが、2006/5/22 4:28で、166.111.249.39 と 87.6.115.177 から。まさにSecuniaのレポートが出た直後みたいですが。その後も、独立したIP10個くらいからAttackを受けてます。

このサイト、人気ありますね

最近は、ScriptKiddieの動きも早い、ということでしょうか。

備えあれば憂い無し。
あらためて、Protectorの導入を勧めておきます。

SecuniaにこんなAdvisoryが上がってます。
http://secunia.com/advisories/20176/

英語が読めなくても、リンク先を読めばだいたいの意味はわかるはずです。register_globals=on でさえなければ問題になりません。

もちろん、Protectorをインストールしてあれば、もしこの手の攻撃が来ても、ヌルバイト対策・変数汚染対策の両方が有効に機能して、ログに記録されることでしょう。

もし、Protectorを入れていない、もしくは入れるつもりがないのでしたら、register_globalsの設定をもう一度確認してください。（個人的にはProtectorをインストールしてない公開XOOPSサイトなんて怖くて仕方がないと思いますが）

一番の「脆弱性」は、このSA20176そのものより、 register_globals=on という設定でXOOPSを運用してしまうことにあると考えた方が良いでしょう。

従来のmyblocksadmin,mytplsadminは、システムモジュールを前提とした作りであったが故に、チェック機構も「システム管理者権限」を利用していました。

- myblocksadmin XOOPS_SYSTEM_BLOCK （システム管理者権限-ブロック管理）
- mytplssadmin XOOPS_SYSTEM_TPLSET（システム管理者権限-テンプレート）

しかし、XoopsCubeで予定されているシステムモジュール換装を考えた場合、それはあまりうまくありません。実際、'system_admin' の各定数は、システムモジュール内で定義されていますし、本来はシステムモジュールでしか意味のないものです。

あちこちで書いていますが、現在XOOPS2.0.xで大きな意味で「コア」と呼ばれるものには以下の３つの要素が含まれます。

- コア
- システムモジュール
- ルートコントローラ

これらは本来独立しているべきものであり、単独モジュールでありライブラリであるaltsysがコアに依存するならともかく、システムモジュールに依存するのでは、本来の目的である「独立性」を損ねてしまうでしょう。

altsysは、それ自身がシステムモジュールのようなものですから、このモジュールの管理者権限が、事実上のシステム管理者権限だと見なすことで、この問題を解決できます。

つまり、altsysについては、各モジュールからライブラリとして呼び出すとしても、altsysのモジュール管理者権限でのチェックが入ることに注意してください。逆に、システム管理者権限チェックは入らないので、そちらでのコントロールはできません。

この唯一の例外は、altsysの要素でありライブラリ専用のmypreferencesです。これについては、対象モジュールの管理者権限がチェックされます。

$xoopsOption['pagetype']
これ、なんだか判りますか？

読んで字の如く「ページタイプ」なのですが、おそらくはNukeの名残と思われ、XOOPS 2.0.xにおいては、コア機能（より正確にはルートコントローラ）の区別をつけて、適切な言語ファイルを読み込むためだけに利用されています。

実のところ、このようなグローバル配列をファイル間通信に利用するのは結構危険なことで、リクエストからインジェクションされる恐れがあります。（ファイル間通信を行うなら、定数かオブジェクトが安全）

また、ルートコントローラの存在しないXoopsCubeでは、完全に消え失せる運命でしょう。（こちらについてはgrepかけていませんが）

その「尾てい骨」こと $xoopsOption['pagetype'] ですが、XOOPS 2.2では再利用されています。$xoopsOption['pagetype'] == 'admin' の時だけ、管理者用のテーマを読み込む、という形になっているのです。

通常のモジュールであっても、/modules/(module)/admin/index.php などという形で管理者コントローラを実装した場合であれば、kernel/module.php において $xoopsOption['pagetype'] = 'admin'; と定義されるので、ほとんどの場合うまく行きます。

しかし、D3モジュールのように、完全なフロントコントローラを目指して、index.php?mode=admin などという形で管理者画面を実装した場合、公開用テーマが適用されてしまうことになります。

そこで、$xoopsOption['pagetype'] = 'admin'; を明示的に実行する必要があります。

以上、XOOPS 2.2にも利用できるモジュールを作る場合には覚えておいて損はないミニ知識でした。

Duplicatable V3モジュールをXOOPS 2.2上での動作確認を行ってみてはじめて判ったことですが、XOOPS_TRUST_PATHに実体がある構造だと、マルチサイトや複数環境での動作確認にとても便利です。

マルチサイトについてはRyujiさんも書かれていましたが、今回、実際に開発してみて、それがとても実感できました。

XOOPS 2.2とJP版XOOPSは、もちろん同じディレクトリでは動きません。でも、XOOPS_TRUST_PATHは同じディレクトリで良いのです。

だから、SubVersionの.svnファイルに気をつけることも、rsyncでどちらのファイルが新しいかをいちいち確認することも、一切必要ありません。2.2で引っかかった場所を修正したら、そのまま、JP版でも動作確認するだけです。これですよ、これ！

なお、従来型のモジュールでも、シンボリックリンクを張れば、同じ効果が得られると思う方もいらっしゃると思いますが、PHPの__FILE__は、シンボリックリンクをうまく利用できないため、この方法では残念ながらうまく行きません。


サイト管理者にとっては、マルチサイトの管理が楽になる。モジュール開発者にとっては、バージョン管理や環境チェックが楽になる。D3モジュールにはこんなメリットもあったのです