security of phpsuexec

[yawnmoth]

A particular web hosting company decided to install phpsuexec on all
their webservers, citing security considerations. My question is...
is it really more secure?

Without phpsuexec, if a PHP script is to create new files, public
write permission needs to be enabled on the particular directory since
PHP is ran as user 'nobody'.

With phpsuexec, however, that's not needed. phpsuexec runs as the
root user.

The problem is... what happens if there's a vulnerability in a PHP
script? What happens if someone has a PHP script like this?:

<?php
eval($_GET['cmd']);
?>

Without phpsuexec, the only thing an attacker could do is to
manipulate files that *do* have public write permission. With
phpsuexec, however, an attacker can do whatever he wants to to pretty
much any file.

Basically, phpsuexec seems to me to only be a good approach to
security if you assume that PHP applications simply do not contain
vulnerabilities. Which is a dumb assumption. That's like believing
that just because you're running Windows XP SP3 with every update
installed that you don't need a Firewall.

Maybe I'm missing something? Or is phpsuexec just, flat out, a bad
idea?

[Jerry Stuckle]

yawnmoth wrote:

A particular web hosting company decided to install phpsuexec on all
their webservers, citing security considerations. My question is...
is it really more secure?

Without phpsuexec, if a PHP script is to create new files, public
write permission needs to be enabled on the particular directory since
PHP is ran as user 'nobody'.

With phpsuexec, however, that's not needed. phpsuexec runs as the
root user.

The problem is... what happens if there's a vulnerability in a PHP
script? What happens if someone has a PHP script like this?:

<?php
eval($_GET['cmd']);
?>

Without phpsuexec, the only thing an attacker could do is to
manipulate files that *do* have public write permission. With
phpsuexec, however, an attacker can do whatever he wants to to pretty
much any file.

Basically, phpsuexec seems to me to only be a good approach to
security if you assume that PHP applications simply do not contain
vulnerabilities. Which is a dumb assumption. That's like believing
that just because you're running Windows XP SP3 with every update
installed that you don't need a Firewall.

Maybe I'm missing something? Or is phpsuexec just, flat out, a bad
idea?

Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
If they have it set up to run as root, they haven't configured it
properly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[yawnmoth]

On Jul 2, 1:40*pm, Jerry Stuckle <[e-mail]:

yawnmoth wrote:

A particular web hosting company decided to install phpsuexec on all
their webservers, citing security considerations. *My question is...
is it really more secure?

Without phpsuexec, if a PHP script is to create new files, public
write permission needs to be enabled on the particular directory since
PHP is ran as user 'nobody'.

With phpsuexec, however, that's not needed. *phpsuexec runs as the
root user.

The problem is... *what happens if there's a vulnerability in a PHP
script? *What happens if someone has a PHP script like this?:

<?php
eval($_GET['cmd']);
?>

Without phpsuexec, the only thing an attacker could do is to
manipulate files that *do* have public write permission. *With
phpsuexec, however, an attacker can do whatever he wants to to pretty
much any file.

Basically, phpsuexec seems to me to only be a good approach to
security if you assume that PHP applications simply do not contain
vulnerabilities. *Which is a dumb assumption. *That's like believing
that just because you're running Windows XP SP3 with every update
installed that you don't need a Firewall.

Maybe I'm missing something? *Or is phpsuexec just, flat out, a bad
idea?

Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
* * If they have it set up to run as root, they haven't configured it
properly.

Good catch.

In the above scenario, though, I'm not sure it'd make a difference?
If you created all the folders, running PHP scripts as you would mean
that all those folders are writable via vulnerabilities in your PHP
scripts. In contrast, if PHP was running as 'nobody', 'nobody'
wouldn't have the same permissions as you and as such, there'd be far
fewer directories that an attacker could write to. The only ones
they'd be able to write to are the publically writable ones, which,
presumably, would be a very small subset of the ones you created.

[Jerry Stuckle]

yawnmoth wrote:

On Jul 2, 1:40 pm, Jerry Stuckle <[e-mail]:

