Hello everyone :) Especially WHM/Cpanel users :D

If you provide shell access, how do you protect users viewing others files, especially php code having database passwords?? :eek:

And what about your custom php code in cpanel themes?

Everything is readable :bawling:

And this happens on almost all *nix platforms :D

If your that worried about a user looking around and finding stuff, why give them shell???

I haven't found a user who will tell me upfront "please give me shell access as I need to look inside other directories" :rolleyes:

Hmm...

Considering this is something on all *nix servers...

You can do two things... Make a chroot, which can be a bitch... Or you can put up with it :D


You could also setup permissions for files, but you'd have to constantly reset those because users will always mess those up with chmod :D

The best solution I have found so far is cgiwrap and php-cgiwrap.

cgiwrap works great, but php-cgiwrap does not want to get installed :bawling:

I don't know anyone here with any luck??

And about cpanel themes directory, that's another problem.

You would need to:

Chroot a user at shell...
Run Apache 2, to make sure PHP scripts ran as the user who owns them...
Compile PHP with safemode and openbase-dir...

And several other things...

[removed by PHPGuardian]

(couldn't delete it)

PHPGuardian. What you just did is against the rules of this board. It is advertising in a none advertising forum.

Apologies, thought it was a relevant resource; post respectfully removed. Moderator please delete original remaining message.

Thanks

Chris

PHPGuardian,

http://www.vbulletin.com/forum/showthread.php?s=&threadid=48539

If it really is that easy to crack then you guys have some work ahead of you :D

I need to reply to this, sorry if it's out of bounds again :)

Yep, we've seen that thread and had a good chuckle about it. Two minutes is really very impressive indeed and, if it's true, the guy / gal who did it should be congratulated for their skill without doubt. We're actually quite open about what it takes to crack it - because everything out there can, and will, be cracked eventually. If you have the resources to rewrite some PHP core and recompile it, you can get at the source. If you've been clever enough to really obfuscate it properly, chances are the source isn't much use anyway :)

All anyone involved in creating alternatives to Zend Encoder can do is to keep pushing the technology further. We have chosen a system that requires no alterations to the server / PHP installation as opposed to some other developers. Each format has pros and cons involved.

We take the analogy of adding security to your house - every window lock, burglar alarm, CCTV camera etc is just another layer of protection that someone must take positive steps to break through - so it is with any code protection. At the end of the day, the obfuscated (not encrypted) code is so difficult to understand that it's not worth the time, other than for a mental exercise, to go through it :)

It's not our style to knock competition or post outrageous claims, there are talented developers everywhere working on solutions. We are interested in getting a product to market that people need, can use and feel good about their distributed intellectual property with.

That's all :)

Chris

I agree, obfuscated code should be good enough :) if anybody can take the pain to reverse engineer it, then probably he/she can write it as well.

So why wasting time reading "oiuoeoiue" ;)

I acutally do like the feautres of PHP Guardian, the IP limiting and time limiting feature is great..

I've almost thought of buying a license, just don't know how much I'd use it to justify it :D

This was masood's thread on protecting php on cpanel so I'm going to bow out now, but I just wanted to say thanks to Prohacker for this (and other!) posts and massood for what looks like a Guardian'ed variable...

:D

Echoing Chris's sentiments, it's not my style to knock anything that furthers PHP and security either, and I spend much of my own time furthering it with free projects like the PHP Accelerator, and applaud efforts in this arena, but I'm also passionate about giving users the best deal, and making sure that users are aware of the facts regarding such security issues because I think that's important too. Phrases such as 'Ultimate code protection' might be misleading, or actually inaccurate.

I'm not sure personally that I would feel that good about releasing my intellectual property where I knew that it was going to be restored back to source on a users machine, but I may just be thinking from the perspective of knowing how to do it. I'm ultimately pro choice for the user, and any tool that offers that, whether good or weak, is at least widening the arena.

But let me explain about the two minutes. There's nothing earth shattering in this, except perhaps how easy it actually is.

The first thing is to realise that source code encoding products do precisely that, they encode source. It is a falacy to think that any encryption is protecting you here. Any hacker or code thief will just attack the weakest link, and that is the PHP compiler itself. In order to execute your scripts, the very tool that is supposedly protecting your code will actually restore the source. In the case of some decoders, they then effectively call eval() on the code. Another problem with this btw., is that calling eval() doesn't give you 100% the same behaviour or output as unencoded scripts, but that's another issue.

Obfuscating code first may seem to help, although all the obfuscators I've seen do quite a poor job and are missing some tricks, but obviously they could be improved. For a hacker, obfuscation IMHO isn't really going to be that much of a deterrent. Another thing is that passwords aren't obfuscated, and that just getting obfuscated source out may be sufficient for the hacker anyway. Reading it may not matter.

