Serious PHP vulnerability; please check your sites!

[ILoveHostasaurus]

Re: Serious PHP vulnerability; please check your sites!

After implementing the code in the .htaccess file, is there any way to test to make sure that we have implemented it correctly and are no longer vulnerable?

thanks in advance.

Yep, without the code, and you won't believe how ridiculous this is, you should be able to go to any php script on your site and make a request that is just for the php file followed by ?-s and see the entire source of the file. So, http://www.domain.com/whatever.php?-s With the rewrites in place, you should get a "forbidden" instead.

Not quite sure how no one noticed that issue for eight years but that's what happened; supposedly a fixed release of php 5.3 and 5.4 will be out tomorrow but those running older versions, often intentionally, will need the rewrites permanently.

[wcw]

Re: Serious PHP vulnerability; please check your sites!

What will the source get them if there are no passwords in it? Not all php scripts are accessing databases. So if they are not, is there a danger?

There is a message center in admin.mvc. Wouldn't something like this be a worthwhile message? Or perhaps a mass email about the issue?

[Brandon MUS]

Re: Serious PHP vulnerability; please check your sites!

The source code CAN make it easier to find security vulnerabilities, but doesn't necessarily constitute an alarm (other than maybe stealing someone's intellectual property). Some of the other things you can do with the query string can be used for DoS attacks.

[ILoveHostasaurus]

Re: Serious PHP vulnerability; please check your sites!

What will the source get them if there are no passwords in it? Not all php scripts are accessing databases. So if they are not, is there a danger?

There is a message center in admin.mvc. Wouldn't something like this be a worthwhile message? Or perhaps a mass email about the issue?

That is not the extent of the vulnerability, he was asking for a method of testing for its presence and the source test is the easiest one since it's just a request with ?-s added on the end.

I will speak to Rick about putting something in the admin; keep in mind that very few users overall will be running php as a cgi.

[Siamese-Dream.Com]

Re: Serious PHP vulnerability; please check your sites!

David:

I just sent you a PM about this because I think there might need to be a slightly more comprehensive action required by us site owners. Don't want to mention it in the public thread (especially since I could be dead wrong about it, too).

[wcw]

Re: Serious PHP vulnerability; please check your sites!

A lot of stores implemented a Facebook interface which involved a php file to test a user's credentials inside the Facebook iframe. Depending on the user "like" status, it would bring up the applicable version of your store. That php file on the store owner's server would be vulnerable to the attack. They would not have passwords in that file as it is just running merchant.mvc as a regular store display. But is there something more insidious they could do, e.g. write html pages to your domain by adding complete php code in the query_string?

[ILoveHostasaurus]

Re: Serious PHP vulnerability; please check your sites!

David:

I just sent you a PM about this because I think there might need to be a slightly more comprehensive action required by us site owners. Don't want to mention it in the public thread (especially since I could be dead wrong about it, too).

So Mark discovered that the rewrite lines may not be effective in a site's root .htaccess file if there is a wordpress install in a subdirectory that has its own new .htaccess file with new rewrites that wordpress uses for permalinks. If you do have a wordpress install, you should add the same rewrites to both your main .htaccess and your wordpress sub-directory .htaccess file or you may not be protected.

Additionally, something I discovered through two other customers; apparently the latest release of wordpress, as of a day or so ago, attempts to change its own .htaccess to block this attack but the attempt is not correct. The wordpress addition to the .htaccess file is:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]

which does not properly stop all methods of the attack. Their code should be replaced with what I posted from the php site:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

[Brandon MUS]

Re: Serious PHP vulnerability; please check your sites!

That php file on the store owner's server would be vulnerable to the attack. They would not have passwords in that file as it is just running merchant.mvc as a regular store display. But is there something more insidious they could do, e.g. write html pages to your domain by adding complete php code in the query_string?

Yes. The ?-s version of the attack is just one variety. There is also one version that allows the injection of additional php code, opening the doors for just about anything.

[grafcomm]

Re: Serious PHP vulnerability; please check your sites!

could this be related to all the spam baskets I have been receiving since mid-may?
I have xijsb.php file in the cgi bin, so I added the rewrite code to the .htaccess file

[Brandon MUS]

Re: Serious PHP vulnerability; please check your sites!

Anything is possible, but it doesn't necessarily mean it is directly related. You should have your host verify that you are patched if you don't know for sure.

[grafcomm]

Re: Serious PHP vulnerability; please check your sites!

I have been contacting miva/hostasaurus for a month trying to get this resolved... the problem is getting worse

[ILoveHostasaurus]

Re: Serious PHP vulnerability; please check your sites!

could this be related to all the spam baskets I have been receiving since mid-may?
I have xijsb.php file in the cgi bin, so I added the rewrite code to the .htaccess file

Miva Merchant doesn't use php so nothing related to php would have anything to do with basket creation on any site running Miva Merchant.

[kitdang]

Re: Serious PHP vulnerability; please check your sites!

A lot of stores implemented a Facebook interface which involved a php file to test a user's credentials inside the Facebook iframe. Depending on the user "like" status, it would bring up the applicable version of your store. That php file on the store owner's server would be vulnerable to the attack. They would not have passwords in that file as it is just running merchant.mvc as a regular store display. But is there something more insidious they could do, e.g. write html pages to your domain by adding complete php code in the query_string?

Bill/David,

I am one of many that have implemented the facebook inframe above. Should I use the temp fix or is the perm fix in place? Sorry late to the game

[ILoveHostasaurus]

Re: Serious PHP vulnerability; please check your sites!

Bill/David,

I am one of many that have implemented the facebook inframe above. Should I use the temp fix or is the perm fix in place? Sorry late to the game

We pushed the rewrite block out to all sites running php as a cgi back in May so you don't need to edit anything. If your php version is below 5.3.13 though, ideally open a support ticket and have us update it to 5.3.14.