>yawnmoth wrote:

>>A particular web hosting company decided to install phpsuexec on all
their webservers, citing security considerations. My question is...
is it really more secure?
Without phpsuexec, if a PHP script is to create new files, public
write permission needs to be enabled on the particular directory since
PHP is ran as user 'nobody'.
With phpsuexec, however, that's not needed. phpsuexec runs as the
root user.
The problem is... what happens if there's a vulnerability in a PHP
script? What happens if someone has a PHP script like this?:
<?php
eval($_GET['cmd']);
?>
Without phpsuexec, the only thing an attacker could do is to
manipulate files that *do* have public write permission. With
phpsuexec, however, an attacker can do whatever he wants to to pretty
much any file.
Basically, phpsuexec seems to me to only be a good approach to
security if you assume that PHP applications simply do not contain
vulnerabilities. Which is a dumb assumption. That's like believing
that just because you're running Windows XP SP3 with every update
installed that you don't need a Firewall.
Maybe I'm missing something? Or is phpsuexec just, flat out, a bad
idea?

Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
If they have it set up to run as root, they haven't configured it
properly.

Good catch.

In the above scenario, though, I'm not sure it'd make a difference?
If you created all the folders, running PHP scripts as you would mean
that all those folders are writable via vulnerabilities in your PHP
scripts. In contrast, if PHP was running as 'nobody', 'nobody'
wouldn't have the same permissions as you and as such, there'd be far
fewer directories that an attacker could write to. The only ones
they'd be able to write to are the publically writable ones, which,
presumably, would be a very small subset of the ones you created.

Sure it would. It means you wouldn't be able to access someone else's
folders - which is important in a shared hosting environment.

Granted, there are other ways to do this - such as open_base_dir, but
what if you had other folders or files in there you wouldn't want PHP to
be able to write to?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Olaf Schinkel]

yawnmoth schrieb:

<?php
eval($_GET['cmd']);
?>

You will **not** realy do that!

Why?
I don´t need to put files on your server.
That is enough:

<?PHP
$e = array(lot of e-mail-adresses);
$t = "Spam code";

foreach($e as $email)
{
mail .....
}
?>

>
Without phpsuexec, the only thing an attacker could do is to

phpsuexec is good for you.
So the webserver runs with the same account you use with FTP.
When the webserver creates a file, you can delete it with FTP and files
created with ftp can be changed/erased, etc with the webserver.
Otherwise you always have trouble.

[yawnmoth]

On Jul 2, 2:50*pm, Jerry Stuckle <[e-mail]:

yawnmothwrote:

On Jul 2, 1:40 pm, Jerry Stuckle <[e-mail]:

>yawnmothwrote:
A particular web hosting company decided to install phpsuexec on all
their webservers, citing security considerations. *My question is...
is it really more secure?
Without phpsuexec, if a PHP script is to create new files, public
write permission needs to be enabled on the particular directory since
PHP is ran as user 'nobody'.
With phpsuexec, however, that's not needed. *phpsuexec runs as the
root user.
The problem is... *what happens if there's a vulnerability in a PHP
script? *What happens if someone has a PHP script like this?:
<?php
eval($_GET['cmd']);
?>
Without phpsuexec, the only thing an attacker could do is to
manipulate files that *do* have public write permission. *With
phpsuexec, however, an attacker can do whatever he wants to to pretty
much any file.
Basically, phpsuexec seems to me to only be a good approach to
security if you assume that PHP applications simply do not contain
vulnerabilities. *Which is a dumb assumption. *That's like believing
that just because you're running Windows XP SP3 with every update
installed that you don't need a Firewall.
Maybe I'm missing something? *Or is phpsuexec just, flat out, a bad
idea?
Actually, IIRC, phpsuexec runs the scripts as you, not as the root user..
* * If they have it set up to run as root, they haven't configured it
properly.

Good catch.

