----- Original Message -----
From: "exon" <exon@home.se>
Because if an attacker can set environment variables to arbitrary values
through a webserver exploit he/she can also modify other slices of memory
making PHP-scripts the last of your worries. An exploit not requiring PHP
to be installed and sending the $_SERVER provided variables will be
infinitely easier to write (due to heap/stack offset reasons, where eip
and such can be easily calculated but arbitrary variables cannot without
some serious code injection) and more generic as well. In short; No idiot
on earth would want to change the values of $_SERVER in hope that it will
be used if they already have the possibility to execute arbitrary code.
Sorry for the late reply, but things have been busy...
Anyhow, the thing you've forgotten is that it _can_ be overwritten, without
any bugs in PHP, but with a poorly configured installation of PHP. Two
things are needed: 1: register_globals turned on, and 2: variables_order
changed from having S at the end, to having any one of G or P afterwards.
(Meaning those variables are processed after SERVER variables). This is
clearly indicated in the PHP docs as variable poisoning being a common issue
when register_globals is used in conjunction with assumptive code, here:
http://www.php.net/manual/en/security.globals.php
So, no, it doesn't take any miracle flaw in PHP, just a bad admin. And,
I've seen things far more stupid happen. I don't see why one worries about
ten cpu cycles or one line of code, or whatever, here, when security is of
the essence. If you get in the mind of "don't trust anything" you won't be
taken by surprise when your assumptions don't pan out.
!c