So anyway, as encoded scripts will get turned back to source and compiled, you just need to display the source at that point. Remember that the PHP engine is OpenSource - you have the source code to the PHP engine, and you can just put a breakpoint or add a printf at the relevant point to see the code as it's run to the compiler. For one approach if you head for Zend/zend_execute.c and the point that compiles source then you won't be far off. It's as simple as that. I won't give more details, although haven't given anything away here that isn't widely known about, and clearly anyone who can read C will be able to get at the source code. Producing quite a decent source restoring tool from encoded files is really just about a days work, including time to write documentation :)

For my two minutes I merely fired up gdb on httpd, ran it with -X, (using php-cli would have done just as well), set a breakpoint or watchpoint in zend_execute, and sat back. I was then emailing back the contents of the script that a friend had emailed me, and yes, that's two minutes or less of effort. A fuller solution would be to open a file, and add a line to do a fprintf to a file. Whilst this means that someone has to edit the engine, recompile etc., or know about gdb etc., a great many people can do that. It really isn't rocket science!

I agree with the securing a house analogy, and it is fair to say that such encoding is better than doing nothing because you have to do a bit of work to see the source. It's also known that companies sell empty alarm boxes with no alarm inside to give the appearance of protection! If someone wants to get in then they will, and if protecting code and possibly passwords is really important, then you need to look to compiled code encoding such as from Zend Encoder or the spinoff from PHPA, as those projects are really operating at a different level of security and sophistication altogether. But, they can be hacked to some extent as well as we're all agreed that there's no 100% secure tool.

That's all :)

ok.. say that i use `PHPGuardian` or `Zend Encoder` and i have a encoded php script "config.php"

<?
$user = "sosecret";
$pass = "verysecret";
$db = "something";
?>

any one can view the encoded script using some thing like this:

hack.php
<?
include "config.php";
echo "the username is $user and da pass is $pass for the db $db";
?>

is this correct?

Yes, but if your encoding it, you'd want to use harder to guess varible names...

Or encode the entire script and not show any varibles :D

Prohacker is exactly right. Figure it this way:

I use include("config.php"); on a NON-encoded script. The variable names are weird, so I'm screwed right? WRONG:

$file = join ('', file ('config.php'))
echo $file;

Now I have all the variable names, since using the above code will NOT parse php, it'll display plain text :rolleyes:.
At least with encoding, it will only display a garbled mess so at least a "curious user" would probably quit at that point, but yes, an actual hacker would have no difficulty decoding the page.

Proper permissions help.

safe_mode will keep one php script from reading the data in someone elses files.

But, the only thing with shell access, is to chroot.

Originally posted by JTY
safe_mode will keep one php script from reading the data in someone elses files.


And you can use Perl script to read it :)

Originally posted by masood


And you can use Perl script to read it :)

suExec...

Bad thing is, for ever way we close something up, there is usually another one right there to take its place that is just as bad or worse....

That's just how shared servers work, which took some time explaining to a client that was hosting unencrypted cc numbers in a flatfile :rolleyes:. Now THAT was an accident waiting to happen...

suExec... can't that work for php too? :D

Yes but shell commands are disabled in php when it's running in safe-mode :).

http://luxik.cdi.cz/~devik/apache/

Interesting script, and a little more secure then safe-mode (supposedly, though I've never tried it) althought it slows things down a bit.

Originally posted by The Prohacker
You would need to:

Chroot a user at shell...
Run Apache 2, to make sure PHP scripts ran as the user who owns them...
Compile PHP with safemode and openbase-dir...

And several other things...

Apache 2.0's perchild MPM (which does run each site under its own child processes) is not yet working as of 2.0.39. This means we still need to use the old 1.x way for per-site isolation (which is wrapping and/or boxing).

If you're using apache 1.x, i recommend mod_cgiwrap (http://steven.haryan.to/mod_cgiwrap/mod_cgiwrap.html). Otherwise, use suexec.

Be careful if you are using cgiwrap since a misconfiguration will cause users to be able to run scripts unwrapped.

Originally posted by The Prohacker
And this happens on almost all *nix platforms :D

If your that worried about a user looking around and finding stuff, why give them shell???

We *can* make things more secure under Unix, by carefully setting filesystem permissions. Two things basically:

1) don't let other users peek into a user's home and his document root; the only unix user needing this access is himself and the webserver user.

2) run all web scripts wrapped so the scripts cannot pose as the webserver user to peek into sites' document roots.

Unfortunately, the situation is pretty hopeless with Cpanel3/4. (And even RaQ 3/4 and Plesk2).

Originally posted by stbauer


1) don't let other users peek into a user's home and his document root; the only unix user needing this access is himself and the webserver user.

(And even RaQ 3/4 and Plesk2).

the proplem is in the webserver user any user can be the webserver user using a php or perl script..

so this wont work

If you want to use suExec with php, you need to use the cgi version of php.

Rename your .php file to a .cgi file
and put #!/usr/bin/php at the top of it and you should be all set.