In the above scenario, though, I'm not sure it'd make a difference?
If you created all the folders, running PHP scripts as you would mean
that all those folders are writable via vulnerabilities in your PHP
scripts. *In contrast, if PHP was running as 'nobody', 'nobody'
wouldn't have the same permissions as you and as such, there'd be far
fewer directories that an attacker could write to. *The only ones
they'd be able to write to are the publically writable ones, which,
presumably, would be a very small subset of the ones you created.

Sure it would. *It means you wouldn't be able to access someone else's
folders - which is important in a shared hosting environment.

Granted, there are other ways to do this - such as open_base_dir, but
what if you had other folders or files in there you wouldn't want PHP to
be able to write to?

It seems like the bigger threat would be from external users, though,
and not paying users? A paying user, presumably, wouldn't want to
jeopardize their good standing with their host.

I guess phpsuexec would enable an admin to identify the owner of a
vulnerable web application, but can't you do better than that,
already, by just recording the URL that was accessed?

[yawnmoth]

On Jul 2, 3:36*pm, Olaf Schinkel <[e-mail]:

yawnmothschrieb:

<?php
eval($_GET['cmd']);
?>

You will **not** realy do that!

Why?
I don´t need to put files on your server.
That is enough:

<?PHP
$e = array(lot of e-mail-adresses);
$t = "Spam code";

foreach($e as $email)
{
* * * * mail .....}

?>

That was just an example. IIRC, PunBB had a vulnerability a while ago
whereby some language parameter was used in an include. eg.

include($row['language'] . '.php');

...where $row was defined by mysql_fetch_assoc(). Since PunBB, at
this time, didn't sanitize the language field, it allowed for null
byte injection and directory traversal. An attacker could set
$row['language'] to "../avatars/evil_avatar.jpg%00" and then run
arbitrary code on the server.

Quite unintentional on the part of the PunBB developers, but it was
quite a fatal mistake, none-the-less.

What happens if some other PHP application makes the same mistake?
phpsuexec gives anyone who might exploit a vulnerability such as this
much more power than they would have otherwise had.

Without phpsuexec, the only thing an attacker could do is to

phpsuexec is good for you.
So the webserver runs with the same account you use with FTP.
When the webserver creates a file, you can delete it with FTP and files
created with ftp can be changed/erased, etc with the webserver.
Otherwise you always have trouble.

That's actually kinda what's scary about phpsuexec, too. If an
attacker was able to exploit the above PunBB vulnerability, they could
delete files or modify them at their convenience - files that they
wouldn't be able to modify if phpsuexec wasn't installed.

It definitely is more convenient, but that convenience seems to come
at a fairly hefty price.

[Olaf Schinkel]

yawnmoth schrieb:

On Jul 2, 3:36 pm, Olaf Schinkel <[e-mail]:

>yawnmothschrieb:

>><?php
eval($_GET['cmd']);
?>

You will **not** realy do that!

Why?
I don´t need to put files on your server.
That is enough:

<?PHP
$e = array(lot of e-mail-adresses);
$t = "Spam code";

foreach($e as $email)
{
mail .....}

?>

That was just an example. IIRC, PunBB had a vulnerability a while ago
whereby some language parameter was used in an include. eg.

include($row['language'] . '.php');

...where $row was defined by mysql_fetch_assoc(). Since PunBB, at
this time, didn't sanitize the language field, it allowed for null
byte injection and directory traversal. An attacker could set
$row['language'] to "../avatars/evil_avatar.jpg%00" and then run
arbitrary code on the server.

Quite unintentional on the part of the PunBB developers, but it was
quite a fatal mistake, none-the-less.

What happens if some other PHP application makes the same mistake?
phpsuexec gives anyone who might exploit a vulnerability such as this
much more power than they would have otherwise had.

>>Without phpsuexec, the only thing an attacker could do is to

phpsuexec is good for you.
So the webserver runs with the same account you use with FTP.
When the webserver creates a file, you can delete it with FTP and files
created with ftp can be changed/erased, etc with the webserver.
Otherwise you always have trouble.

