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_at_gclements.plus.com>
Received on May 28 2008
Intro
