Comparing the PHP *interpreter itself* to other interpreters likely reveals many more vulns. But as Jericho and I said in this summer's Black Hat talk on vuln stats, "just say no" to comparing products based solely on vuln counts. The PHP interpreter has benefited from close attention by researchers like Stefan Esser, but we simply don't know how much effort and researcher expertise has been put into other interpreters. Maybe people just aren't looking as hard. Also, many PHP-interpreter vulns are relatively low severity (e.g. sandbox escapes requiring a code path from an application that uses an API that's rarely if ever exposed to untrusted data). Maybe the devs of other interpreters don't report low-risk issues like crashes as vulnerabilities. Etc...
All that said, PHP is a great object lesson in which easy-to-use features can enable deadly application-layer vulnerabilities (e.g. remote file inclusion, register_globals). It's been interesting to see PHP evolve over the years to remove many of the more dangerous features. And the recent reports on Ruby gem vulns show that the old school vulnerabilities don't go away just 'cause there's a newer language. I'm not aware of any work that consciously tries to compare interpreters using a fixed, comprehensive list of "desired security features" beyond the surface-level measurements like number of vulns reported, but that would be some interesting work indeed. - Steve _______________________________________________ Dailydave mailing list [email protected] https://lists.immunityinc.com/mailman/listinfo/dailydave