That's actually kinda what's scary about phpsuexec, too. If an
attacker was able to exploit the above PunBB vulnerability, they could
delete files or modify them at their convenience - files that they
wouldn't be able to modify if phpsuexec wasn't installed.

It definitely is more convenient, but that convenience seems to come
at a fairly hefty price.

I think:
phpsuexec is OK.
The main Problem is the code, executed on the webserver.
I have no problems with phpsuexec - i use it.

[Jerry Stuckle]

yawnmoth wrote:

On Jul 2, 2:50 pm, Jerry Stuckle <[e-mail]:

>yawnmothwrote:

>>On Jul 2, 1:40 pm, Jerry Stuckle <[e-mail]:
yawnmothwrote:
A particular web hosting company decided to install phpsuexec on all
their webservers, citing security considerations. My question is...
is it really more secure?
Without phpsuexec, if a PHP script is to create new files, public
write permission needs to be enabled on the particular directory since
PHP is ran as user 'nobody'.
With phpsuexec, however, that's not needed. phpsuexec runs as the
root user.
The problem is... what happens if there's a vulnerability in a PHP
script? What happens if someone has a PHP script like this?:
<?php
eval($_GET['cmd']);
?>
Without phpsuexec, the only thing an attacker could do is to
manipulate files that *do* have public write permission. With
phpsuexec, however, an attacker can do whatever he wants to to pretty
much any file.
Basically, phpsuexec seems to me to only be a good approach to
security if you assume that PHP applications simply do not contain
vulnerabilities. Which is a dumb assumption. That's like believing
that just because you're running Windows XP SP3 with every update
installed that you don't need a Firewall.
Maybe I'm missing something? Or is phpsuexec just, flat out, a bad
idea?
Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
If they have it set up to run as root, they haven't configured it
properly.
Good catch.
In the above scenario, though, I'm not sure it'd make a difference?
If you created all the folders, running PHP scripts as you would mean
that all those folders are writable via vulnerabilities in your PHP
scripts. In contrast, if PHP was running as 'nobody', 'nobody'
wouldn't have the same permissions as you and as such, there'd be far
fewer directories that an attacker could write to. The only ones
they'd be able to write to are the publically writable ones, which,
presumably, would be a very small subset of the ones you created.

Sure it would. It means you wouldn't be able to access someone else's
folders - which is important in a shared hosting environment.

Granted, there are other ways to do this - such as open_base_dir, but
what if you had other folders or files in there you wouldn't want PHP to
be able to write to?

It seems like the bigger threat would be from external users, though,
and not paying users? A paying user, presumably, wouldn't want to
jeopardize their good standing with their host.

I guess phpsuexec would enable an admin to identify the owner of a
vulnerable web application, but can't you do better than that,
already, by just recording the URL that was accessed?

Not necessarily. Hackers can get a cheap account on a shared server,
also. And even if it isn't a hacker - a poorly written script could
cause havoc on the entire server.

Detection after the fact is nowhere near as good as prevention.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[yawnmoth]

On Jul 2, 5:32*pm, Jerry Stuckle <[e-mail]:

yawnmoth wrote:

On Jul 2, 2:50 pm, Jerry Stuckle <[e-mail]:

