Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: Invision Vulnerabilities, including remote code execution
From: "Mike Weller" <mike () we11er co uk>
Date: Wed, 26 Apr 2006 22:46:37 +0100

Response inline

-----Original Message-----
From: Steven M. Christey [mailto:coley () mitre org] 
Sent: 26 April 2006 20:41
To: bugtraq () securityfocus com
Subject: Re: Invision Vulnerabilities, including remote code execution


 sources/action_public/search.php line 1261  $this->output = 
preg_replace(  
"#(value=[\"']{$this->ipsclass->input['lastdate']}[\"'])#i", "\\1  
selected='selected'",  $this->output );

...
an #e modifier is added and then %00 used which will be parsed as a 
null byte and truncate the string thus removing the original 
)#i part.

This is a very interesting bug: modifying a regular 
expression in a way that accesses the execution functionality.


In general, regexp hacking seems to be a fruitful area for research.
As another example, null characters have been used to bypass 
security-relevant regexp checks.


Indeed. Invision is (to be frank) an appalling example of handling user
input. Posts go through a plethora of regexes, and there are
canonicalization issues all over the place with html and url escaped codes
(&#...; and %xx) being decoded where they shouldn't be decoded. Posts go
through numerous conversions on their way in to the database (where they are
mixed with HTML) and also on their way out, opening up a whole range of
potential vulnerabilities.

One example of this (that should work in current versions) is to insert the
following code into a new post:

&#x3c;&#x61;&#x20;&#x68;&#x72;&#x65;&#x66;&#x3d;&#x22;&#x23;&#x22;&#x20;&#x6
f;&#x6e;&#x6d;&#x6f;&#x75;&#x73;&#x65;&#x6f;&#x76;&#x65;&#x72;&#x3d;&#x22;&#
x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;&#x61;&#x6c;
&#x65;&#x72;&#x74;&#x28;&#x27;&#x48;&#x65;&#x79;&#x20;&#x74;&#x68;&#x65;&#x7
2;&#x65;&#x27;&#x29;&#x3b;&#x22;&#x3e;&#x48;&#x6f;&#x76;&#x65;&#x72;&#x20;&#
x6f;&#x76;&#x65;&#x72;&#x20;&#x74;&#x68;&#x69;&#x73;&#x3c;&#x2f;&#x61;&#x3e;

Decoded this is:

<a href="#" onmouseover="javascript:alert('Hey there');">Hover over this</a>

Somewhere in the source of IPB, this is decoded and ends up in the resulting
post.

Another problem is PHP's strings. All sorts of strange and wonderful things
happen when you start inserting line breaks, nulls, and backspaces (\x08).

I think an important area of development for modern web languages would be
to mark strings as being 'safe' (escaped) or not... and making it as hard as
possible for a programmer to use unsafe strings. I've even written a short
page describing an idea for a PHP class that should help developers avoid
issues with sanitation/escaping:

http://www.we11er.co.uk/programming/safestring.html 


As "input validation" becomes more frequent, it seems likely 
that these kinds of vulns will be introduced more often.  
Other languages with rich regexp capabilities might be 
subject to similar issues.

- Steve


Mike


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]