DANGER -- WhizzyWig is seriously flawed! (Bug fix attached)

[Ogredude]

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.

[digisubs]

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

[Ogredude]

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.

[bloc]

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

[bloc]

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.

[Yellowrose]

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?

[bloc]

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.

[bloc]

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.

[Ogredude]

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!

[bloc]

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.