Re^7: Perl needs Zend (mod_perl vs. 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}

Comment on Re^7: Perl needs Zend (mod_perl vs. fastcgi)

Replies are listed 'Best First'.
Re^8: Perl needs Zend (mod_perl vs. fastcgi) by perrin (Chancellor) on Oct 26, 2006 at 19:28 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^8: Perl needs Zend (mod_perl vs. fastcgi)
by perrin (Chancellor) on Oct 26, 2006 at 19:28 UTC

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.

[reply]