yawnmothwrote:
On Jul 2, 1:40 pm, Jerry Stuckle <[e-mail]:
yawnmothwrote:
A particular web hosting company decided to install phpsuexec on all
their webservers, citing security considerations. *My question is....
is it really more secure?
Without phpsuexec, if a PHP script is to create new files, public
write permission needs to be enabled on the particular directory since
PHP is ran as user 'nobody'.
With phpsuexec, however, that's not needed. *phpsuexec runs as the
root user.
The problem is... *what happens if there's a vulnerability in a PHP
script? *What happens if someone has a PHP script like this?:
<?php
eval($_GET['cmd']);
?>
Without phpsuexec, the only thing an attacker could do is to
manipulate files that *do* have public write permission. *With
phpsuexec, however, an attacker can do whatever he wants to to pretty
much any file.
Basically, phpsuexec seems to me to only be a good approach to
security if you assume that PHP applications simply do not contain
vulnerabilities. *Which is a dumb assumption. *That's like believing
that just because you're running Windows XP SP3 with every update
installed that you don't need a Firewall.
Maybe I'm missing something? *Or is phpsuexec just, flat out, a bad
idea?
Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
* * If they have it set up to run as root, they haven't configured it
properly.
Good catch.
In the above scenario, though, I'm not sure it'd make a difference?
If you created all the folders, running PHP scripts as you would mean
that all those folders are writable via vulnerabilities in your PHP
scripts. *In contrast, if PHP was running as 'nobody', 'nobody'
wouldn't have the same permissions as you and as such, there'd be far
fewer directories that an attacker could write to. *The only ones
they'd be able to write to are the publically writable ones, which,
presumably, would be a very small subset of the ones you created.
Sure it would. *It means you wouldn't be able to access someone else's
folders - which is important in a shared hosting environment.

Granted, there are other ways to do this - such as open_base_dir, but
what if you had other folders or files in there you wouldn't want PHP to
be able to write to?

It seems like the bigger threat would be from external users, though,
and not paying users? *A paying user, presumably, wouldn't want to
jeopardize their good standing with their host.

I guess phpsuexec would enable an admin to identify the owner of a
vulnerable web application, but can't you do better than that,
already, by just recording the URL that was accessed?

Not necessarily. *Hackers can get a cheap account on a shared server,
also. *And even if it isn't a hacker - a poorly written script could
cause havoc on the entire server.

It seems to me, though, that a poorly written script would actually be
more of an issue with phpsuexec than without. I think the following
table (which assumes PHP, under phpsuexec, is running as 'marysue')
will help clarify things:

| 'joebob' 0777 | 'joebob' 0755 | 'marysue' 0755
with phpsuexec | can write | can't write | can write
without phpsuexec | can write | can't write | can't write

In the above chart, an attacker, exploiting a poorly written script,
can write to two directories when phpsuexec is being used, whereas he
can only write to one directory when phpsuexec *isn't* being used. In
other words, phpsuexec makes it so this attacker can write to more
directories than he previously would have been able to.

[Jerry Stuckle]

yawnmoth wrote:

On Jul 2, 5:32 pm, Jerry Stuckle <[e-mail]:

>yawnmoth wrote:

>>On Jul 2, 2:50 pm, Jerry Stuckle <[e-mail]:
yawnmothwrote:
On Jul 2, 1:40 pm, Jerry Stuckle <[e-mail]:
>yawnmothwrote:
>>A particular web hosting company decided to install phpsuexec on all
>>their webservers, citing security considerations. My question is...
>>is it really more secure?
>>Without phpsuexec, if a PHP script is to create new files, public
>>write permission needs to be enabled on the particular directory since
>>PHP is ran as user 'nobody'.
>>With phpsuexec, however, that's not needed. phpsuexec runs as the
>>root user.
>>The problem is... what happens if there's a vulnerability in a PHP
>>script? What happens if someone has a PHP script like this?:
>><?php
>>eval($_GET['cmd']);
>>?>
>>Without phpsuexec, the only thing an attacker could do is to
>>manipulate files that *do* have public write permission. With
>>phpsuexec, however, an attacker can do whatever he wants to to pretty
>>much any file.
>>Basically, phpsuexec seems to me to only be a good approach to
>>security if you assume that PHP applications simply do not contain
>>vulnerabilities. Which is a dumb assumption. That's like believing
>>that just because you're running Windows XP SP3 with every update
>>installed that you don't need a Firewall.
>>Maybe I'm missing something? Or is phpsuexec just, flat out, a bad
>>idea?
>Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
> If they have it set up to run as root, they haven't configured it
>properly.
Good catch.
In the above scenario, though, I'm not sure it'd make a difference?
If you created all the folders, running PHP scripts as you would mean
that all those folders are writable via vulnerabilities in your PHP
scripts. In contrast, if PHP was running as 'nobody', 'nobody'
wouldn't have the same permissions as you and as such, there'd be far
fewer directories that an attacker could write to. The only ones
they'd be able to write to are the publically writable ones, which,
presumably, would be a very small subset of the ones you created.
Sure it would. It means you wouldn't be able to access someone else's
folders - which is important in a shared hosting environment.
Granted, there are other ways to do this - such as open_base_dir, but
what if you had other folders or files in there you wouldn't want PHP to
be able to write to?
It seems like the bigger threat would be from external users, though,
and not paying users? A paying user, presumably, wouldn't want to
jeopardize their good standing with their host.
I guess phpsuexec would enable an admin to identify the owner of a
vulnerable web application, but can't you do better than that,
already, by just recording the URL that was accessed?

