RE: [Ganglia-general] PHP security concerns?
Hi Brooks.
After reading up on www.php.net , I have learned a little more. One of my
colleagues expressed concerns about php because of possible automatic
conversion of PHP forms to global variables.
Here's an excerpt from the PHP docs explaining the dangers:
For various reasons, PHP setups which rely on register_globals being on (i.e.,
on form, server and environment variables becoming a part of the global
namespace, automatically) are very often exploitable to various degrees. For
example, the piece of code:
?php
if (authenticate_user()) {
$authenticated = true;
}
...
?
May be exploitable, as remote users can simply pass on 'authenticated' as a
form variable, and then even if authenticate_user() returns false,
$authenticated will actually be set to true. While this looks like a simple
example, in reality, quite a few PHP applications ended up being exploitable by
things related to this misfeature.
-
Well, the good news is I believe that the Ganglia web frontend does not require
register_globals to be turned on. Local variables are initialized using PHP
predefined arrays such as $HTTP_GET_VARS and the web page that displays the php
module configuration (info.php) appears to confirm that in our case,
register_globals is turned off. Next step is to try safe_mode .
Yemi
-Original Message-
From: Brooks Davis [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 10:51 AM
To: Adesanya, Adeyemi
Cc: 'ganglia-general@lists.sourceforge.net'
Subject: Re: [Ganglia-general] PHP security concerns?
On Mon, May 24, 2004 at 10:18:35AM -0700, Adesanya, Adeyemi wrote:
Hi There.
Our Ganglia monitoring system has been growing in size and
popularity
and we would like to increase it's visibility by serving
the frontend
on a public web server. So far, the frontend has only been
accessible
from within our intranet or via ssh tunnel.
We are seeking approval from our web team who currently do
not enable
PHP on public web servers due to security concerns. They
may however
make an exception if the web pages can run under 'PHP
safe_mode'. Do
you think their concerns are reasonable/justified? What
experience do
we have running the web frontend in safe_mode? How much additional
work (if any) is required???
There are two major issues with PHP. First, its default
security model means that everything runs as the webserver
user. That means PHP on a multiuser system is inadvisable.
Second, there's a lot of REALLY crappy PHP code out there.
One guy I know who works for an ISP says they clean up a
break-in at least once a week caused by bad PHP code. Most
of those are caused by idiots installing outdated code they
download from untrustworthy sites.
I'm not sure what would be required to run Ganglia in safe mode.
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
RE: [Ganglia-general] PHP security concerns?
yemi-
you shouldn't have any problem running in safe mode.. except that you
will need to explicitly state the path to the rrdtool binary in the
safe configuration. otherwise, php will not allow it to be run. (i
can't remember exactly how that is done but i've seen it bounced around
the list).
as you say, we don't rely on register_globals. that security concern
isn't an issue with ganglia.
-matt
On Mon, 2004-05-24 at 16:41, Adesanya, Adeyemi wrote:
Hi Brooks.
After reading up on www.php.net , I have learned a little more. One of my
colleagues expressed concerns about php because of possible automatic
conversion of PHP forms to global variables.
Here's an excerpt from the PHP docs explaining the dangers:
For various reasons, PHP setups which rely on register_globals being on
(i.e., on form, server and environment variables becoming a part of the
global namespace, automatically) are very often exploitable to various
degrees. For example, the piece of code:
?php
if (authenticate_user()) {
$authenticated = true;
}
...
?
May be exploitable, as remote users can simply pass on 'authenticated' as a
form variable, and then even if authenticate_user() returns false,
$authenticated will actually be set to true. While this looks like a simple
example, in reality, quite a few PHP applications ended up being exploitable
by things related to this misfeature.
-
Well, the good news is I believe that the Ganglia web frontend does not
require register_globals to be turned on. Local variables are initialized
using PHP predefined arrays such as $HTTP_GET_VARS and the web page that
displays the php module configuration (info.php) appears to confirm that in
our case, register_globals is turned off. Next step is to try safe_mode .
Yemi
-Original Message-
From: Brooks Davis [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 10:51 AM
To: Adesanya, Adeyemi
Cc: 'ganglia-general@lists.sourceforge.net'
Subject: Re: [Ganglia-general] PHP security concerns?
On Mon, May 24, 2004 at 10:18:35AM -0700, Adesanya, Adeyemi wrote:
Hi There.
Our Ganglia monitoring system has been growing in size and
popularity
and we would like to increase it's visibility by serving
the frontend
on a public web server. So far, the frontend has only been
accessible
from within our intranet or via ssh tunnel.
We are seeking approval from our web team who currently do
not enable
PHP on public web servers due to security concerns. They
may however
make an exception if the web pages can run under 'PHP
safe_mode'. Do
you think their concerns are reasonable/justified? What
experience do
we have running the web frontend in safe_mode? How much additional
work (if any) is required???
There are two major issues with PHP. First, its default
security model means that everything runs as the webserver
user. That means PHP on a multiuser system is inadvisable.
Second, there's a lot of REALLY crappy PHP code out there.
One guy I know who works for an ISP says they clean up a
break-in at least once a week caused by bad PHP code. Most
of those are caused by idiots installing outdated code they
download from untrustworthy sites.
I'm not sure what would be required to run Ganglia in safe mode.
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
--
Mobius strippers never show you their back side
PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3'
signature.asc
Description: This is a digitally signed message part
Re: [Ganglia-general] PHP security concerns?
Great. Thanks for confirming.
Yemi
On 5/24/04 4:49 PM, Matt Massie [EMAIL PROTECTED] wrote:
yemi-
you shouldn't have any problem running in safe mode.. except that you
will need to explicitly state the path to the rrdtool binary in the
safe configuration. otherwise, php will not allow it to be run. (i
can't remember exactly how that is done but i've seen it bounced around
the list).
as you say, we don't rely on register_globals. that security concern
isn't an issue with ganglia.
-matt
On Mon, 2004-05-24 at 16:41, Adesanya, Adeyemi wrote:
Hi Brooks.
After reading up on www.php.net , I have learned a little more. One of my
colleagues expressed concerns about php because of possible automatic
conversion of PHP forms to global variables.
Here's an excerpt from the PHP docs explaining the dangers:
-
---
For various reasons, PHP setups which rely on register_globals being on
(i.e., on form, server and environment variables becoming a part of the
global namespace, automatically) are very often exploitable to various
degrees. For example, the piece of code:
?php
if (authenticate_user()) {
$authenticated = true;
}
...
?
May be exploitable, as remote users can simply pass on 'authenticated' as a
form variable, and then even if authenticate_user() returns false,
$authenticated will actually be set to true. While this looks like a simple
example, in reality, quite a few PHP applications ended up being exploitable
by things related to this misfeature.
-
Well, the good news is I believe that the Ganglia web frontend does not
require register_globals to be turned on. Local variables are initialized
using PHP predefined arrays such as $HTTP_GET_VARS and the web page that
displays the php module configuration (info.php) appears to confirm that in
our case, register_globals is turned off. Next step is to try safe_mode .
Yemi
-Original Message-
From: Brooks Davis [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 10:51 AM
To: Adesanya, Adeyemi
Cc: 'ganglia-general@lists.sourceforge.net'
Subject: Re: [Ganglia-general] PHP security concerns?
On Mon, May 24, 2004 at 10:18:35AM -0700, Adesanya, Adeyemi wrote:
Hi There.
Our Ganglia monitoring system has been growing in size and
popularity
and we would like to increase it's visibility by serving
the frontend
on a public web server. So far, the frontend has only been
accessible
from within our intranet or via ssh tunnel.
We are seeking approval from our web team who currently do
not enable
PHP on public web servers due to security concerns. They
may however
make an exception if the web pages can run under 'PHP
safe_mode'. Do
you think their concerns are reasonable/justified? What
experience do
we have running the web frontend in safe_mode? How much additional
work (if any) is required???
There are two major issues with PHP. First, its default
security model means that everything runs as the webserver
user. That means PHP on a multiuser system is inadvisable.
Second, there's a lot of REALLY crappy PHP code out there.
One guy I know who works for an ISP says they clean up a
break-in at least once a week caused by bad PHP code. Most
of those are caused by idiots installing outdated code they
download from untrustworthy sites.
I'm not sure what would be required to run Ganglia in safe mode.
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
