Topic: [Urgent] Searching in form generates fatal error (Read 3299 times)

sibas · « **on:** March 22, 2012, 11:27:46 pm »

One friend that have site running snews, report me that they have attempt to hack his site,
his host send him email and say that have problems with the specific script because of memory leaks, said also that site goes down if he don't fix the problem.
I trying to help him and I discover at list one search query that makes this fatal
search with query
id <> 3
fatal generate in
function filterTags
line: $fromTagOpen = substr($postTag, 1);

mosh · « **Reply #1 on:** March 23, 2012, 07:11:02 am »

hi sibas,
here is a first aid fix:

1. in function search ->
first line -> comment out -> $search_query = clean(cleanXSS($_POST['search_query']));

2. add this code under the commented line from step 1
# do not copy the php tags.

Code: [Select]

<?php
		if(isset($_POST['search_query'])){
			$find = clean($_POST['search_query']);
			$find = strip_tags($find); 
			$find = trim ($find);
			$search_query = $find;
		}
?>

hope it help

mosh · « **Reply #2 on:** March 23, 2012, 07:29:11 am »

if you type id <> 3
in a comment and post it, you get the same
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 33554447 bytes)

it looks like functions cleanXSS and filterTags needs fix.
to test to problem add this to index:

Code: [Select]

$source = 'id <> 3';
$source = cleanXSS($source);
echo $source;

you get the same
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 33554447 bytes)

this could effect snews where ever cleanXSS being used.
single user
comments, contact, search are at risk.
MU
articles, comments, contact, search are at risk.

UPDATE:
temporary global fix is to replace cleanXSS,
comment out function cleanXSS, and add this above it

Code: [Select]

// fatal error temporary fix
	function cleanXSS($val){
		if($val!=""){
			$find = clean($val);
			$find = strip_tags($find); 
			$find = trim ($find);
			$search_query = $find;
		}
		return $search_query;
	}

sibas · « **Reply #3 on:** March 23, 2012, 01:13:02 pm »

As I see from the logs they try many xss script in searchform
I realize that anything you query with <> makes that fatal error.
As mosh say this happen also in comments!!

sibas · « **Reply #4 on:** March 23, 2012, 01:24:54 pm »

Mosh, I have update function cleanXSS with

Code: [Select]

// fatal error temporary fix
	function cleanXSS($val){
		if($val!=""){
			$find = clean($val);
			$find = strip_tags($find); 
			$find = trim ($find);
			$search_query = $find;
		}
		return $search_query;
	}

and still log the queries from searchform, if see anything that are suspicious I report it.

I hope to get rid from those because is bad to lost his site from some scriptkids.

mosh · « **Reply #5 on:** March 23, 2012, 01:40:23 pm »

this replacment function is only temporary,
the cleanXSS function needs to be fixed, it is being used meny times.

this replacment clean all tags and is being used in articles,
this limit the text input, contact and comments as well.

sibas · « **Reply #6 on:** March 23, 2012, 02:23:13 pm »

Yes I know
at list temporary with this code maybe stop to have those fatal error as they try every day..
And maybe stop to complain host about memory leaks.

sibas · « **Reply #7 on:** March 24, 2012, 05:04:37 am »

I am curious why no one of the sNews dudes don't have make any comment or ask something about this issue,
I think is very serious subject as any site use sNews can go down with this memory leak!!

mosh · « **Reply #8 on:** March 24, 2012, 09:03:52 am »

UPDATE:
a fix to original cleanXSS function,

