lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18492.37906.687014.172229@cerise.gclements.plus.com>
Date: Wed, 28 May 2008 00:06:58 +0100
From: Glynn Clements <glynn@...ements.plus.com>
To: "Charles Morris" <cmorris@...odu.edu>
Cc: "Mark Sanders" <mark@...nox.nl>, gogulas@...pl,
	bugtraq@...urityfocus.com
Subject: Re: function sleep() in all versions of PHP


Charles Morris wrote:

> I agree with you that this is a known issue, and that there are ways
> around it, however I would in fact call it a vulnerability.

That depends upon your threat model.

If you are treating max_execution_time as protection against malicious
scripts, then it's a vulnerability, and not one which is easily fixed.
 
OTOH, if you merely consider it a precaution against "runaway"
scripts, which aren't actively trying to evade such constraints, then
it's just a limitation (and, AFAICT, an intentional one, i.e. it's
only intended to limit CPU usage).

> I am of the opinion that PHP ... should automatically interrupt any
> processes in the process tree from the current script execution

That's easier said than done, particularly if you are trying to
protect against malicious scripts.

A child which is trying to evade such termination can fork() and have
the parent exit. This will leave a gap in the chain of parent/child
relationships, so it can no longer be traced back to the original
child process. Even if PHP runs each child in a separate process group
or session, the child can just move itself to a new process group or
session.

Almost anything which is inherited across a fork() can be discarded or
changed. The things which can't (UID, GIDs, chroot, etc) would need
root privilege to initialise.

Essentially, once PHP has spawned a child, it's control over the child
and its descendents is limited to whatever features the kernel
provides. If you limit yourself to bare-bones POSIX (no capabilities,
or extensions such as SELinux or RSBAC), the set of features is rather
lacking in this regard.

-- 
Glynn Clements <glynn@...ements.plus.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