headers
Eric Anderson | 25 Jan 2012 17:33

Understanding the Security

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
suPHP@...
https://lists.marsching.com/mailman/listinfo/suphp
Permalink | Reply |
headers
Joe Gillotti | 25 Jan 2012 17:53
Favicon
Gravatar

Re: Understanding the Security

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 <eric-Es09zwCbMN9sO85lhEf0XA@public.gmane.org> 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
suPHP@...
https://lists.marsching.com/mailman/listinfo/suphp
Permalink | Reply |
headers
Joe Gillotti | 25 Jan 2012 18:10
Favicon
Gravatar

Re: Understanding the Security

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 <eric@...> 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
> suPHP@...
> https://lists.marsching.com/mailman/listinfo/suphp
Permalink | Reply |

Gmane