> 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
