PEAK XOOPS - News

日本では年末に大掃除を行う習慣があります。
家中のガラス拭きをやった勢いで、altsysのmyblocksadmin機能について大掃除してみました。（半分嘘）

実際、myblocksadminは私が積極的にメンテしているコードの中では最悪クラスの汚さで、機能的にも、WYSIWYG対応もspawのみ、新コアについてもXOOPS2.2のみ、と半端でした。

どうやら本家はXOOPS2.2を切り捨てることを完全に決断したようで、2.3という番号を冠しながら、中身は2.0.18の改良版のようなので、XOOPS2.2対応はやめました。いろいろ問題のあるspawもやめてます。

その代わり、というわけではないのですが、ImpressCMSに正式に対応しました。これで、D3モジュール群がImpressCMSでストレスなく使えると思います。正直、本家版についてまで、動作確認している暇はないのですが、XOOPS_VERSIONを見て、2.3なら、ImpressCMSと同じ扱いにしています。もしブロックポジションなどの仕様が同じであれば、XOOPS2.3でもすんなり動くかもしれません。

もちろん、WYSIWYGはcommon/fckeditor(fckxoops)に対応しています。これが入っていなければ警告が出るという親切設計！

XCL2.1コアの機能で、ブロック編集画面で表示対象グループが選べる、というのも、絶対にあった方が利便性が高そうなので、ついでに実装してます。ただ、これをまともにやると、group_permissionテーブルのgperm_idが異常に増大しそうなので、表示対象グループに変更がなければ同テーブルはいじらない、なんてあたりにも一応手間をかけました。

まるまる書き直した関係で、バグもいろいろありそうですが、ベータ版等と分けて管理する余裕もないので、一発勝負で0.70としてリリースしてます。

もし不具合があったらコメント等の方法で教えてください。

xoops.org (Mamba) がこんなニュースを出しました。
Security : Protector Security Fix for XOOPS 2.0.x and 2.2.x users

先に結論から言うと、無意味なレポートなので、無視して構いません。
XOOPS_TRUST_PATH内のファイルにアクセスされたらLFIだ、なんてトンデモなレポートですから

この世の中には、DocumentRootの外に置く部分と中に置く部分が別れているアプリケーションはごまんとあります。
むしろそういうアプリケーションの方が正しい設計であり、全部をDocumentRoot内に置く古いXOOPSの構造こそある意味おかしいと言えます。

もし、前者のようなアプリケーションについて、DocumentRoot外に置かれるべきコードをDocumentRoot内に置いて、そこに直接アクセスされたとしたら、そりゃあゴロゴロと「脆弱性」が出てくるように見えるでしょう。
少なくとも、PathDisclosureくらいはいくらでもあります。

でも、誰もそんな馬鹿げたレポートはしません。
なぜなら、DocumentRootの内か外か、というのは非常に重要な違いであると言うことを誰もが知っているからです。

XOOPS_TRUST_PATH はDocumentRootの外に置く
これは大原則です。

こんなニュースを出すという時点で、xoops.org は誰もセキュリティの基本を知らないことを露呈してしまっています。
（ニュースだけならサイト管理者であるMamba氏が無知なだけでしょうけど、ご丁寧にもphppp氏がメールで問い合わせまでしてきてます）

翻って、ImpressCMSを見てみると、彼らはちゃんとXOOPS_TRUST_PATHの意味を理解していることが判ります。例えば、mainfile.php 内のパスワード部分を、XOOPS_TRUST_PATH内に別ファイルとして保存しています。
（本当に必要かどうかはともかく）

つまり、xoops.orgからリリースされるXOOPSという名前のCMSより、ImpressCMSの方がお勧めだと言えるでしょう。

Snoopyにコマンド実行脆弱性が見つかっています。
http://jvn.jp/jp/JVN20502807/

現実には、XOOPS各フォークのコアで、任意のURIをSnoopyに渡す、ということはありませんし、各モジュールについても、Snoopyで取得するURIについては、管理者以外は指定できないものがほとんどだと思うので、ほぼすべてのXOOPSサイトでそれほどの緊急性はないでしょう。慌てず騒がず、今後でてくる新バージョンにバージョンアップすれば十分です。

ただ、もし、ゲストが投稿したURIからRSSやサイトイメージを取得しようとするような使い方をしているのなら、緊急性があります。いますぐパッチを当ててください。

