vBulletin Bulletin Board Software Lets Remote Users Cause Other Users to Execute Bulletin Board CGI Commands Without Warning
SecurityTracker Alert ID: 1001765|
SecurityTracker URL: http://securitytracker.com/id/1001765
(Links to External Site)
Date: Jun 16 2001
Execution of arbitrary code via network|
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes |
Version(s): 2.0.0 Release Candidate 2 and earlier|
A vulnerability has been reported in the vBulletin bulletin board software (as well as several other bulletin board products). The security hole lets remote users post inline images containing CGI commands that will be automatically executed by any user viewing the post.|
A remote user can place a URL or script within an image tag (e.g., [img] (or HTML <img> or <iframe> or <script src="">) tag) such that the script will be called by whomever views that thread. The script could reportedly force the user to unknowingly update their profile, respond to polls in a certain way, post new messages or threads, email a user with arbitrary content, and perform other bulletin board commands.
An example is provided in the Source Message.
A remote user could cause another user to automatically execute bulletin board commands when they view a post. A user could be unknowingly forced to update their profile, respond to polls in a certain way, post new messages or threads, email a user with arbitrary content, and perform other bulletin board commands. |
The vendor has provided a fix in versions after 2.0.0 Release Candidate 2. See the Vendor URL support section for upgrade instructions.|
Vendor URL: www.vbulletin.com/ (Links to External Site)
Input validation error|
|Underlying OS: Windows (Any), Windows (NT), Windows (98), Windows (2000)|
Source Message Contents
Subject: The Dangers of Allowing Users to Post Images|
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@example.com ),
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:
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
Product Manager, vBulletin
"vBulletin: Community Instantly"
Copyright 2001 Jelsoft Enterprises Ltd
Go to the Top of This SecurityTracker Archive Page