> 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 ( clambertat_private ), > 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:johnat_private > > "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.
This archive was generated by hypermail 2b30 : Fri Jun 15 2001 - 11:19:18 PDT