You are right in what concerns environment; but a crash in mod_perl takes down the apache child, whereas with fastcgi only perl is blown away. The apache child talking to it serves a 500 error page (or whatever it got until that) and stays alive.
With a compromise, the situation is worse with mod_perl. If you've 0wn3d a mod_perl script, you've got apache, not just the script as in fastcgi.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
With FastCGI, perl and the FastCGI child process dies. There is no meaningful difference between that and an apache/mod_perl process dying. In both cases, the current request is ruined, another process is spawned, and things continue.
With a security problem, you do not "get" apache if you compromise a mod_perl script. You have no access to anything else in the server but your current process, and certainly no access to the parent process. What matters is what you can do to the system itself, which is determined by what user you run as, and this is the same for FastCGI.
| [reply] |
That really depends on the type of exploit. AFAIK it's possible to change
the server runtime config of an apache child from within a mod_perl script
(please correct me if I'm wrong), and that copy might be serving other things
than just that script.
So, you have that apache child owned for it's lifetime (of course not the
parent), which could lead to further exploits in other areas of the webserver.
That's not possible with fastcgi.
Of course all this is theoretical without a POC.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
