ReviewPost Security

WB · June 30th, 2005, 02:26 PM

Since ReviewPost shares much of its code with Photopost and in light of the recent security update to PhotoPost, is there an ETA for when ReviewPost will be made secure as well (assuming that it needs the updates and based on the PhotoPost announcment it sounds as if the ReviewPost code needs it quickly since there was no 5.11 equivalent that might have mitigated some of the issues)?

Thanks.

Michael P · June 30th, 2005, 02:53 PM

PhotoPost Classifieds will be out tomorrow and I expect ReviewPost to get the same code changes for a release in the next week or two. With Chuck taking a bahamma beach vacation, I'm working through the code as quickly as possible and posting updates as I have them versus holding them all for one upload.

WB · June 30th, 2005, 02:57 PM

Great, thanks for the response.

Arnie · July 12th, 2005, 09:36 AM

Any update on this yet? It'd be nice to be able to secure ReviewPost properly so some of us can actually use the software. I have it disabled until the fix is posted as basically the software is unsecure until then.

If you code post privately the issue with the code perhaps we could fix the problem ourselves temporarily?

Arnie · July 17th, 2005, 01:12 PM

I'd like to warn folks that several of the vulnerabilities in PhotoPost listed here are as far as I can see left wide open in ReviewPost and leave your product unsecure and open to having the SQL database probed:

http://secunia.com/advisories/14742/

Proof of concept:

/REVIEWPOST-HOME/showproduct.php?product=4&sort='test

This results in this error:

Code:

Content visible to verified customers only.

The $password and $sort variables in showproduct.php are not sanitized, and the relevant bugs here also seem to work:

http://lists.seifried.org/pipermail/...ch/007572.html

Just substitute showgallery for showproduct to test on your version.

This bug report was made in March and has not yet been crosschecked against ReviewPost.

I'm posting this in the members area only for obvious reasons.

As a fix for the $sort bug, replace line 106 (if ( empty($sort) ) $sort = 1; ) in showproduct with this:

Code:

Content visible to verified customers only.

If I discover fixes to the other bugs I'll post them.

Arnie · July 17th, 2005, 05:07 PM

After a futher check through the code for RP it would seem to be a good idea if someone went through the publically accessible pages with a fine tooth comb and ensured that all variables were correclty sanitized before usage. There look to be a look of possible problem areas.

sbb · July 17th, 2005, 05:18 PM

is this to assume then that review post software has not been updated to resolve this? I need to install it but not at the risk of propping as we are already running high MySQL queries with our site traffic alone without adding to it with security issues.

Arnie · July 17th, 2005, 05:28 PM

No, if you run the test I set out above with a simple query you'll see that it runs the SQL is added to the query and reported in the error message.

All that is needed is a crafted "union select" command and someone could output passwords or whatever they wanted out of your database.

In different news there's two more security updates that I'd recommend. Both of them involve htaccess. If you can create an htaccess file in the root of your RP install with this line in it:

Code:

Content visible to verified customers only.

Then in the /RP/data directory I'd add an .htacces file with this in it:

Code:

Content visible to verified customers only.

Basically the first file ensures that magic quotes are on, the second ensures that even if someone gets around the upload routines even if they upload a php or cgi file they can't run it, and the php file will just outputplain text.

Some ISPs and hosts won't allow you to do this in htaccess, but like I said if you can (if you can't you'll get a standard http error 500) you should do it.

Looking at things now it looks like a fair few bugs that affect PhotoPost might not have been checked out on ReviewPost.

Someone on the RP support crew will hopefully address this issue sometime shortly, but it's now been past two weeks since they were notified of the problems and nothing has happened yet.

Arnie · July 17th, 2005, 05:45 PM

Before I hit the sack for the night here's another issue I dislike. Showing the exact version number for RP publically is a bad idea. If you forget to update someone can do a quick Google search to find a vulnerable install.

Lines 153/154 of pp-inc.php can be changed from:

Code:

Content visible to verified customers only.

to this:

Code:

Content visible to verified customers only.

Now you just have the major version number listed rather than the revision.

