http://xoops.peak.ne.jp/ Support&Experiment Fri, 24 May 2013 00:59:26 +0900 http://backend.userland.com/rss/ XOOPS News gij@peak.ne.jp gij@peak.ne.jp en http://xoops.peak.ne.jp/images/logo.gif http://xoops.peak.ne.jp/ 144 80 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=481 http://www.viruslist.com/en/weblog?discuss=208187897&return=1 A notify system for such worms via FTP has just been implemented in Protector-3.50. It checks mtime of XOOPS_ROOT_PATH and mtime/inode of XOOPS_ROOT_PATH/index.php It works like a noisemaker in banks. Though it cannot protect any manipulation of your site, you can avoid to scattering such worms from your site by the notifying mail. Of course, the first priority must be "Keeping the client secure from such worm". And it might be better "Watching sites by each other" than "Watching a site by myself" if we implement an observing system for servers. Wed, 18 Nov 2009 03:46:16 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=481 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=480 Now I've never heard bad side effects about DBLayer-Trapped-Anti-SQL-Injection. Thus, I've numbered 3.4 for Protector as STABLE version. And the module name has been changed from "Xoops Protector" into "Protector" after 3.4.x. During beta testing Protector 2.3.x: - ImpressCMS 1.1.2 - XoopsCube Legacy 2.1.7 These cores have the feature for DBLayer-Trapping. I thank these core developpers about it. :worshippy: As the acknowledgemet, I've added optimized module_icon for each cores like ImpressCMS 1.2 or XCL2.1 I also thank to Rene Sato telling me information about ImpressCMS 1.2 # I've found a bug in upgrading script in ImpressCMS 1.2 beta. /upgrade/upd-icms-1.0-to-1.1/settings_salt.php line 46 [code] if ( !isset( $vars['DB_SALT'] ) ) { require_once ICMS_ROOT_PATH.'/class/icms_Password.php' ; $icmspass = new icms_Password(); $vars['DB_SALT'] = $icmspass->icms_createSalt(); } [/code] Regards! Thu, 17 Sep 2009 13:18:44 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=480 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=479 Some SPAMs were posted into this site. "how can I get a newer version?" or "this is useful!" It looks not a SPAM just a grance. Judging by access.log, such posts must be made by not machine but human. sigh... Then, I'm trying a filter disabling posts from someone registering this site within 60 minutes. If you are annoyed such a SPAM, try the latest Protector (3.36a). just copy filsters_disabled/postcommon_post_register_moratorium.php into filsters_enabled/ Sat, 29 Aug 2009 04:38:48 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=479 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=478 I met gigamaster yesterday, in Hotel New Otani of Tokyo. He looks great. a nice guy, indeed. Because of my poor skills of English conversations, we could not communicate each other enough. But I feel his passion about "open source". As gigamaster's posts sound bitter (^^;, he is misundestood in the community of ImpressCMS or xoops.org. After the meeting, this is just a problem of missing communications. "Open source projects" are often developped "on line" only. But, I convinced "off line meetings" raise them higher stages. Sat, 25 Apr 2009 05:38:35 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=478 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=476 a XSS is found in piCal-0.91h You'd better to select just ONE of these actions (1) update piCal into the latest version >= 0.92 - recommend for site owners using piCal as is (2) overwrite just piCal/index.php in the latest archive - recommend for site owners using piCal with some hacks (3) patch piCal/index.php manually - recommend for experts. it's an easy patch line 154 in index.php [code] $xoopsTpl->assign( 'print_link' , "$mod_url/print.php?event_id={$_GET['event_id']}&action=View" ) ; $xoopsTpl->assign( 'print_link' , "$mod_url/print.php?event_id=".intval($_GET['event_id'])."&action=View" ) ; [/code] If you use Protector and turning "enable anti-XSS (BigUmbrella)" on, don't worry about it. The feature of "anti-XSS" can protect attacks via XSS entirely. Anyway, you'd better update piCal if you use older piCal. And I strongly recommend you to turn "enable anti-XSS (BigUmbrella)" on, even if you use piCal. Mon, 23 Feb 2009 04:40:20 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=476 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=475 The DBLayer Trapping anti-SQL-Injection of Protector-3.30 with XOOPS2 raises a "SQL Injection" alert at updating preferences including doublequatation("). This wrong detection is caused by the wrong way to escape SQL. class/database/mysqldatabase.php [code] function quoteString($str) { $str = "'".str_replace('\\"', '"', addslashes($str))."'"; return $str; } [/code] Only XOOPS2 and XCL2.1 have such a wrong escaping method. This method should be corrected like: [code] function quoteString($str) { $str = "'".str_replace('\\"', '"', addslashes($str))."'"; $str = "'".mysql_real_escape_string($str)."'"; return $str; } [/code] On the other hand, both ImpressCMS and XOOPS-2.3.2 have a right method. However this is just a problem of the XOOPS Cube project, there can be some modules/hacks escaping SQLs like this. Then I have to modify the logic of the "DBLayer Trapping anti-SQL-Injection". (A) A request including ' or " is found in a SQL as is (without escaping) (B) All body of the request stays in single string of the SQL (not breaking quotation) When both (A) AND !(B) are found, protector stops the program as "SQL Injection found". This logic can reduce some patterns of wrong detections. Fri, 23 Jan 2009 05:47:03 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=475 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=474 We have to know comparing doubtful requests and all SQLs in the DB Layer have to pay not a few CPU band. Then, we can override the DB Layer only when "attackable requests" has come. Almost all HTTP requests never have such "attackable requests". This logic make it compatible the speed and the security. My protector find "attackable requests" by this pattern (perl regex formatted): [code] /(information_schema|select|'|")/i [/code] ' and " can break the pair of quatations. select allows attackers to access the other tables. On the other hand, it ignores union because it has non-sense without select. Marks starting commatation like (/* , -- or #) are ignored too. Such marks can get their meaning only when the pair of quatitions are broken. And $_SERVER['HTTP_ACCEPT'] often incldues a string like '*/*'. Let's go to the logic of the method query() of the Protector's DB Layer. query() compares "attackable requests" and all SQLs. There are two patterns of vulnerabilities against SQL Injection. (1) a string missing to escape (the string is origined from a request) eg) SELECT ... FROM `table` WHERE `varchar_column`='(string_missing_to_escape)' (2) a request placed into SQL as is eg) SELECT ... FROM `table` WHERE `integer_column`=(request) SELECT ... FROM `table` WHERE ... ORDER BY (request) This logic can protect almost all vulnerabilities like (1). - list requests having ' or " up - compare all SQLs and the listed requests - if a SQL includes one of the listed requests, stop it. Because ' or " should be escaped in all SQL. Of course, this logic can be too sensitive. To avoid accidental matches, we have to set the minimum length of "attackable requests". I guess "6" is the best value for the length. Because the shortest "attackable request" is here. [code] 'OR 1# [/code] On the other hand, we cannot cover the mistakes like (2) entirely. The data in the `table` can be read/lost/added as attackers like. But we can protect the other tables by these logics even if a vulnerablity like (2) exists. (A) SQL with any comment (B) If "requests including SELECT" exists outside of quotation. SQL both !(A) and !(B) can be queried. Though (A) looks too sensible, it is not troublesome at my test. Note, this overridding is rarely occured. (B) is the main logic. All attacks aiming some specific tables have to include "SELECT". To know the list of tables, attackers have to use "SELECT" from information_schema. If you want to know the implementation, try to read ProtectorMySQLDatabase.php in Protector-3.3 Fri, 16 Jan 2009 05:07:17 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=474 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=473 To Compare request and SQL, we have to override DB layer. With XOOPS, this will be implemented as a modification for databasefactory.php because the database factory class looks too rigid. This is my modification. It might be not the best way, but better way for adopted by each core teams of XOOPS forks/folks. class/database/databasefactory.php [code] require_once $file; /* patch from */ if ( defined('XOOPS_DB_ALTERNATIVE') && class_exists( XOOPS_DB_ALTERNATIVE ) ) { $class = XOOPS_DB_ALTERNATIVE ; } else /* patch to */if (!defined('XOOPS_DB_PROXY')) { $class = 'Xoops'.ucfirst(XOOPS_DB_TYPE).'DatabaseSafe'; } else { $class = 'Xoops'.ucfirst(XOOPS_DB_TYPE).'DatabaseProxy'; } $instance =& new $class(); [/code] hi minahito, marcan, and phppp. I've made the patch can be accepted for you. Please consider it. :-) At the next article, I will discuss about the condition when the db layer must be overridden, and the logic comparing requests and SQL. Thu, 15 Jan 2009 16:12:57 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=473 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=472 I've shocked just by looking inside of the archive of xoops-2.3.2b. They put XOOPS_TRUST_PATH folder inside htdocs/ ! (They renamed xoops_trust_path into xoops_lib. this fact also shows us they didnot understand the meaning of XOOPS_TRUST_PATH) Moreover, there are no .htaccess under the folder xoops_lib/ I suspect my eyes. mamba had reported LFI in the file under XOOPS_TRUST_PATH. This is another evidence they cannot understand the meaning of inside/outside DocumentRoot. When mamba said "I fixes Protector", I replied "Such a patch is non-sense". This report proves mamba's patch was just non-sense. http://www.milw0rm.com/exploits/7705 You should interpret the report is not an exploit of Protector itself but just XOOPS-2.3.2. Anyway, phppp and developpers of xoops.org should do right now: Put xoops_lib(XOOPS_TRUST_PATH) ouside of htdocs. Learn the meanining of inside/outside DocumentRoot. Read how to install Protector V3 again and again! If you cannot do that or cannot understand what I mean, remove Protector from your archive. Your wrong structure of the archive gave me pain. My module -Protector- is useful for protecting all XOOPS forks/folks from maricious attacks as long as the module is installed rightly. Fri, 09 Jan 2009 13:09:35 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=472 XOOPS http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=471 There are a lot of XOOPS modules or PHP applications with SQL Injection still. Protector can protect some patterns of SQL Injections. It is just "some" instead of "all". That's because Protector cannot distinguish attacks and fair requests just by REQUEST layer. A word of "UNION" will be posted as "UNI-ON". Such modification in REQUEST layer must be non-sense. Then, Protector should judge them by both REQUEST layer and DB layer. anti-XSS: (a) doubtful requests are found (b) ob_start() (c) compare requests and outputs SQL Injection: (1) doubtful requests are found (2) override DB layer (3) compare requests and SQLs It is not easy to implement (3) because Protector have to parse SQLs. However, (2) will be the most problem for XOOPS. Because there are no way to override DB layer. I will suggest DB layer modification can be overridden for all core teams in the next entry. This idea is based on JM2. (four years ago!) He is the real hero for XOOPS :worshippy: Wed, 07 Jan 2009 04:37:49 +0900 http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=471 PHP