RE: function sleep() in all versions of PHP
> From: charlesmorris@xxxxxxxxx
> [mailto:charlesmorris@xxxxxxxxx] On Behalf Of Charles Morris
> Sent: Tuesday, 27 May, 2008 13:14
>
> The reasoning behind this is behind the definition of
> vulnerability, and here is a good one:
> "a weakness in a system allowing unauthorized action [(NRC91:301;
> Amo94:2) Sandia] A flaw or weakness in a system's design,
> implementation, or operation and management that could be
> exploited to violate the system's security policy. ..."
That definition, however useful it may be in some contexts, is
sufficiently broad that it can be used to argue that essentially any
affordance is a vulnerability.
For example: password-based login systems enforce security using secrets
held by humans, and we know humans are inherently unreliable, so
password-based login systems are a vulnerability.
That's true (and indeed password-based login has been widely critiqued
as a really lousy authentication mechanism), but in itself it's a vapid
observation.
> In this case a security policy has been designated with the
> "max_execution_time" directive and that policy is being
> violated by the blocking code.
No, it is not, since "execution time" here is defined as CPU time. This
"vulnerability" report is factually incorrect, as well as pointless.
> As with any vulnerability it is the vendor's responsibility
> to provide a fix and protect it's users.
No, it is not. My desktop machine, as supplied by the vendor, was
vulnerable to the dreaded "power failure" denial of service attack. Was
it Dell's responsibility to supply me with a UPS? (And what if the UPS
battery fails? Maybe Dell should be required to provide me with a
guaranteed unlimited supply of electricity.)
> I am of the opinion that PHP (As PHP (not Apache) is the one
> providing the "max_execution_time" directive) should
> automatically interrupt any processes in the process tree
> from the current script execution to avoid violation of the directive.
You're proposing the subsystem implement an asynchronous watchdog that
uses some as-yet-unspecified, platform-dependent mechanism to terminate
processes out of band, with no recovery? Nothing could possibly go wrong
with *that*.
Let me see if I have this straight. The threat is that an attacker can
get PHP running on a server to make a sleep() call with a large
argument, and thus consume resources. The solution is a fragile,
unpredictable, arbitrary hack.
I'd say the attacker's already won - a good trick, since this
hypothetical attacker doesn't even exist.
A better question might be: just what branch of the attack tree are you
trying to prune? If your attacker can run arbitrary PHP code on your
server, why would he waste time with this sleep() nonsense?
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus