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?
12  1658 
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*******@attgl obal.net
=============== ===
On Jul 2, 1:40*pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
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.
yawnmoth wrote:
On Jul 2, 1:40 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
>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
vulnerabiliti es. 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*******@attgl obal.net
=============== ===
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.
On Jul 2, 2:50*pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
yawnmothwrote:
On Jul 2, 1:40 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
>yawnmothwrot e:
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
vulnerabilitie s. *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?
On Jul 2, 3:36*pm, Olaf Schinkel <tr...@schinkel .tvwrote:
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_ass oc(). 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.
yawnmoth schrieb:
On Jul 2, 3:36 pm, Olaf Schinkel <tr...@schinkel .tvwrote:
>yawnmothschrie b:
>><?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_ass oc(). 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.
yawnmoth wrote:
On Jul 2, 2:50 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
>yawnmothwrot e:
>>On Jul 2, 1:40 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
yawnmothwrot e:
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($_GE T['cmd']);
?>
Without phpsuexec, the only thing an attacker could do is to
manipulat e 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
vulnerabili ties. 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*******@attgl obal.net
=============== ===
On Jul 2, 5:32*pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
yawnmoth wrote:
On Jul 2, 2:50 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
yawnmothwrote:
On Jul 2, 1:40 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:
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
vulnerabilit ies. *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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: R. Gregg Reed |
last post by:
I bought a script called WebDate and installed it on my server, where it
worked fine. A week ago my hosting company installed phpsuexec, and now the
mail function won't work. I keep getting errors like:
********************************************************
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The...
|
by: millrace |
last post by:
helloo
i'm crying out for some apache ownership help please :)
i've got a problem with some directly-web-accessible and
not-directly-web-accessible scripts that i've written to run in apache.
looking at the net, i guess it's an old problem, but my isp isn't
running phpsuexec. therefore apache is creating files as 'nobody'.
however, when i ftp files onto the server they are owned by myuid. but
|
by: robert |
last post by:
well, talk about timely. i'm tasked to implement a security feature,
and would rather do so in the database than the application code. the
application is generally Oracle, but sometimes DB2. Oracle has what
it calls package DBMS_RLS, which implements application ignorant
row level security.
scanning this group yielded "you can't do that; use views". then i
dug out DB2Mag qtr 1 2004, and there is MLS for v8/390. from this
article,...
|
by: Mike MacSween |
last post by:
S**t for brains strikes again!
Why did I do that? When I met the clients and at some point they vaguely
asked whether eventually would it be possible to have some people who could
read the data and some who couldn't but that it wasn't important right now.
And I said, 'sure, we can do that later'.
So now I've developed an app without any thought to security and am trying
to apply it afterwards. Doh!, doh! and triple doh!
|
by: Ashish |
last post by:
Hi Guys
I am getting the following error while implementing authentication using
WS-security.
"Microsoft.Web.Services2.Security.SecurityFault: The security token could
not be authenticated or authorized ---> System.Exception: WSE565: The
password provided the SecurityTokenManager does not match the one on the
incoming token. at
Microsoft.Web.Services2.Security.Tokens.UsernameTokenManager.VerifyPlainText
| | |
by: prithvi g via .NET 247 |
last post by:
Hi
I am a newbie to .NET remoting, I am trying to implementauthorization using SSPI example provided by Michael Barnett. Ihave included the required dll(Microsoft.Samples.Security.SSPI.dll andMicrosoft.Samples.Runtime.Remoting. Security in both my clientand server. I have have defined my config files as follows
for client
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.runtime.remoting>
<application>
<channels>...
|
by: Earl Teigrob |
last post by:
Background:
When I create a ASP.NET control (User or custom), it often requires security to be set for certain functionality with the control. For example, a news release user control that is comprised of a DataGrid may have separate permissions for adding, deleting and updating a news item.
Problem
Up until now, I have been implementing security directly inside the control. I will test directly against the security model to see if...
|
by: Magdelin |
last post by:
Hi,
My security team thinks allowing communication between the two IIS instances
leads to severe security risks. Basically, we want to put our presentation
tier on the perimeter network and the business tier inside the fire wall or
internal network. The biz tier will be developed and deployed as web services
on IIS.
I know microsoft recommends this architecture but I am not able to convince
my security team. They say IIS is vulnerable...
|
by: hansBKK |
last post by:
Upfront disclaimer - I am a relative newbie, just starting out learning
about PHP, mostly by researching, installing and playing with different
scripts. I am looking for a host that will provide the right environment
for this - running a wide variety of PHP applications. I realise that
security is also important, but for now flexibility is more important to
me.
Note that I'm **not** looking for people to recommend hosting companies,
I...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
