PEAK XOOPS - News

Japanese people do the general housecleaning at the end of week.
I do the cleaning of the altsys codes which are quite dirty.

I've cleaned myblocksadmin up.
And I dropped codes for XOOPS2.2 and common/spaw as trash.

Newly, altsys supports ImpressCMS.
It makes all "D3 Modules" can work fine with ImpressCMS.
Though I don't have time to test XOOPS 2.3, altsys perhaps works fine if XOOPS 2.3 is structurally identical with ImpressCMS.

And altsys starts to support common/fckeditor (fckxoops) for custom block's WYSIWYG editing.

And so on..

Since the new myblocksadmin is fully scratched, it might includes some bugs.
I'll be appreciated if you report bugs.

xoops.org (Mamba) annouces a news.
Security : Protector Security Fix for XOOPS 2.0.x and 2.2.x users

I can say it is a non-sense report then just ignore it.
(Inside XOOPS_TRUST_PATH LFI )

There are many Web applications structured with both public codes (inside DocumentRoot) and private codes (outside of DocumentRoot).
You know such applications have better structures than older applications like XOOPS.

If someone put private codes inside DocumentRoot and accesses private codes via httpd directly, there looks a lot of security problems.
But, none send such a stupid report.
Because all security experts know the meaning of inside/outside DocumentRoot well.

XOOPS_TRUST_PATH must be placed outside of DocumentRoot.
This is an important principal.

This news reveals the members of xoops.org don't know the basic of the security at all.

On the other hand, the developpers of ImpressCMS know the meaning of XOOPS_TRUST_PATH well.
eg) ImpressCMS stores a file for "DB password etc." under XOOPS_TRUST_PATH.

This is my conclusion:
Choose ImpressCMS rather than a CMS named XOOPS from xoops.org.

A command execution vulnerability has found at the library "Snoopy".
http://secunia.com/Advisories/32361/

But calm down, guy.
All XOOPS forks never pass arbitrary URIs into Snoopy.
And almost modules using Snoopy allow to set URIs only by administrators.
Just update the releasing version later.

But, if you allows guests or incredible users to set URI using Snoopy, you have to patch it urgently.

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)
                {

I've continued to criticize XoopsErrorHandler since XOOPS-2.0.4 released.

There are three reasons:

(1) XoopsErrorHandler ignores the setting of php and messages are displayed
(2) If there are parse errors in codes, the error handler cannot work fine
(3) There are no way to override the handler if attackers access un-intended URI directly

In the other words, the setting of php must be the most important, hence such a handler looks non-sense for other than limited conditions.

Then, we should disable such a error handler, and control it via the setting of php (.htaccess or php.ini).

Especially, XoopsErrorHandler changes the level of error_reporting arbitrarily, thogh you set the level by .htaccess/php.ini explicitly.
Such a bad class should be dropped, right now.


Fortunately, XCL can do that without core hacks, however it is necessary to hack the core (include/common.php etc.) for the other X2 forks.

This is the preload.
http://www.peak.ne.jp/support/xoops/Preload_ErrorHandlerOriginal.zip

After you set this preload, you can recover the controls against php errors.


For both of developpers and site owners, it must be the best way to handle errors by log.

You may say...
"display_errors will be usefuler than log_errors for debugging"

I can deny it easily.
Just try

$ tail -f error_log

php_flag display_errors off
php_flag log_errors on
php_value error_log (a_file_you_like)
php_value error_reporting 2047

= Introduction =

It is hard to upload massive files into shared hosting services via FTP, as you know.
It often causes some missing uploading easily, and you will get many troubles after installing.

But, CGI will run with suExec under such shared hosting services.
This fact offers you to extract any archives via CGI.
You are always ower of extracted files.

And you can get the archive via wget.
(Note: the URI should not be depended on requests against the CGI. If you make such a CGI, it causes serious security holes)

Then, I've written a installer "Hodajuku Distribution for XCL2.1" (HD-1.0.2).
You can get it from here
http://www.peak.ne.jp/support/xoops/hd_installer.zip

= How to use =

- extract the zip
- upload hd_installer.cgi into DocumentRoot or its subfolder
- chmod 755 hd_installer.cgi
- access via web browser eg) http://www.example.com/hd_installer.cgi

It looks quite smooth.
You are free from:
- downloading the archive into your local computer
- uploading massive files into the server via ftp
- chmod uploads/cache/templates_c/mainfile.php

Note(1):
You must test the CGI at shared servers.
Because the CGI cannot run with almost local environment.
eg)
xampp: there is no bash
local linux: suExec disabled (perhaps)

Note(2):
You never forget removing hd_installer.cgi just after installation.

= Examination =

If you are interested this kind of installer, try to hack hd_installer.cgi
I wrote the script easy to hack as possible.

Just by modifying some lines of 'declare' in the top of the script, you can make "ImpressCMS Installer" or "XOOPS2.3 Installer".

The script is under licensed "New BSD".

This system must be really useful as "updater" of modules or the core.
As the updater can use information from mainfile.php, it might be moderately secure.

I'll make such a updating CGI by bash