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 executionsources/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: <a href="#"  f;nmouseover="&# x6a;avascript:al ert('Hey the 2;e');">Hover &# x6f;ver this</a> 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
Current thread:
- Invision Vulnerabilities, including remote code execution spam (Apr 25)
- <Possible follow-ups>
- Re: Invision Vulnerabilities, including remote code execution Steven M. Christey (Apr 26)
- RE: Invision Vulnerabilities, including remote code execution Mike Weller (Apr 30)
- Re: Invision Vulnerabilities, including remote code execution mattmecham (Apr 27)