PhpGedView / Discussion / Help: 4.2.3 Local File Inclusion Vulnerability

antiqueone - 2011-01-05

My hosting provider has closed down my sites due to processes running on the server. I have done a search and found a report at http://www.exploit-db.com/exploits/15913/ on a security problem reported today. Is there anyone around who can fix this problem?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

KosherJava - 2011-01-06

Until a fix is available you can probably just remove the module.php file from the root of your PGV install. You should not need it unless trying to manage your modules. Removal seems to have caused no issue (that I noticed) in my install short of not allowing me to manage my Google Maps module. More about the vulnerability at https://secunia.com/advisories/42786 .

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ggpauly - 2011-01-06

I couldn't get this exploit to run successfully on my test server. I didn't want to upset an ISP, so I didn't try it on a production server.

Reportedly, php.ini setting magic_quotes_gpc = On is protective, however I could not get the exploit to run successfully regardless of this setting. magic_quotes_gpc is deprecated and discouraged as of php 5.3

inserting the following after line 63 in module.php might help:

if (false!==strpos($_REQUEST,'..'))

{

$_REQUEST = 'index';

}

However as I said I could not test this. Perhaps the standard Apache2 security is preventing a successful exploit.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Greg Roach - 2011-01-06

<<I couldn't get this exploit to run successfully on my test server.>>

I could. You don't need a fancy perl script. You can do this by typing a URL into your browser.

@antiqueone. If you have access to your webserver logs, it would be interesting to confirm whether this particular exploit was used on your site (the timing could be coincidental), and to know when the attack happened. e.g. before or after this exploit was published. However, I'm sure you have your own priorities at the moment…. :-(

As ggpauly says, the module.php script needs to validate/sanitise the pgvaction parameter before using it.

The "magic quotes" setting works by replacing the embedded null with the escape sequence \0.

You should check your phpinfo page. If "magic_quotes_gpc" is "On", you should be OK. If it is not, then you should take some action REAL SOON. kosherjava's advice is good - delete this file until a patch is available.

Note that "magic_quotes_gpc" is a deprecated feature, and causes its own problems. You shouldn't rely on "magic" for your web security :-)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Pollard - 2011-01-06

Just a comment, I have had multiple attempts, that appear to be unsuccessful, using this exploit over the last day over the half a dozen or so pgv sites that I operate. I suspect many more in the future. I will probably add a clause to .htaccess for insurance.

Tony

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ggpauly - 2011-01-06

I have checked my logs, and there have been 100s of attacks beginning Wednesday morning. In my case all were unsuccessful because of webserver security.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

antiqueone - 2011-01-07

Thank you to everyone who has replied to this. i think I will take things slowly and recover my sites without phpgedview for now.
Tony, what clause can you add to .htaccess to provide insurance?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Pollard - 2011-01-07

I must admit that I don't claim to be an htaccess expert, and others may improve or correct this but I have tried a variant of;

RewriteEngine On
RewriteCond %{THE_REQUEST} ^/module\.php.*$
RewriteRule ^.* -

This is supposed to send anyone who attempts to access the /module.php file down a black hole.

Tony

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2011-01-07

I posted a patch for this new hacking attempt to the Patch section this morning (2011.01.07 @ 11:40 GMT).

There's a different patch file for SVN older than 7006 and for the 4.2.3 version of PGV. Patch files for older versions of PGV can be created if there's a demand - just ask here or send me an e-mail.

SVN 7006 includes this patch.

As was noted above, you can avoid the problem by removing modules.php from your installation. A better option would be to change its permission from 755 or 644 to 700. That way, if you need to run this script, you can simply change its permissions temporarily.

Note: Available documentation claims that all scripts should be set to permission 644. This is wrong for some servers which require 755 to permit script execution.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

KosherJava - 2011-01-07

Thanks for the patch.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2011-01-07

This is the URL to the relevant patch:
https://sourceforge.net/tracker/?func=detail&aid=3152857&group_id=55456&atid=477081

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

antiqueone - 2011-01-07

Thank you so very much for producing a patch so quickly and thanks to everyone else for their inputs.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

KosherJava - 2011-01-07

Is it time to release a new version of PGV?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2011-01-07

kosherjava:
Yes, we should probably release a new version within the next few weeks. We're not quite ready - there are a few things that still require attention, and I want to include the ancestry report. This report is pretty good, but it needs a little work.

I'm not sure whether the new version should be 4.2.4 or 4.3.0. I'm leaning towards calling it 4.2.4, since there aren't any major new features in it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stephen Arnold - 2011-01-07

Gerry
I lean to 4.2.4, BUT, if all the work is there for the exploits and you finish the report repoiishing, it may be better (and still a very small increment IMHO) to move it to 4.3 and rid ourselves of the 4.2x nomenclature.
-Stephen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2011-01-08

To tighten security even more, the patch files have been updated again.

The changes are based on some recommendations made by Greg (Thanks, greg!)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ilox - 2011-01-08

Now that we have the patch (many thanks for the fast work) is it safe to replace the modules.php file that we have removed?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2011-01-08

Yes, definitely.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2011-01-08

The latest set of patch files includes a replacement "modules.php" file. Make sure you don't accidentally replace this new one with your old one.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ilox - 2011-01-08

Thanks mate, will make sure to update all my installs to the latest corrections.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

John Finlay - 2011-01-13

This is a pretty major security hole. If you are interested in seeing just how it works you can find a detailed tutorial here:
http://forum.intern0t.net/general-hacking-discussions/1258-shell-via-local-file-inclusion-proc-self-environ-method-step-step.html

How about we put together a quick 4.2.4 release with just the security patches until the main trunk is ready? I could probably do this later today or tomorrow.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stephen Arnold - 2011-01-13

John
See my comments on the developers forum.
Stephen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

King Rat - 2011-01-13

Yes. You really do need to put out a new version with the security hole fixed. The patch is not enough.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2011-01-13

I posted my views in the Developer forum. Dont delay releasing version 4.2.4; the stuff I'm working on is not a good enough reason to delay.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

macalter - 2011-01-13

May I clarify please: My Admin page says "PhpGedView 4.3.0 svn". So, does that mean an update will then say 4.2.4?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

4.2.3 Local File Inclusion Vulnerability

Forums

Help

4.2.3 Local File Inclusion Vulnerability document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

4.2.3 Local File Inclusion Vulnerability