Paul Laudanski wrote:
On Mon, 26 Dec 2005, Yasuo Ohgaki wrote:
But I don't insist nx bit support is useless.
I'm not sure I follow this one? Are you meaning:
http://en.wikipedia.org/wiki/NX_bit
Yes.
As you probably know, PHP's include/require statement will execute
remote script by default.
e.g. include('http://example.com/bad-script');
IMHO,ãallow_url_fopen (or like) should provide NX bit like safe guard
feature.
Anyway, most php script do not need remote script execution feature.
And even with SELinux, it cannot prevent to execute remote code while
access to local file could be rejected and reported.
Making allow_url_fopen useless is bad thing.
Can you expand on this one please, or are you throwing it back to your
original reply?
PHP has sevral safe guard features.
open_basedir:
open_basedir is unreliable as it was implemented in application (PHP) level.
With SELinux, admin don't have to rely on open_basedir to restrict access
to sensible files.
Even if open_basedir is unreliable, but it's useful as safe guard.
allow_url_fopen:
It restricts remote code execution. However, since the introduction of
php://input,
PHP allows remote code injection regardless of allow_url_fopen setting. (for
bad PHP
script, of course.) For some known reason to me, allow_url_fopen was changed
form
INI_ALL to INI_SYSTEM setting from PHP 4.3.x. (i.e. INI_ALL - script can change
setting, INI_SYSTEM - only system level config can change setting) Firewall may
restrict outbound port 80 access from web servers, but mordern web sites require
external web service access. Therefore, restricting outbound web access is not
practical as safe guard.
If PHP handles allow_url_fopen properly, it would be a good safe guard.
allow_url_include:
Added 2005-11-18 by Rasmus, it is replacement for allow_url_fopen for
include/require,
only available in CVS version (PHP6). It seems to have "php://input script
injection"
vulnerability still. (Not verified. I just read the patch. The patch only add
new
config value to check. Others might add proper code to restrict php://input.)
If PHP handles allow_url_include properly, it would be a good safe guard.
I just would like to mention that recent changes regarding to allow_url_fopen
feature
wasn't a good one for security perspective. OWASP guideline has recommended PHP
setting at the end of the document. It recommends allow_url_fopen=off, but
INI_ALL -> INI_SYSTEM change was made it impossible as some basic features
require
allow_url_fopen=on. In addition, "php://input script injection" vulnerability
spoils allow_url_fopen=off as safe guard.
(e.g. PHP scripts that have remote script execution vulnerability has
php://input
script injection vulnerability most likely.)
OWASP guideline may be better to be updated, since allow_url_fopen=off
is not practical and allow_url_fopen=off does not provide good enough safe
guard.
--
Yasuo Ohgaki
