The Dangers of Allowing Users to Post Images

["John Percival" <john () jelsoft 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