Eric,
To further elaborate on the scenarios that you provided, if you want to
ensure the PHP files themselves can not be altered by malicious code,
you can make them immutable so they cannot be changed at all.
With Linux, as root, you can do:
chattr +ia *php
This makes it impossible for the script itself (or essentially any user
on the system, including root) to edit/remove the files at all. You can
make them normal again with (as root) chattr -ia
This may seem a little extreme which is why you really should just
ensure you're not running horrible code and have an automatic backup
system in place, in case something bad actually happens. (I personally
use a combination of rsync and tar under cron to keep the stuff I care
about safe in an off-site location)
Warm regards
On 01/25/2012 11:53 AM, Joe Gillotti wrote:
Suphp doesn't prevent bad coding practices; it merely provides privilege
separation, which can significantly limit the amount of damage such
practices can cause.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Eric Anderson <[email protected]> wrote:
I understand how suPHP allows each site on a shared host to be
isolated since the scripts are being run as the website owner. So a
security flaw in one site cannot affect another site. I am wondering
if there is a way to allow suPHP to protect a script from itself.
Let me give you two examples:
Scenario 1
---------------
Script upload.php is designed to allow a end user to upload files to
a directory so that file can then be served by the web server. The
intent might be to allow image uploads. But upload.php is careless
and doesn't check to ensure that the uploaded file is actually an
image. A hacker uploads a file called destroy.php. This is placed in
the upload directory which is publicly accessible. So the hacker
makes a request to destroy.php which is designed to remove any files
it has permission to remove. Since it is owned by the website owner
it will be run as the website owner. This means it can delete the
entire website.
Is there any way to prevent the above from happening? Is there
something in suPHP that helps with this? The only thing I can think
of it to disable the suPHP handler on the upload directory.
Scenario 2
---------------
In this situation there is no upload. We have a php script called
careless.php. It makes the mistake of evaling data that came from
the web request (i.e. eval($_GET['code'])). A hacker realizes this
and makes a request that sets $_GET['code'] to something evil (maybe
deletes all files in the website). Is there anything in suPHP to
prevent this?
Obviously my scenarios are highly contrived. But I think they are
simplifications of real world problems. An exploit in some 3rd party
software (Wordpress, etc) may allow a hacker to carry out attacks
like this on the website running the software.
When running php as an apache module these exploits allowed hacks to
take advantage of too permissive upload directories and even invade
other sites on the same server (which also had to permissive upload
directories). But the website itself was not at much risk since it
was owned by a different user than the user php was executing as
(assuming the website files were not group/world writable).
Under suPHP each site is isolated (good!) but it seems that an
exploit allows the hacker more potential for problems within that
isolated site than before.
Am I understanding things correctly? Is there something I am
missing? Any insights would be greatly appreciated.
Eric
--
http://saveyourcall.com - Easily record phone calls from any phone
http://pixelwareinc.com - Atlanta-based web development and design
_______________________________________________
suPHP mailing list
[email protected]
https://lists.marsching.com/mailman/listinfo/suphp
_______________________________________________
suPHP mailing list
[email protected]
https://lists.marsching.com/mailman/listinfo/suphp
