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.

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}

A lot of the config stuff is read-only from within a request, but sure, if you manage to get the web app to run some arbitrary code, you can probably find some way to mess up the config for that child process. You could do pretty much anything, like run a system command to wipe whatever part of the hard drive you have access to. You can certainly do things to mess up the perl interpreter in that child process, like screwing up @INC, reading other people's globals, redefining methods, etc. The fact that FastCGI won't let you touch the web server config from a compromised process doesn't sound very valuable to me when you consider all the other things you could do.