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
This archive was generated by hypermail 2b30 : Thu Jun 14 2001 - 09:24:50 PDT