なお、Snoopyを自前で持っているモジュールには、xhldがあります。こちらについても、とりいそぎパッチを当てておきます。d3pipes は自前で持っていないので、コアの方だけパッチを当てれば十分です。

それにしても、$safer_URIなんてのが全然安全じゃなかったことに、1.2.3パッチの時点で気付けなかった自分が恥ずかしい…

Index: html/class/snoopy.php
===================================================================
--- snoopy.php  (revision 729)
+++ snoopy.php  (working copy)
@@ -1035,8 +1035,7 @@

                $headerfile = tempnam($temp_dir, "sno");

-               $safer_URI = strtr( $URI, "\"", " " ); // strip quotes from the URI to avoid shell access
-               exec($this->curl_path." -D \"$headerfile\"".$cmdline_params." \"".$safer_URI."\"",$results,$return);
+               exec($this->curl_path." -k -D \"$headerfile\"".$cmdline_params." \"".escapeshellcmd($URI)."\"",$results,$return);

                if($return)
                {

XOOPS2.0.4から導入されて「しまった」XoopsErrorHandler。
私自身、ことある毎にこれについて批判してきましたが、その理由は明確です。

(1) phpの設定によらず、PHPエラーがHTTPボディとしてechoされてしまう
(2) fatalエラーなどで止まる場合は、ハンドラの上書きが効かない
(3) mainfile.phpを通過するケースとそうでないケースで、設定を一致させる術がない

(1)は、実稼働サイトでエラーを確認する術がないことを意味します。XoopsErrorHandlerは一応XOOPS_URLを隠蔽してくれますが、PHPデバッグがONの間、すべての訪問者にエラー内容を送出してしまう、という根本的な問題が解決されていません。

(2)も大きな問題です。mainfile.phpなどの記述ミスで、fatalエラーとなる場合、error_reporting()やXoopsErrorHandlerの処理など実行されないのですから、必然的にphpの設定がそのまま生きます。

(3)は(2)と似ていますが、これはPathDisclosure問題と直結します。XOOPSの構造は古く、本来DocumentRoot外に置かれるべきPHPコードの断片ファイル群が、DocumentRoot内に多く存在します。それらに直アクセスされた時に、PathDisclosureとなるかどうかは、php設定によるのです。

つまり、どのようなエラーハンドラ設計を行おうと、php設定こそが重要である、という事実はひっくり返しようがないのです。

であれば、特定条件を満たした時だけ働くエラーハンドラなど無効にして、PHP設定だけですべてをコントロールできるようにするのが合理的な手段というものでしょう。

特に勝手にerror_reporting()レベルを変更してしまうXoopsErrorHandlerなんて、今すぐ捨てましょう！


…と、ここで従来であれば、「その部分を潰すHackは〜」となるわけですが、XCL2.1なら、それさえもpreload一個で実現できることに、今になってようやく気付きました。

XCL2.1用のエラーハンドラ正常化preload
http://www.peak.ne.jp/support/xoops/Preload_ErrorHandlerOriginal.zip
（解凍で得られた ErrorHandlerOriginal.class.php を preloadフォルダにコピー）

このpreloadを入れるだけで、php設定だけでエラー処理をすべてコントロール出来るようになります。


なお、ほとんどすべてのケースで都合が良いのは、エラーをログに記録する方法です。
「ログ記録方式だとリアルタイムなデバッグに使いづらいじゃないか」なんていう人には、良い方法を教えましょう。好きなターミナルを開いておいて、
$ tail -f error_log
とするだけです。tailの-fオプションは様々な局面で役立つので、絶対に暗記しておくべきでしょう。

もしあなたがXCL-2.1を利用しているのなら、上述したpreloadを有効にした上で、php.iniや.htaccessで、エラーをロギングするようにしましょう(log_errorsをonにして、error_logに適切なファイルを指定)。もちろん、display_errorsはoffです。

それこそが、開発者にとって最も効率よい環境であり、同時に、サイト運営者にとって最も安全な環境ですから。

●アプリケーションインストーラの原理等

前の記事でも書いたのですが、rsync+sshやsshログインが出来ない環境で、大量のファイルを展開するWebアプリケーションのセットアップは、かなり辛いものがあります。FTPでアップロードするのにもとても時間がかかり、途中で切れることも珍しくありません。アップロードが不完全であることに気がつければまだ良い方で、成功したと思い込んで作業を進めてしまうと、後になってから面倒なトラブルが頻出することになります。

しかし、そういう環境（安価な共有型ホスティングサービス）であれば、おそらくCGIはsuExecです。であれば、アーカイブの展開をCGIでやってしまえば良いのです。ファイルオーナーはFTPでアップするのと一緒です。つまり、FTPで大量のファイルをアップロードする必要なんてなくなります。

ついでに、アーカイブもwgetで取得してしまえば、FTPでアップロードするのは、そのCGIのみとなります。そうなれば本当に楽ちんです。

ここで注意しなければならないのは、wgetのパラメータが任意ではいけません。そんなことをしたら、そのCGIが存在しているタイミングに、任意のアプリケーションをインストールされてしまいます。（もちろん、そうであってもなくても、そのCGIは実行後、即座に消すべきですが）


とりあえず、サンプル的な意味で、ホダ塾ディストリビューションをインストールするためのCGIを書いてみました。

http://www.peak.ne.jp/support/xoops/hd_installer.zip

●bashCGI版インストーラ使い方

このファイルを解凍すると、hd_installer.cgi というファイルが出来ますので、これをサーバにFTPでアップロードします。アップロード先が重要で、XCLのルートフォルダとなるべきフォルダにアップロードしなければなりません。

例えば、サーバのDocumentRootが /home/foo/public_html で、そのルートにインストールしたいのであれば、そのまま /home/foo/public_html の下にアップします。
このファイルはCGIですから、実行パーミッションを与えます。755または705が一般的でしょう。また、サーバによっては、.htaccess に
Options +ExecCGI
の一行を追加する必要があるかもしれません。

あとは、ブラウザで、そのCGIにアクセスするだけです。例えば、
http://www.example.com/hd_installer.cgi
など。

あとは画面に表示される手順に従うだけで、インストーラ画面が開きます。tar.gzアーカイブを、パーミッション保存したまま展開するので、cache, uploads, mainfile.php などのパーミッションをFTPで変更する必要すらありません。「５分でインストール」どころか２分を切れそうです

一度遊びで試してみれば、その簡単さに驚くはずです。

ただ、「遊び」とは言っても、ローカルでテストしたら、たいがいうまく行きません。xampp環境ではそもそもbashがないでしょうし、自宅サーバなどに*nixをインストールして開発に使っているケースでも、ちゃんとsuExecを有効にしていることはほとんどないでしょう。このCGIは、suExecを有効にしている共有型レンタルサーバでないと動かないし動かす意味もない、ということをお忘れなく。


●余談

wgetで取得可能なアーカイブは、 http://downloads.sourceforge.net/hodajuku/ 直下のファイルに限定されます。ただ、サーバがファイルをリモートから取ってくる形ではなく、CGIと同一フォルダにアーカイブを用意しておけば、一部のモジュールのインストールにも利用可能です。少なくとも私のD3モジュールであれば、そのまま行けます。（もっとも、そのほとんどがHDに同梱されているのでほとんど意味はありませんが）

なお、XCL2.1.xはなぜかzipしか用意がないので、この手が使えません。もちろん、unzipコマンドを使えば解凍できるので、そのようにCGIを改変すれば良いのですが、unzipはあまり一般的ではないので、そういうコードにしていません。さらにzipにはパーミッションの概念がないので、解凍したファイル群に対するパーミッション変更までCGIに記述する必要があります。


このタイプのインストーラに興味があるなら、ぜひhd_installer.cgiを改変してください。
スパゲッティになりやすいbashスクリプトにしては、そこそこ見やすく再利用しやすいコードとなるよう努力したつもりです。スクリプトの最初の方にある定数定義だけいじれば、ImpressCMSや本家版XOOPSにも利用できるでしょう。再利用しやすいように、ライセンスも修正BSDとしてあります。


今回はインストーラでしたが、このシステムが本当に効いてくるのは、むしろアップデータでしょう。大量のファイルをFTPで上書きアップロードするというのは、本当に面倒です。しかもインストール時よりもさらに、途中で切れたかどうかの判断が難しくなります。

さらに、アップデータであれば、インストールされた情報（XOOPSであればmainfile.php）を参考にすることが出来るので、インストーラのようにリクエストに依存する必要がなくなります。つまり、サーバに置きっぱなしでも良いようなCGIを作れる可能性はあります。

次回はそのアップデータを作ってみたいと思います。