This specific topic is jsut my personal opinion, but unless code is security bullet proof (and IMHO RP isn't) you should never publicise the exact version number.

As a further small aside for someone on the coding side to look into, in member.php after "// Process a user's edit, forward to profile display" several of the variables mentioned are not sanitized and could well be exploited.

Code:

Content visible to verified customers only.

is then used here:

Code:

Content visible to verified customers only.

I'm not certain but that coudl well be used to get around home systems.

Arnie · July 19th, 2005, 09:32 AM

Omegatron/support is there any chance of a reply to all the issues raised here?

Chuck S · July 19th, 2005, 09:36 AM

All I can say is Reviewpost is next up for a code overhaul

Arnie · July 19th, 2005, 09:49 AM

Any chance on an ETA? I mean.. there's some serious security issues left open at the moment in all versions up to and including the current release of RP.

I've posted what I can as fixes for those that need them some help with it would be appreciated, after all I'm a customer.. not a support engineer.

Chuck S · July 19th, 2005, 10:02 AM

Well the bug reports you meantion where on Photopost and were addressed and security versions released

You meantion in a post we where notified two weeks ago yet your post is 2 days ago so I don't quite follow you.

1. Version number displaying is not a bug.

2. No ETA as we just released classifieds 2 weeks ago. More than likely this will take some time as well.

Arnie · July 19th, 2005, 10:21 AM

You're not really reading what I'm posting are you? Please read all that's posted on here then reply.

The bugs listed for PhotoPost were addressed in PhotoPost I gather, however this is a ReviewPost forum ergo what I posted is a problem with ReviewPost.

Some of the security issues for PhotoPost are equally applicable to ReviewPost. Take for example the SQL injection one I highlighted right above with proof of concept. At least one bug highlighted in "showgallery.php" (posted on Secunia on 2005-03-29) is directly applicable to "showproduct.php" in ReviewPost because it's basically the SAME CODE and it still remains open and unfixed.

The version number issue I mentioned is also just listed as an advisory.. nothing more. I even said that in my post. It's just a personal thing. Publicising your exact version number is a bad idea and one that phpBB adopted for the same obvious reasons.

MichaelP posted on July 30th:

Quote:

PhotoPost Classifieds will be out tomorrow and I expect ReviewPost to get the same code changes for a release in the next week or two.

The question asked by the first poster was... with the publicised flaws in PhotoPost that have been addressed, when will we see a fix for ReviewPost as it shares the same code?

Ergo.. I've posted bugs, pointed out possible security flaws, and posted fixes where I can (with proof of concept if applicable) in ReviewPost that are all applicable to this topic because for at least one of them you've known about it for at least 2 months and failed to help.

IMHO individual security flaws need to be addressed ASAP when you're notified (preferably within a certain number of days). Glorified "code overhauls" can wait.

Chuck S · July 19th, 2005, 12:53 PM

All I am saying is any security warnings issued by security companies on Reviewpost where addressed many months ago. There has been no new Reviewpost warnings now thats not saying there is issues.

Now Michael P will have to respond with a timeline as my answer is as I already said it is being addressed. Only Michael can give an ETA.

WB · July 19th, 2005, 02:50 PM

An ETA would be much appreciated from Michael. Based on the response to my original post, we had expected the update to be out by now.

Chuck S · July 19th, 2005, 10:38 PM

Well as you know ETA'S are just that.

I have actually begun working with this and I can say minimum two weeks and I would expect this to be a BETA since we will be using the new typecast function

You can see the progress here where I have done most of the front end already and zipcode added

http://omegatron.net/rp/index.php

Arnie · July 20th, 2005, 04:57 AM

Excuse me while collect my jaw off the floor...

...you're not going to release security patches in the interim to the issues raised that place an immediate threat to all version of ReviewPost because you want to release your new version of the codebase? So instead you're going to expedite the new release you are working on and chuck it out in BETA form in a few weeks?

So those of us wanting to use ReviewPost in a production environment go from having a hugely unsecure version of your software to one that's BETA status and presumably flawed in ways we don't know yet.

At a guess it'd take you guys about an hour of your time to go through your code and fix the immediate holes (such as any XSS/SQL injections that are apparent), then just post a revision to the code publically.

Sorry for being so candid but your response just begs my sheer disbelief. I can only assume that there's something I don't know about in your development methodology or something but on the face of it as a member on a product support forum I've never heard a response like it. Are there so many security problems that a security maintenance release is too much work and time better spent on the newer code revision?

Edit: Today I've just added a heap more issues that look to me to have been unchecked. Again they were all reported under PhotoPost and do not look to have been checked/fixed against ReviewPost to which they also apply. Without a copy of the PhotoPost code it's hard to directly compare the fixes that may have been applied to the other code set so some reports may not apply, however I've checked the reports against ReviewPost to the best of my ability and reported on those that look to do look to be at risk.

Developers may wish to consult the following resources to cross check each reported PP bug against RP:
http://cve.mitre.org/
http://secunia.com/

Chuck S · July 20th, 2005, 08:41 AM

Arnie

Coding reviewpost to use the new typecast is plugging the holes. The new typecast function is the sanitizer and must be ran through every file. This does not take an hour to go through and do. It is not something we can just plug up here and say do this do that.

Remember the security bugs you are reporting are from Photopost which where fixed in Photopost. There are no current open security reports to our knowledge on any of our products that have not been attended to my us. Now your trying vulnerabilities reported in a photopost report in reviewpost and thats admirable.

Security Releases can take weeks to do and this will be a huge security release when it comes out. Whether we decide to call it beta or final is not relative. Probally wrong choice of words but the point being is we released Photopost and Classifieds without any period like a beta where users find bugs and we where hit with a slew of bugs.

Arnie · July 20th, 2005, 08:53 AM

Ah thanks for the explanation, I'm not familiar with the PhotoPost improvements as I'm not privy to the code so can only surmise what the fixes to the previously posted bugs were. I look forward to the new release.

If/when I come across issues I'll post what I can here, as I'm doing to best to get the current codebase patched to a point that I'm happy to place it oline publically in the interim. As things are my install of RP remains offline.