Mapme 1.3 Exploit Code Fix

Hello,

I've received a response from the developer of mapme 1.3 in regards to the recently identified exploit.

in mapmejs.php

Change:



to



You can add this change immediately.

Please let me know if any comments.

Regards,
Ajay Bhargav


Hope this is of some use to folk, maybe worth including in the Bad Plugin List plugin as a note..

Cheers

Pete

Why not simply make the fix and upload it to plugins.e107 with a new version number?

That way everyone can grab a copy without having to edit files which most aren't confident of doing.

EDIT: I made the changes and made it available here: [-link-]

It's not tested though..........................

I've asked him to do that as the insecure version would have been removed.

This is intended for people who are confident, and wish to simply fix the version they have running at the moment.

Good stuff - It would be good if others could contact plugin developers to get the security holes closed, it's a shame to see good plugins being abandoned, when it can literally be a simple task of informing the developer of the exploit used so it can be closed.

Pete

Pete I have admin rights at plugins.e107 and pm's were sent to most (not all) plugin makers when they were withdrawn and few responded with fixes I'm afraid.

First I replaced the old version folder with the new version, and the map doesn't load anymore, so then I decided to apply this fix manually to mapmejs.php, but I have the same problem, the map doesn't load up on users profiles with this change in place.

e107 Version 0.7.22

Guk, please update to the most recent version being 0.7.25. Using older versions makes your website vulnerable to exploits and other security issues.

1.4 still doesn't work for me. I see the map when you click on the map page, but it doesnt even show in the profiles page.

Is the developer aware that 1.4 is not working for people, will there be a fix or should I uninstall it all together?

The developer didn't issue 1.4. 1.4 fixes an explot that exists in 1.3. Nothing was changed between 1.3 and 1.4 that would have broken it.

In fact, the only thing that was changed is what you see in the first post of this thread.

I can report that changing:



to:



Does break mapme on my website in the user profile page.

Without the change, the map is displayed on each users profile, and with that change in place, the area where the map should be is blank. swata4 confirmed the same thing in this thread.

Revert those changes.

Change the following line:



To:



See if that works.


OR

You can revert those changes mention in the OP and change:



To:



This is probably easier.

Thank you, I tried both of those methods and they both work. The map is back in the user profile page.

Thanks. My maps disappeared from the profile page, and stopped showing the users on the main map too.

This fix put the map back in the profiles page, but the main map for the site doesnt show any people on it, even though I have my target set.

I see you have an OR between these two methods.

Is there any reason not to do both?

I did and things seems to be working fine.

@WayneM;

Cause when you do both you'll 'over do' it. I'll try to explain it as clear as I can.

Start by looking at the second method.

$uid = $_GET['u']; to $uid = intval($_GET['u']); activates an inbuilt protection from e107 It makes sure the input (the GET variable) is not malicious and it prepares it for safe usage.
It takes the GET variable, it checks its validity, and it stores the safe value in the $uid variable. Once done, the $uid variable is considered as safe.


Now look at the first method.
Instead of making sure the $uid variable is safe before even starting to build up a query (= request to mysql - the database where everything is stored), it does so in the query itself.
You see: "gmarkers.user_id = ".$uid." and " is changed in "gmarkers.user_id = ".intval($uid)." and"

If you'd apply both methods at the same time; you'd get something like this:
gmarkers.user_id = ".intval(intval($_GET['u']); )."

Its double

Hope that clears it up, just ask if you want more info

Thanks for that!
Makes sense.

Is one of these methods preferred, or more elegant?

Thanks.

I would prefer the second method as you can then use the variable safely elsewhere in the code without creating vulnerabilities if you happen to forget to add the security using method one.

You're welcome

As Moc said, they both do the same thing. The second method just, as Moc said, allows you to safely use $uid in other queries.

I added it at the last minute because it will be easier for people who don't understand coding that well to implement without causing errors by missing something.

Thanks!