Ultimate Bulletin BoardTM 6.04f

[sh4dow]

kallitera kante kanena update sto forum stin parapano ekdosi giati:<P>The Dangers of Allowing Users to Post Images (Cross-Site Request Forgeries)<BR>------------------------------------------------------------------------<P><BR>SUMMARY<P>This advisory shows how almost any script that uses cookie session/login <BR>data to validate CGI forms can be exploited if the users can post images.<P>DETAILS<P>Known vulnerable:<BR> * Ultimate Bulletin BoardT version 6.04e (and prior)<BR> * ezboard 6.2, WWW Threads PHP 5.4<BR> * vBulletin 2.0.0 Release Candidate 2 and before (later versions are <BR>safe)<P>Immune systems:<BR> * Ultimate Bulletin BoardT version 6.04f<P>Allowing users to post inline images is potentially a bad thing. Having <BR>the user authentication based solely on cookies is another potentially bad <BR>thing. When you put them together, it gets a whole lot worse. We will <BR>explain this problem with reference to a typical forum system, but <BR>naturally, it can be extended to almost any other CGI script, not just <BR>limited to PHP scripts.<P>What is the problem? Well, by using an (or HTML <img> or <iframe> or <BR><script src="">) tag, the user is having anyone who views the thread <BR>access that image - that is perform an HTTP GET on the URL specified for <BR>the image. Even if it's not an image, it still can be accessed, but will <BR>display a broken image. This means that the user can put a CGI script <BR>inside tags. This script will be called by whoever views that <BR>thread. When used maliciously, it could force the user to: unknowingly <BR>update their profile, respond to polls in a certain way, post new messages <BR>or threads, email a user with whatever text they want, the list goes on. <BR>This would be particularly worrying for a 'worm' to spread through a <BR>forum, filling it with rubbish posts.<P>For example, if a user posted something along these lines:<BR>[*img]http://your.forums/forums/newreply.cgi?action=newthread&subject=aaa&body=some+naughty+words&submit=go[/*img]<P>Then the post would go through, under the name of whoever viewed the <BR>image. This is of particular danger when an administrator views an image, <BR>which then calls a page in an online control panel - thus granting the <BR>user access to the control panel.<P>How can it be fixed? Well, there are a couple of ways to stop it, but the <BR>easiest (in PHP at least) seems to be to have most of the variables used <BR>by scripts be used through $HTTP_POST_VARS. So instead of checking for <BR>$action in a script, $HTTP_POST_VARS['action'] would be checked. This <BR>forces the user to use a POST request, not a GET. Alternatively, the <BR>sessionid could be required to come with the GET/POST request variables, <BR>rather than by cookie. Finally, in the specific case of tags, the <BR>use of ? or & in the img URL can be disabled by some regexes.<P>If the software that you run is not secure, we recommend that you disable <BR>HTML and/or tags, until the fixes have been implemented.<P>Possible workaround:<BR>Verifying that a valid image was posted, for example test for its image <BR>size, and reject it if it is invalid:<P><?php<BR>file://quick sample code follows<BR>file://$imagePath is the URL provided; doesn't matter if its via GET or POST<P>$imageInfo = getImageSize($imagePath);<P>if(!$imageInfo)<BR>{<BR>print("Sorry, image cannot be opened or is not a valid image type.");<BR>}<BR>elseif($imageInfo[0] >= 800 || $imageInfo[1] >= 600)<BR>{<BR>print("Sorry, image too big");<BR>}<P>file://and so on<BR>?><P><BR>ADDITIONAL INFORMATION<P>The information has been provided by <mailto:[email protected]> <BR>Chris 'stallion' Lambert, <mailto:[email protected]> John Percival, <BR><mailto:[email protected]> Ben Gollmer and <mailto:[email protected]> <BR>David Dreezer.<P>.. kai o noon noito

[-nick-]

Nai..ALLA ANTI na kanoume anabathmish,mporoume na kanoume auto pou leei OXI emeis dhl.,o Hal..