in reply to Re: Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
in thread mod_perl and shared environments don't mix - do they?

the difference is that if a user has permission to run mod_perl as part of a shared server environment that user can load leaky C code - custom C modules for php would have to be compiled into the server by the administrator

In both cases you need nothing more than the ability to compile the module and the ability to add it to the path. Instructions for loading a custom C library from a PHP page are here.

Mod_perl can modify apache internals

Like what? You can add configuration directives, if you have the ability to compile a C module and add it to httpd.conf. You can control which phase your module gets called in (to create an auth handler), but that's no more of a security risk than any other access. You can modify values of the current request, but again, this doesn't hurt any one else. Looking down the API, I just don't see anything that would allow one to wreak more havoc than you could with PHP.

  • Comment on Re: Re: Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
by bean (Monk) on Aug 11, 2003 at 17:44 UTC
    Interesting - I was not aware of the dl() function for PHP. Of course, it would be disabled by any halfway competent administrator (because safe_mode would be enabled, which cannot be overridden by a user).

    I haven't tried it, but with mod_perl a user ought to be able to modify his/her virtual host document root and mess with other users' stuff (it could modify anything dynamically generated). A user might be able to bypass bandwidth throttling too (although that could be fixed with proxy servers). What else... Would it be impossible for a mod_perl script to persist in the apache child and monitor information passing to and from the sites of other users?

    The bottom line is, PHP is designed to be friendly to administrators. Mod_perl is designed to do anything and isn't appropriately sandboxed for shared environments.
[reply]
      I agree that mod_perl is not appropriate for environments with potentially malicious users in a shared environment; I just don't agree with your reasons. I think they show some common misconceptions about mod_perl, e.g. memory leaks and dangerous apache API. The reason it's unsafe is all on the perl side, i.e. you can mess with other people globals, functions, etc. as much as you want to.

      I haven't tried it, but with mod_perl a user ought to be able to modify his/her virtual host document root and mess with other users' stuff

      You're thinking of adding things like an access handler or filter to someone else's stuff? You can only change that sort of configuration during startup, which would require you to have admin privileges on the server. After startup, docroot can't be changed.

      A user might be able to bypass bandwidth throttling too

      If you give people just Apache::Registry access and no use of .htaccess files they would not be able to, since it would be too late in the request for that. They could skip a cleanup or logging handler though.

      Would it be impossible for a mod_perl script to persist in the apache child and monitor information passing to and from the sites of other users?

      Not really. Your code ends when the request ends. However, you could take advantage of Perl's unprotected nature to globally redefine the print function or change the Apache::Registry handler function to do something completely different. So again, wide open for exploits, but all on the perl side. None of it related directly to the apache API.

[reply]
[d/l]
        However, you could take advantage of Perl's unprotected nature to globally redefine the print function or change the Apache::Registry handler function to do something completely different.
        Which is exactly what running Apache::Registry scripts under Safe should be able to prevent..

        Makeshifts last the longest.

[reply]
        Not having .htaccess, uh, access would be a pain, but I'll concede that cuts what was apparently my only real potential exploit (the bandwidth throttling thing - it was easy to fix anyway) to shreds. I stand corrected - thanks for straightening me out. My apache configuration/API skillz are degenerating more rapidly than I thought. <sigh> I guess it doesn't matter - apache2 makes them obsolete anyway.
[reply]

In Section Meditations