Not necessarily. Hackers can get a cheap account on a shared server,
also. And even if it isn't a hacker - a poorly written script could
cause havoc on the entire server.

It seems to me, though, that a poorly written script would actually be
more of an issue with phpsuexec than without. I think the following
table (which assumes PHP, under phpsuexec, is running as 'marysue')
will help clarify things:

| 'joebob' 0777 | 'joebob' 0755 | 'marysue' 0755
with phpsuexec | can write | can't write | can write
without phpsuexec | can write | can't write | can't write

In the above chart, an attacker, exploiting a poorly written script,
can write to two directories when phpsuexec is being used, whereas he
can only write to one directory when phpsuexec *isn't* being used. In
other words, phpsuexec makes it so this attacker can write to more
directories than he previously would have been able to.

But you're assuming marysue is going to have 755. That would not be the
case in any sane installation. And a good hosting company will prohibit it.

Also, phpsuexec won't allow anything to be done with files set to 0777.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[yawnmoth]

On Jul 2, 10:10*pm, Jerry Stuckle <[e-mail]:

yawnmothwrote:

On Jul 2, 5:32 pm, Jerry Stuckle <[e-mail]:

>yawnmothwrote:
On Jul 2, 2:50 pm, Jerry Stuckle <[e-mail]:
yawnmothwrote:
On Jul 2, 1:40 pm, Jerry Stuckle <[e-mail]:
yawnmothwrote:
>A particular web hosting company decided to install phpsuexec on all
>their webservers, citing security considerations. *My question is...
>is it really more secure?
>Without phpsuexec, if a PHP script is to create new files, public
>write permission needs to be enabled on the particular directory since
>PHP is ran as user 'nobody'.
>With phpsuexec, however, that's not needed. *phpsuexec runs as the
>root user.
>The problem is... *what happens if there's a vulnerability in a PHP
>script? *What happens if someone has a PHP script like this?:
><?php
>eval($_GET['cmd']);
>?>
>Without phpsuexec, the only thing an attacker could do is to
>manipulate files that *do* have public write permission. *With
>phpsuexec, however, an attacker can do whatever he wants to to pretty
>much any file.
>Basically, phpsuexec seems to me to only be a good approach to
>security if you assume that PHP applications simply do not contain
>vulnerabilities. *Which is a dumb assumption. *That's like believing
>that just because you're running Windows XP SP3 with every update
>installed that you don't need a Firewall.
>Maybe I'm missing something? *Or is phpsuexec just, flat out, a bad
>idea?
Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
* * If they have it set up to run as root, they haven't configured it
properly.
Good catch.
In the above scenario, though, I'm not sure it'd make a difference?
If you created all the folders, running PHP scripts as you would mean
that all those folders are writable via vulnerabilities in your PHP
scripts. *In contrast, if PHP was running as 'nobody', 'nobody'
wouldn't have the same permissions as you and as such, there'd be far
fewer directories that an attacker could write to. *The only ones
they'd be able to write to are the publically writable ones, which,
presumably, would be a very small subset of the ones you created.
Sure it would. *It means you wouldn't be able to access someone else's
folders - which is important in a shared hosting environment.
Granted, there are other ways to do this - such as open_base_dir, but
what if you had other folders or files in there you wouldn't want PHPto
be able to write to?
It seems like the bigger threat would be from external users, though,
and not paying users? *A paying user, presumably, wouldn't want to
jeopardize their good standing with their host.
I guess phpsuexec would enable an admin to identify the owner of a
vulnerable web application, but can't you do better than that,
already, by just recording the URL that was accessed?
Not necessarily. *Hackers can get a cheap account on a shared server,
also. *And even if it isn't a hacker - a poorly written script could
cause havoc on the entire server.

