> 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
( [EMAIL PROTECTED] ),
> 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:[EMAIL PROTECTED]
>
> "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.
