bugtraq - RE: Invision Vulnerabilities, including remote code execution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <001901c6697a$e58df450$e69b830a@newbie>
Date: Wed, 26 Apr 2006 22:46:37 +0100
From: "Mike Weller" <mike@...1er.co.uk>
To: "'Steven M. Christey'" <coley@...re.org>,
	<bugtraq@...urityfocus.com>
Subject: RE: Invision Vulnerabilities, including remote code execution

Response inline

> -----Original Message-----
> From: Steven M. Christey [mailto:coley@...re.org] 
> Sent: 26 April 2006 20:41
> To: bugtraq@...urityfocus.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