TinyPortal

OK, I've been playing with the uploader script from the WhizzyWig editor. (whizzypic.php)

I started looking into it because pics I was uploading weren't being listed by the image browser pane.  Turns out it's because the file is not comparing strings case insensitive and my files had extension .JPG

But I've uncovered some really horrible flaws with the whole script.

• It doesn't authenticate you vs SMF at all.
• It pulls your user ID and the settings for how to sort images out of a cookie of all things, instead of the DB.
• It doesn't check to see if it's being called from within SMF, so you can call it from anywhere, even if WhizzyWig is disabled.
• It doesn't check the contents of the file, merely the extension, before it lets you upload.
• It uploads files to the directory specified in a GET variable in the URL.

And this is just what I've discovered so far.  There are some serious security issues with this thing.

I'm working on a fix, I'll release it back to the community when I'm done.  In the meantime, you may want to consider removing whizzypic.php from your server.

im currently using whizzywig because i get a 404 error when i try to use the FCK editor. ill wait for your fix dude. :)

OK, I believe I've closed up the holes in it.

I've attached the corrected whizzypic.php file as well as the smf_api_2 script you'll need.

The whizzypic.php inside the whizzypic.zip file needs to replace the whizzypic.php inside the \wysiwyg directory in your SMF installation.

The files smf_api_2.php and smf_api_subs.php inside the smf_api_2.zip need to be placed in the root folder of your SMF installation.

The smf_api_2 script allows us to tap into SMF's core for various things.  In this case, I'm using it to authenticate the user, and to pass the user and group information, as well as the image prefix without having all this stuff in a cookie where it used to be.  Having system settings passing around inside a cookie doesn't make much sense to me.  And it's insecure.

Since the destination image directory is hardcoded everywhere else in the TinyPortal and indeed in the FelBlog files, instead of being stored in the database somewhere, I've just hardcoded it into whizzypic.php.  When you call whizzypic, it's still passing a directory through the GET variables, but the script is now completely ignoring that value.  The script checks to see if /tp-images/Image is actually a directory, if not, it sets the directory to /images instead.

You'll need to have the exif extensions enabled on your PHP installation.  One of the big security holes in this script was that it never checked the contents of the file, just the extension in the filename, which can be easily faked.  An evildoer could stuff malicious code into a file and name it .gif and get it uploaded to the server quite easily.  So I changed things around, it's now using exif_imagetype() to check the actual contents of the file, and only allowing the upload to proceed if the image is a jpg, gif, or png.  This has the upshot of making the script insensitive to filename case.

I'm really glad it DID have a problem with filename case, because otherwise I wouldn't have even looked at this script, and I probably would have been really confused when my server got hacked.

Good luck installing it.  If you've got any problems, let me know and I'll try to work with you on it.


NOTE:  I haven't evaluated FCK for any security holes.  I didn't like its UI, so I'm not going to be using or fixing it.

PS: Sorry, but I don't know how to package my fix up as a nice little patch to go into the next version.

Thanks for pointing this out. I will look at the files attached.

The files provided in attached is not the original smf_api files, rather it seems they are modified/updated by yourself. As such i can't really support those.

But I will indeed adress the flaws you uncovered.

Bloc I use the FCK editor for both of my sites and seeing the security issue in these posts is a scary thing for anyone. Can I safely delete the whizzywig files from my installation without having any effects on theboard installation?

Yes. It will only deny people uploading through Whizzywig, and of course no direct calls. and since you don't use it, no harm. It won't harm otherwise either, just get a 404 page when trying to upload.

I will correct these things for 0.9.8.

I have used SSI.php instead, since its already present.

If you want to use this, please exchange it with the file you have currently. It does the same as the first poster posted - but without depending on a smf_api.php file.

Quote from: Bloc on February 23, 2007, 04:05:52 PM
The files provided in attached is not the original smf_api files, rather it seems they are modified/updated by yourself. As such i can't really support those.

But I will indeed adress the flaws you uncovered.

Yeah, they're not the "official" smf api file, because the "official" one, guess what, doesn't WORK with smf 1.1.1.  Yeah.  Wonderful.

This api has been extended by another user, the guy who wrote the Drupal 5.0 - SMF 1.1.1 bridge.

I see you've updated my update to use the SSI.php instead.  That sounds like a much better solution.  The only reason I used that smf_api is because it was the only way I personally knew of quickly and easily reaching the SMF internals.  I'll take a look.

Thanks!

The smf_api file hasn't been updated because SSI is meant to replace what it does, and to a large extent already does. SSI.php is actively updated and maintained + always there inside the forum while smf_api.php is not.

It still needs a bit of work.  It's relying on the no-longer-present $smf_user_info variable.

This can be easily switched to $context['user'] but I haven't figured out how to get the ID_GROUP out of that.  I'm not even exactly sure what ID_GROUP is signifying.

Using $user_info should have ID_GROUP present. Its the primary post-based membergroup.

I have changed it on my local site but will need to test it first.

well, the $user_info does not have ID_GROUP or ID_MEMBER at all.  There is a variable $ID_MEMBER available with the user's userid, but no such luck on the group.

Since I'm not really interested in categorizing images by anything but userid, I'm just going to leave the group bit broken.  I can't figure out how to get an ID_GROUP out of the system at all.

In fact, I'm rather unclear on how ID_GROUP even works.  I know it's the primary membergroup.  But how's that determined?  If you add a user to multiple membergroups, then which one is going to show in ID_GROUP?  Is there any way to predict this behavior?

The primary membergroup is stored in member table as ID_GROUP, while other groups are stored as comma divided list in AdditionalGroups, also in Member table.

The "primary" takes precedence, but you can of course check both fields, stored in $user_info.

Are you still using that ssi version of the script? if yes its still pretty dangerous to keep it because you just have to register a user to upload any script you want.
I dont know why we still had that on the server tbh since its not included in the tp downloads anymore but maybe tell people that they should seriously delete it.
There is at least one guy going around exploiting that right now. It started with a scripted attack that prepended a html comment to all index.php files (doing a backup graciously) forwarding people to a russian dating site with referal id attached.
Shame on us for not keeping our server tidy tho  ::)

edit: it/he uploaded r57shell.php (adding that here for googlers to find and link the breach to WhyzzyWig faster)
edit2: just saw that you still serve it with 0.9.8  :-X

Whizzywig is no longer a part of TP if you upgrade.

well yes but its still in http://www.tinyportal.net/index.php?action=tpmod;dl=item745 which is the "stable version" isnt it?

There has never been a "stable" release from TP yet. Although, many have called 0.9.8 the most stable release. As with all software, if you should stay up to date to avoid security issues.

tp 098 smf1.1.11 - just found/deleted a recently added r57shell.php in tp-images
can you confirm that i need to delete my whizzypic.php file?
as the patched file on page 1 of this topic wasn't present but on reading this thread wouldn't prevent this

many thx

also i have been avoiding upgrading to tinyportal10beta4 to this big forum, although i have it on newer forums. i've been keeping it because upgrade requires deleting existing version etc, but if i choose to keep it and delete the whizzy - can i simply add the fckeditor from the newer version as no fckeditor folder exists in the installation at present
many thx

I don't believe that this is something that can be easily done.  The best thing to do would be to uninstall the version you have and upgrade to the latest version.

ZarPrime

Remove ALL whizzywig files before installing beta4, to be sure they are not present.

Whizzywig is still used in beta4, but using a newer version AND without the upload addon for it, which was the one item that was unsecure. Instead its now using TP's internal upload function (that do check permissions) and  insert the images into articles. It also sorts the uploads on author, so you only see "your" uploads - even if they all are in the same directory at the server.