It seems to me, though, that a poorly written script would actually be
more of an issue with phpsuexec than without. *I think the following
table (which assumes PHP, under phpsuexec, is running as 'marysue')
will help clarify things:

* * * * * * * * * | 'joebob' 0777 | 'joebob' 0755 | 'marysue' 0755
with phpsuexec * *| * can write * | *can't write *| * *can write
without phpsuexec | * can write * | *can't write *| * can't write

In the above chart, an attacker, exploiting a poorly written script,
can write to two directories when phpsuexec is being used, whereas he
can only write to one directory when phpsuexec *isn't* being used. *In
other words, phpsuexec makes it so this attacker can write to more
directories than he previously would have been able to.

But you're assuming marysue is going to have 755. *That would not be the
case in any sane installation. *And a good hosting company will prohibitit.

Also, phpsuexec won't allow anything to be done with files set to 0777.

As the owner of her own files, marysue's going to have 7xx no matter
what, afaik (at the very least, I can't change it on my own host via
FTP). What the other values are seem to me to be of little
consequence, be they 755 or 700 or whatever.

And as for 777 being denied... well, to accommodate that, I guess we
can create a new chart - which directories can be accessed via HTTP
and can also be written to via a PHP script (if both are true, then
we'll say "yes"; otherwise, we'll say "no"):

| 'joebob' 0777 | 'joebob' 0755 | 'marysue' 0755
with phpsuexec | no | no | yes
without phpsuexec | yes | no | no

So, per that, it seems like phpsuexec doesn't prevent attack - it just
changes the conditions under which you can be attacked.

Further, it seems that of those two conditions - 'joebob' 0777 and
'marysue' 0755 - that 'marysue' 0755 is, by far, the more dangerous
one. 'joebob' may not even have any directories with 0777 permissions
and even if he does, it's, presumably, only going to be a small
subset. 'marysue', on the other hand, is going to have her every
directory with 07xx permissions and there's not a whole lot she can do
about that.

[Jerry Stuckle]

yawnmoth wrote:

On Jul 2, 10:10 pm, Jerry Stuckle <[e-mail]:

>yawnmothwrote:

