PEAK XOOPS - ProtectorにLFIだそうです(笑) in englishin japanese

Archive | RSS |
XOOPS
XOOPS : ProtectorにLFIだそうです(笑)
Poster : GIJOE on 2008-11-29 04:45:23 (15939 reads)

in englishin japanese
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の方がお勧めだと言えるでしょう。


Related articles
Printer friendly page Send this story to a friend

Comments list

nitinshah12  Posted on 2008/12/5 19:53
Quote:
hi nitinshah12

Quote:


As a user of xoops what I would like to know is since my webhost does not allow creating folder outside rootfolder, what according to you should i do to fix this issue.

Just "create"?
If you mean create/read, it might be the open_basedir restriction.

Then you have to make XOOPS_TRUST_PATH inside your "rootfolder" (DocumentRoot) then put .htaccess "DENY FROM ALL".

You can check whether the .htaccess works fine via Protector's "Security Advisory".

Normally, you will get 403 error.
This means OK.
If your host disallows (not ignores) .htaccess, then you will get 500 error (Internal Server Error).
It is OK also.

Thanks a lot
GIJOE  Posted on 2008/12/5 3:48
hi nitinshah12

Quote:

As a user of xoops what I would like to know is since my webhost does not allow creating folder outside rootfolder, what according to you should i do to fix this issue.
Just "create"?
If you mean create/read, it might be the open_basedir restriction.

Then you have to make XOOPS_TRUST_PATH inside your "rootfolder" (DocumentRoot) then put .htaccess "DENY FROM ALL".

You can check whether the .htaccess works fine via Protector's "Security Advisory".

Normally, you will get 403 error.
This means OK.
If your host disallows (not ignores) .htaccess, then you will get 500 error (Internal Server Error).
It is OK also.
nitinshah12  Posted on 2008/12/5 1:36
Gijoe,
As a user of xoops what I would like to know is since my webhost does not allow creating folder outside rootfolder, what according to you should i do to fix this issue.
GIJOE  Posted on 2008/12/3 13:15 | Last modified
in englishin japanese
つまらない誤解を招きたくないので、元の文書は日本語で書きます。
オリジナル文書は日本語なので、英語を読んで疑問に思ったら、日本語の方を訳してください。

まず最初に、絶対に譲れない線を書いておきます。
「XOOPS_TRUST_PATH 内にアクセスできないこと」というのは、「努力目標」ではなく「仕様」です。

確かにDocumentRoot外にファイルを置けないようなホスティングサービスは事実としてあります。また、XOOPS_TRUST_PATH直下に.htaccessを置いても無視されるケースもなくはないでしょう。

しかし、その両方を兼ね備えてしまうような基本的にクソなサーバが実在することをもって、プライベートエリアを必要とするプログラム(この場合はProtector)にセキュリティ上の問題が発生したと言うのは明らかに論理的な間違いでしょう。

もしそういう論法が成立するなら、ほとんどすべてのWebアプリケーションが脆弱性を持つことになります。CakeでもEthnaでも、DocumentRoot外に置くべきファイル群というのがありますから。


そして、ニュースエントリそのものも論理的に間違っています。Protectorにセキュリティ問題が見つかったのでもなんでもなく、XOOPS_TRUST_PATH 内の直アクセスについての注意喚起が足りなかった、という話題にすぎないでしょう。問題にすべきは、インストーラやドキュメントの方でしょう。

さらに、それによってxoops.orgが用意したProtectorへのパッチがふるってます。
// Validates $xoopsConfig['language'] in case xoops_lib is located inside webroot
$language = empty($xoopsConfig['language']) ? "english" : preg_replace("/[^a-z0-9_\-]/i", "", $xoopsConfig['language']);
なんでプライベートエリアに置かれることが大前提であるファイルに、いちいちpreg_replace()なんて重い「サニタイズ」処理を入れなきゃいけないのでしょうか。

そういう馬鹿げたチェックが嫌だからこそ、XOOPS_TRUST_PATHという概念を持ち込んでいるんです。preg_replace()はもちろん論外ですが、もっとずっと軽い処理である
if( ! defined( 'XOOPS_TRUST_PATH' ) ) exit ;
てな一行を各ファイルの先頭に入れる、という妥協案さえも受け入れることはできません。