1. find cleanXSS() -> while($source != filterTags($source)) {
2. replace the while with if like this -> if($source != filterTags($source)) {

i did some tests with XSS attacks and this fix works fine so far,
the tests i did ( add this code to index.php, uncomment to test different attacks ):

Code: [Select]

<?php
# XSS ATTACK TESTS
 	$source = 'id <> 3';
// 	$source = 'id < > 3';
// 	$source = '<HTML><BODY><?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time"><?import namespace="t" implementation="#default#time2"><t:set attributeName="innerHTML" to="XSS&lt;SCRIPT DEFER&gt;alert(&quot;XSS&quot;)&lt;/SCRIPT&gt;"></BODY></HTML>';
// 	$source = '<EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED>';
// 	$source = '<!--[if gte IE 4]><SCRIPT>alert(\'XSS\');</SCRIPT><![endif]-->';
// 	$source = '<XSS STYLE="xss:expression(alert(\'XSS\'))">';
// 	$source = '<DIV STYLE="background-image: url(javascript:alert(\'XSS\'))">';
// 	$source = '<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">';
// 	$source = '<STYLE>@import\'http://ha.ckers.org/xss.css\';</STYLE>';
//	$source = '<BR SIZE="&{alert(\'XSS\')}">';
// 	$source = '<BGSOUND SRC="javascript:alert(\'XSS\');">';
//	$source = '<SCRIPT/SRC="http://ha.ckers.org/xss.js"></SCRIPT>';
	echo cleanXSS($source);
?>

all the sample attacks was tested on the search form as well and on comments.

please, test this fix and report.

Keyrocks · « **Reply #9 on:** March 24, 2012, 08:36:00 pm »

I'm just one of the "Dudes" and I have been busy off-line for a few days.

function cleanXSS($val) uses the preg_replace() PHP function to search through any subject (content) - the $source in this case - looking for a match to a pattern (defined with a regular expression) and replaces that pattern with a replacement, which then becomes the $source that gets through.

Example: $source = preg_replace( pattern, replacement, $source );

There are now two $source strings in the function using preg_replace().

I am just guessing... but perhaps what we need to do is add a third string (under or before the other two) that replaces id <> 3 with a replacement, which could be empty (nothing).

I have not worked with regular expressions (regex or regexp) before but here a couple of references:

Using preg_replace()
Regular Expressions - Basic Syntax

mosh · « **Reply #10 on:** March 25, 2012, 09:59:46 am »

looks like good solution key,
we need to find the right regex to match different cases of <>, <<>>, <<|>>, etc..
if we try:
id <> 3 -> (tried to allocate 33554438 bytes)
id <<|>> 3 -> (tried to allocate 33554438 bytes)
id <><> 3 -> (tried to allocate 295895 bytes)
id <><><> 3 -> (tried to allocate 128269442 bytes)
id <><><><><> 3 -> (tried to allocate 99432545 bytes)
id ><>>>< 3
id <>> 3
we get the same error.

sibas · « **Reply #11 on:** March 25, 2012, 08:15:25 pm »

Hey key!
Pity that the other dudes have gone to holidays, karma to you for all your help you giving in this forum.

I try what mosh say above, and adding the $source = '<>'; in the while seems like work
something like this

Code: [Select]

<?php
		while($source != filterTags($source)) {
			$source = filterTags($source);
			$source = '<>';
		}
?>

philmoz · « **Reply #12 on:** April 01, 2012, 01:49:21 am »

Quote from: mosh on March 24, 2012, 09:03:52 am

UPDATE:
a fix to original cleanXSS function,

1. find cleanXSS() -> while($source != filterTags($source)) {
2. replace the while with if like this -> if($source != filterTags($source)) {

Looking at this section, if the input is hungry, then it tries to feed twice, as the function filterTags is called twice.

Code: [Select]

 while($source != filterTags($source)) { 
   $source = filterTags($source) 
}

So, I replaced with

Code: [Select]

$testSource = filterTags($source);
while($source != $testSource) {
	$source = $testSource;
}

This also removed the memory munch that an entry like id<>3 produced. Changing the 'while' as per mosh's post is also a logical move with this bit of code.

However, with either Mosh's or mine, I am getting an output that is a tad odd for this input into search => id<>3

Quote

Search results

There are no results for query id<>3 3.

mosh · « **Reply #13 on:** April 01, 2012, 04:24:43 pm »

Quote from: philmoz on April 01, 2012, 01:49:21 am

However, with either Mosh's or mine, I am getting an output that is a tad odd for this input into search => id<>3
Quote
Search results

There are no results for query id<>3 3.

the source for this odd error is at the filterTags function,
could not find why yet.

philmoz · « **Reply #14 on:** April 01, 2012, 10:46:08 pm »

Quote from: mosh on April 01, 2012, 04:24:43 pm

Quote from: philmoz on April 01, 2012, 01:49:21 am

However, with either Mosh's or mine, I am getting an output that is a tad odd for this input into search => id<>3
Quote
Search results

There are no results for query id<>3 3.

the source for this odd error is at the filterTags function,
could not find why yet.

If I replace 'while' with 'if' (and remove the 'continue;' lines), the extra bit goes, but if I use id<<>>3 as search argument, I get the "not enough characters" search error"

News:

Author Topic: [Urgent] Searching in form generates fatal error (Read 3299 times)

sibas

[Urgent] Searching in form generates fatal error

mosh

Re: [Urgent] Searching in form generates fatal error

mosh

Re: [Urgent] Searching in form generates fatal error

sibas

Re: [Urgent] Searching in form generates fatal error

sibas

Re: [Urgent] Searching in form generates fatal error

mosh

Re: [Urgent] Searching in form generates fatal error

sibas

Re: [Urgent] Searching in form generates fatal error

sibas

Re: [Urgent] Searching in form generates fatal error

mosh

Re: [Urgent] Searching in form generates fatal error

Keyrocks

Re: [Urgent] Searching in form generates fatal error

mosh

Re: [Urgent] Searching in form generates fatal error

sibas

Re: [Urgent] Searching in form generates fatal error

philmoz

Re: [Urgent] Searching in form generates fatal error

mosh

Re: [Urgent] Searching in form generates fatal error

philmoz

Re: [Urgent] Searching in form generates fatal error