>>On Jul 2, 5:32 pm, Jerry Stuckle <[e-mail]:
yawnmothwrote:
On Jul 2, 2:50 pm, Jerry Stuckle <[e-mail]:
>yawnmothwrote:
>>On Jul 2, 1:40 pm, Jerry Stuckle <[e-mail]:
>>>yawnmothwrote:
>>>>A particular web hosting company decided to install phpsuexec on all
>>>>their webservers, citing security considerations. My question is...
>>>>is it really more secure?
>>>>Without phpsuexec, if a PHP script is to create new files, public
>>>>write permission needs to be enabled on the particular directory since
>>>>PHP is ran as user 'nobody'.
>>>>With phpsuexec, however, that's not needed. phpsuexec runs as the
>>>>root user.
>>>>The problem is... what happens if there's a vulnerability in a PHP
>>>>script? What happens if someone has a PHP script like this?:
>>>><?php
>>>>eval($_GET['cmd']);
>>>>?>
>>>>Without phpsuexec, the only thing an attacker could do is to
>>>>manipulate files that *do* have public write permission. With
>>>>phpsuexec, however, an attacker can do whatever he wants to to pretty
>>>>much any file.
>>>>Basically, phpsuexec seems to me to only be a good approach to
>>>>security if you assume that PHP applications simply do not contain
>>>>vulnerabilities. Which is a dumb assumption. That's like believing
>>>>that just because you're running Windows XP SP3 with every update
>>>>installed that you don't need a Firewall.
>>>>Maybe I'm missing something? Or is phpsuexec just, flat out, a bad
>>>>idea?
>>>Actually, IIRC, phpsuexec runs the scripts as you, not as the root user.
>>> If they have it set up to run as root, they haven't configured it
>>>properly.
>>Good catch.
>>In the above scenario, though, I'm not sure it'd make a difference?
>>If you created all the folders, running PHP scripts as you would mean
>>that all those folders are writable via vulnerabilities in your PHP
>>scripts. In contrast, if PHP was running as 'nobody', 'nobody'
>>wouldn't have the same permissions as you and as such, there'd be far
>>fewer directories that an attacker could write to. The only ones
>>they'd be able to write to are the publically writable ones, which,
>>presumably, would be a very small subset of the ones you created.
>Sure it would. It means you wouldn't be able to access someone else's
>folders - which is important in a shared hosting environment.
>Granted, there are other ways to do this - such as open_base_dir, but
>what if you had other folders or files in there you wouldn't want PHP to
>be able to write to?
It seems like the bigger threat would be from external users, though,
and not paying users? A paying user, presumably, wouldn't want to
jeopardize their good standing with their host.
I guess phpsuexec would enable an admin to identify the owner of a
vulnerable web application, but can't you do better than that,
already, by just recording the URL that was accessed?
Not necessarily. Hackers can get a cheap account on a shared server,
also. And even if it isn't a hacker - a poorly written script could
cause havoc on the entire server.
It seems to me, though, that a poorly written script would actually be
more of an issue with phpsuexec than without. I think the following
table (which assumes PHP, under phpsuexec, is running as 'marysue')
will help clarify things:
| 'joebob' 0777 | 'joebob' 0755 | 'marysue' 0755
with phpsuexec | can write | can't write | can write
without phpsuexec | can write | can't write | can't write
In the above chart, an attacker, exploiting a poorly written script,
can write to two directories when phpsuexec is being used, whereas he
can only write to one directory when phpsuexec *isn't* being used. In
other words, phpsuexec makes it so this attacker can write to more
directories than he previously would have been able to.

But you're assuming marysue is going to have 755. That would not be the
case in any sane installation. And a good hosting company will prohibit it.

Also, phpsuexec won't allow anything to be done with files set to 0777.

As the owner of her own files, marysue's going to have 7xx no matter
what, afaik (at the very least, I can't change it on my own host via
FTP). What the other values are seem to me to be of little
consequence, be they 755 or 700 or whatever.

And as for 777 being denied... well, to accommodate that, I guess we
can create a new chart - which directories can be accessed via HTTP
and can also be written to via a PHP script (if both are true, then
we'll say "yes"; otherwise, we'll say "no"):

| 'joebob' 0777 | 'joebob' 0755 | 'marysue' 0755
with phpsuexec | no | no | yes
without phpsuexec | yes | no | no

So, per that, it seems like phpsuexec doesn't prevent attack - it just
changes the conditions under which you can be attacked.

Further, it seems that of those two conditions - 'joebob' 0777 and
'marysue' 0755 - that 'marysue' 0755 is, by far, the more dangerous
one. 'joebob' may not even have any directories with 0777 permissions
and even if he does, it's, presumably, only going to be a small
subset. 'marysue', on the other hand, is going to have her every
directory with 07xx permissions and there's not a whole lot she can do
about that.

Again, you're assuming marysue is going to have 0755. That is not a
valid assumption, and without it, your whole argument falls apart.

First of all, web scripts don't have execute privileges. And a good
host will not allow the user to make it world-writable. Marysue's files
are probably 640, or at the very worst, 644.

But we've gotten way off of PHP topics. If you want to pursue security
further, I suggest you try a Linux admin newsgroup.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================