Interesting paper, Gadi. Some thoughts: 1) It seems obvious that RFI is equivalent to remote code execution, but it's worth repeating. 2) A PHP exploit is much easier to write than a shellcode exploit. Plus, with the file inclusion, the payload is not limited in size, and you have a lot more reliability because you don't have to worry about platform variations. Also, a fairly unskilled attacker can simply plug URLs into some parameters to find an RFI issue in a custom application. 3) The fact that you're seeing a lot of live attacks shows that, despite register_globals being disabled by default in PHP for a few years now, it's frequently enabled. And even if it's disabled, some developers will implement their own version of register_globals by using dangerous constructs such as eval(), extract(), and $$varname (the latter being what I call dynamic variable evaluation). Since these constructs can be equivalent to register_globals, they can be as dangerous. 4) Besides register_globals, other bugs/features in the PHP interpreter probably contribute to the high numbers of PHP application vulnerabilities. Stefan Esser's work in this area is extensive. The GLOBALS variable overwrite, and overwrite issues for other superglobals, will allow an attacker to control critical variables that the programmer would reasonably assume are safe. The unset() and XSS-in-error-messages bugs have been fixed, but how many servers still run vulnerable PHP versions? PHP 5 still supports some remote behaviors even when allow_fopen_url is disabled. 5) RFI's success in compromising web servers is probably one reason why we see so many RFI vulnerabilities being disclosed (along with other factors like ease of discovery and prevalence of PHP applications). - Steve
