Photopost vBGallery Exploit

Yesterday Photopost sent its customers an email advising of an exploit affecting all versions of Photopost vBGallery, that allowed a user to upload a mis-named file that could be executed by your server.

Their excuse is that it is Apache's flaw.

They have provided instructions on how to patch the latest version, but if you are running something older, the instructions are not accurate, so you have the option of paying to renew your account to be able to download the unexploitable version.

More information Here

(You cannot download the unexploitable version if your licenses have lapsed).

Indeed... i have a site running 2.2 of vB Gallery, and was fortunate enough to be able to figure out where to put the 'patch' myself.

I hope there aren't too many of their customers who are less-savvy with PHP than I am, and are either exploited, or forced to pay for a renewal they didn't really want.

a) Here is a link that deals with why it's an Apache issue. The various patches to vBGallery are to work-around it.

b) Here are the patch instructions for the work-around and here is list of 'before' chunks of code for the older versions of vBGallery & even vBadvanced Gallery. Nobody has to renew just to get the patch instructions; as far as I know everybody who has a license should be able to view the information. If somebody has a license, expired or not, and can not view the instructions then please post over in the PP forums so it can be looked into. If somebody has a license and has not logged into the forums for a very long time then they may have to update their email address to show as verified.

Thanks for the extra links Kevin, they weren't in the email, or the threads linked to from it.

Any reasoning as to why they allowed it to remain in the code for so long? mod_mime's not a new thing.

*Edit to add* As you can see from the first line of PhotoPost Community - View Single Post - vBGallery clean script Discussions , these were not provided until I requested them.

and, Zach has edited Michael's original post, so none of that information was available to anyone until this afternoon. Good to see they took my request on board.

Originally Posted by Ace Shattock

Thanks for the extra links Kevin, they weren't in the email, or the threads linked to from it.

Any reasoning as to why they allowed it to remain in the code for so long? mod_mime's not a new thing.

Looks like it was a Day 1 item going all the way back to the "vBadvanced Gallery" days. For whatever reason it is just recent that it reached critical mass.

Based upon different conversations, etc., it looks like it has caught everybody off-guard including a few other projects. One of the reasons likely why is because it is only a small list of extensions that behave unexpectedly. For example, *.php.wmv is vulnerable but *.php.txt and *.php.gif are not.

Originally Posted by Ace Shattock

and, Zach has edited Michael's original post, so none of that information was available to anyone until this afternoon. Good to see they took my request on board.

I edit everything
- ya there were a few revisions of the file thanks for the reminder. I had my head in fixing the problems and forgot on the code changes over the different revisions. Some of the links you were trying to access was still in the Mod area and not moved to live area. Blame me, they are on the east coast 3 hours +, I was still in the shower

I spent a few days on research and running test cases. I found that every system I ran into 200-250 different hosts have this lay back way of apache setup.

I spent 4 hours round and round with my web host. They are clueless why the problem happens, I was told I was put on a trouble ticket system (e-mail) as the person that just reads screens to answer questions could not help me. I need to email them the answers.

Most are limited to wmv, psd problems some servers run file.php.anything
- apache is just interpreting it as file.php.

EX:
helloworld.php = <?php Print "Hello, World!"; ?>

All the same PHP file: (my host)
http://www.szone.us/problem/helloworld.php <-- good
http://www.szone.us/problem/helloworld_php.psd <-- good
http://www.szone.us/problem/helloworld_php.wmv <-- good
http://www.szone.us/problem/helloworld.php.psd <- bad
http://www.szone.us/problem/helloworld.php.wmv <- bad

Originally Posted by viperalley

Until this moment I wasn't even aware of this post; so don't pat yourself on the back prematurely.

Maybe not, but if you figure in the fact that I am "Kall" on your forums, and made the post that prompted the additions, can I begin patting sequence now?

I think that something like this

AddHandler cgi-script .php .php3 .php4 .php5 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI

Or this in a htaccess of the upload folder

<Files ^(*.jpeg|*.jpg|*.png|*.gif)>
order deny,allow
deny from all
</Files>

Can mitigate the problem

Haha I was right finally, that smells like an SQL injection

Originally Posted by viperalley

Sure, you can stroke yourself all you want...

Awesome.

I am glad to see the lesson has been learned, and hope that next time an exploit of this level is found in your software, you will provide the relevant information of all prior versions.

When you took it over and began selling it to people, you assumed responsibility for it.