PEAK XOOPS - News in englishin japanese

Archive | RSS |
Poster : GIJOE on 2008-10-30 16:04:51 (9429 reads)

in englishin japanese
A command execution vulnerability has found at the library "Snoopy".

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



Poster : GIJOE on 2008-10-15 16:28:42 (17472 reads)

in englishin japanese
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.

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

via some terminals.

The best setting for XOOPS is:
- disable XoopsErrorHandler
- set ROOT/.htaccess like this

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


Poster : GIJOE on 2008-10-09 17:45:23 (22689 reads)

in englishin japanese

= 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

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

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

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

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

Poster : GIJOE on 2008-10-08 15:32:43 (16094 reads)

in englishin japanese
I'm writing a CGI to install/update XOOPS cores/modules.
It means you will be free from "uploading/overwriting massive files via ftp" or "chmod some directories before installing".

There are too many shared web servers like:
PHP: apache module (run as apache/nobody)
CGI: suExec (run as the file's owner)
Such users must be lucky

But, I don't write the CGI by perl but bash, because perl can cause some errors depending on modules/environments.

These are Tips/Problems to write CGI by bash.

- echo HTTP response headers
Without HTTP headers, the CGI returns 500 error

- how to get requests
GET variables: parse $QUERY_STRING
POST variables: parse <stdin>
This is a sample of the parser.

	until [ -z "$query" ] ; do

- how to use associated arrays
We have to use para-assoc-arrays like:

- easy to create big holes...
We have to write the code very carefully.

- use severe "white list"
We don't have a method like htmlspecialchars()
Then we never get characters other than [a-zA-Z0-9._-].
All requests must be constructed with /^[a-zA-Z0-9._-]*$/

I produce the CGI in the next entry.
Just a moment.

Poster : GIJOE on 2008-09-12 17:23:54 (9877 reads)

in englishin japanese
I've supervised a translation of "Ajax Security" into Japanese.

"Ajax Security"
Billy Hoffman & Bryan Sullivan

This news has no values to be written in English, sorry.


« 1 2 3 (4) 5 6 7 ... 55 »
Username or e-mail:


Remember Me

Lost Password?

Register now!