なぜなら、それは「XOOPSにもプライベートエリアが必要だ」ということを理解して、XOOPS_TRUST_PATHという概念に賛同してくれた他の開発者全員への裏切り行為になるからです。

もしProtectorがそういう改変を受け入れてしまったとしたら、他のD3モジュール群すべてに同じ改変が必要になるでしょう。TRUST内には各種ライブラリ・キャッシュ・アップロードファイル・ログ・セッション等、直アクセスを想定していないファイル群がごまんと置かれます。それらをどうしろというのでしょう?

一応、phppp氏との約束もあるので、Protector 3.22のセキュリティガイドに、XOOPS_TRUST_PATHがちゃんとプライベートになっているかどうか、というチェッカを実装しておきました。
(ROOT_PATHとTRUST_PATHの相対パスをとって、直アクセスを試みるもの)

それが私からの最終回答です。
gigamaster  Posted on 2008/12/2 3:46 | Last modified
Hi All,

Honestly, I was expecting such discussion ^^
and only wonder how long it will take to be public.

Xoops.org is not Xoops2 but Xoops Sphere
DJ and Mamba are doing the same as Herko
and the guys of Impresscms did some time ago
- patchwork and misinforming community to
capitalize the project for own benefit.

Both Xoops Sphere and Impresscms are forks
of original Xoops2 and both are not secure.
Too bad that you just get it now !

XOOPS Cube is the logical suite of Xoops2
Minahito rewrite the code from scratch.
XC founder is also the one of Xoops2.

To be fair to the community, from the front page of xoops.org
we should have the original logo of Xoops2 and a short information
explaining the events: "Since the founder left in 2005 Xoops has multiple forks"
followed by the logos of XC Legacy, Xoops Sphere and Impresscms

Nobody is perfect. But we can try to be honest and do better.

Have Fun
McDonald  Posted on 2008/11/29 10:19
Quote:
However, some of our users don't have the ability to do it due to their host.

I have to agree with Mamba on this point.

Even with ImpressCMS it's possible to have the XOOPS_TRUST_PATH inside the DocumentRoot. ImpressCMS can create it outside DocumentRoot automatically (if allowed by host), but a user can enter a path inside DocumentRoot manually.
mamba  Posted on 2008/11/29 5:20 | Last modified
GIJoe,
Yes, we know this very well, and we recommend every time to place XOOPS_TRUST_PATH outside of the DocumentRoot!

If you read our Installations Guidelines, as well as our "A Guide to Make your XOOPS Installation even more secure" it's stated there again and again.

However, some of our users don't have the ability to do it due to their host. Of course, they can change the host. Or others might not read it, because they never read instructions.

We received a report from Digital Security Research Group, and we acted on that. I think, it's a responsible thing to do and I think it's better to prevent a problem and help a user, than tell the user "You're stupid and it's your fault that you placed XOOPS_TRUST_PATH inside the DocumentRoot".

This the same way why we have airbags and safety belts in the car. As a car manufacturer you could say: "Everybody knows that they should drive carefully, and if they don't know how to drive, it's not our problem". But because accidents happen, that's why we install the extra safety measures, and thus save lives.

You can claim that ImpressCMS knows better about security, but they have their share of security breaches and vulnerabilities as well:

http://www.securityfocus.com/archive/1/498734
http://community.impresscms.org/modules/smartsection/item.php?itemid=261

so I don't think that your statement is fair.

You're the best Security expert in the XOOPS community, and everybody in the community respect you for it, and it would be nice if you could share your know-how with us and help us to support our users, instead of shooting at us. We never had any other intentions than to help our users!

We believe that as a Open Source project we have the responsibility to help our users and look after them. And that's exactly what we've done here. Yes, if their XOOPS_TRUST_PATH is outside of DocumentRoot, they don't have to worry. But if we would do today a survey, we would find out that there are many users who still didn't place it outside.

And for this reason we believed that it's "Better safe than sorry" and that's why we've provided this patch. If we save even one user from being hacked, then it was worth it for us!
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!