Re: The Dangers of Allowing Users to Post Images

[David Dreezer <bugtraq () infopop com>]

> This exploit shows how almost any script that 
uses cookie session/login data
> to validate CGI forms can be exploited if the 
users can post images.
> One of our developers, Chris 'stallion' Lambert 
( clambert () whitecrown net ),
> discovered this exploit in a routine internal 
security audit.
> Allowing users to post inline images is 
potentially a bad thing. Having the
> user authentication based solely on cookies is 
another potentially bad
> thing. When you put them together, it gets a 
whole lot worse. I will explain
> this problem with reference to a typical forum 
system, but naturally, it can
> be extended to almost any other CGI script, not 
just limited to PHP scripts.
> We have also tested this with Infopop's Ultimate 
Bulletin Board 6.04e,
> ezboard 6.2 and WWW Threads PHP 5.4, and at the 
time of writing, all three
> were susceptible to attack.
>
> What is the problem? Well, by using an [img] (or 
HTML <img> or <iframe> or
> <script src="">) tag, the user is having anyone 
who views the thread access
> that image - that is perform an HTTP GET on the 
URL specified for the image.
> Even if its not an image, it still can be 
accessed, but will display a
> broken image. This means that the user can put a 
CGI script inside [img]
> tags. This script will be called by whoever 
views that thread. When used
> maliciously, it could force the user to: 
unknowingly update their profile,
> respond to polls in a certain way, post new 
messages or threads, email a
> user with whatever text they want, the list goes 
on. This would be
> particularly worrying for a 'worm' to spread 
through a forum, filling it
> with rubbish posts.
>
> For example, if a user posted something along 
these lines:
>
[img]http://your.forums/forums/newreply.cgi?action
=newthread&subject=aaa&bod
> y=some+naughty+words&submit=go[/img]
> Then the post would go through, under the name 
of whoever viewed the image.
> This is of particular danger when an 
administrator views an image, which
> then calls a page in an online control panel - 
thus granting the user access
> to the control panel.
>
> How can it be fixed? Well, there are a couple of 
ways to stop it, but the
> easiest (in PHP at least) seems to be to have 
most of the variables used by
> scripts be used through $HTTP_POST_VARS. So 
instead of checking for $action
> in a script, $HTTP_POST_VARS['action'] would be 
checked. This forces the
> user to use a POST request, not a GET. 
Alternatively, the sessionid could be
> required to come with the GET/POST request 
variables, rather than by cookie.
> Finally, in the specific case of [img] tags, the 
use of ? or & in the img
> URL can be disabled by some regexes.
>
> If the software that you run is not secure, we 
recommend that you disable
> HTML and/or [img] tags, until the fixes have 
been implemented.
> Known Vulnerable: Infopop's UBB 6.04e (probably 
the whole 6.xx series),
> ezboard 6.2, WWW Threads PHP 5.4, vBulletin 
2.0.0 Release Candidate 2 and
> before (later versions are safe). Probably many 
more bulletin boards and CGI
> scripts out there, but those are the main ones 
that we have been tested
> positive.
>
>
> John Percival
> Product Manager, vBulletin
>
> http://www.vbulletin.com/
> mailto:john () vbulletin com
>
> "vBulletin: Community Instantly"
>
>
>
> Copyright 2001 Jelsoft Enterprises Ltd
 
Infopop Corporation's current version of the 
Ultimate Bulletin Board™ Version, 6.04f (released 
06-12-2001 05:58 PM), does not have this 
vulnerability. Our OpenTopic™ product has never 
had this vulnerability.