security with mod_perl
I have a local hosting provider who has mod_perl installed on the server, but will not enable it for security reasons. After doing some digging on the mod_perl site and thinking about how many ways a renegade mod_perl program could bring down a site (large modules using a lot of memory means larger httpd process, consumes memory, hurts performance, etc.). I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. Maybe some way to restrict memory space or something? One problem I see is that Stat::INC would need to be enabled for everything (at least in the clients sandbox). I guess performance-wise, this would still be way better than straight CGI. Thanks for any help. If there is an M out there for this, please tell me to RTF! I looked into some of the sites listed on the mod_perl providers page on perl.apache.org. However, most of these sites are $99+ per month. My lowly non-profit clients can't afford this much $. I'm debating getting a bunch of non-profits together and do a dedicated server, but I'd rather not do that unless I have to. Thanks, Mike Zelina
Re: security with mod_perl
We use BSD::Resource for our mod_perl clients. Keeps them from eating the machine alive. On another shared machine each client gets their own interpreter with some pretty tight limits on child spawning, open children etc. on top of the Resource limits Shared hosting mod_perl is a real drag to do though unless everyone is pretty low traffic. I'm probably not doing it right, its a 'grown' solution for a few clients, not a huge solution engineering for mass hosting. John- On Wed, 11 Jun 2003 09:58:54 -0700 Mike Zelina [EMAIL PROTECTED] wrote: I have a local hosting provider who has mod_perl installed on the server, but will not enable it for security reasons. After doing some digging on the mod_perl site and thinking about how many ways a renegade mod_perl program could bring down a site (large modules using a lot of memory means larger httpd process, consumes memory, hurts performance, etc.). I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. Maybe some way to restrict memory space or something? One problem I see is that Stat::INC would need to be enabled for everything (at least in the clients sandbox). I guess performance-wise, this would still be way better than straight CGI. Thanks for any help. If there is an M out there for this, please tell me to RTF! I looked into some of the sites listed on the mod_perl providers page on perl.apache.org. However, most of these sites are $99+ per month. My lowly non-profit clients can't afford this much $. I'm debating getting a bunch of non-profits together and do a dedicated server, but I'd rather not do that unless I have to. Thanks, Mike Zelina
RE: security with mod_perl
Not quite a manual, but read some of these discussions on PerlMonks: http://www.perlmonks.org/index.pl?node=mod+perl+isp+hostgo_button=Search mod_perl shared hosting ISPs supporting mod_perl mod_perl: the bane of share webhosting Hope this gives you some answers (not a lot of hope, though) -Sidharth. -Original Message- From: Mike Zelina [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 12:59 PM To: [EMAIL PROTECTED] Subject: security with mod_perl I have a local hosting provider who has mod_perl installed on the server, but will not enable it for security reasons. After doing some digging on the mod_perl site and thinking about how many ways a renegade mod_perl program could bring down a site (large modules using a lot of memory means larger httpd process, consumes memory, hurts performance, etc.). I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. Maybe some way to restrict memory space or something? One problem I see is that Stat::INC would need to be enabled for everything (at least in the clients sandbox). I guess performance-wise, this would still be way better than straight CGI. Thanks for any help. If there is an M out there for this, please tell me to RTF! I looked into some of the sites listed on the mod_perl providers page on perl.apache.org. However, most of these sites are $99+ per month. My lowly non-profit clients can't afford this much $. I'm debating getting a bunch of non-profits together and do a dedicated server, but I'd rather not do that unless I have to. Thanks, Mike Zelina
RE: security with mod_perl
On Wed, 2003-06-11 at 18:09, Sidharth Malhotra wrote: Not quite a manual, but read some of these discussions on PerlMonks: http://www.perlmonks.org/index.pl?node=mod+perl+isp+hostgo_button=Search mod_perl shared hosting ISPs supporting mod_perl mod_perl: the bane of share webhosting Hope this gives you some answers (not a lot of hope, though) You can get nice virtual servers from only 15 GBP / month ( probably about the same in merkan money for similar hosting in the US ). Quite why anybody would want shared hosting when you can have a virtual server (usually with ensim and stuff for newbies) for such a low ammount of money. http://www.bytemark-hosting.co.uk do some good deals and discounts for free software author and seem nice people. -- Aaron Trevena, BSc (Hons) --- Software Engineer Tusker Direct :: www.tuskerdirect.com
Re: security with mod_perl
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote: I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. I was just talking about this with my co-workers. Here's one way: Set up a front-end apache with mod_proxy. Have it proxy all requests for /~user (or whatever) to an unprivileged port assigned to that user (or a name-based virtual host). Give each user their own mod_perl on that port/host that they can do what they want with, since it runs as an unprivileged user (themselves). However, it's quite possible that this is more trouble and less value than the virtual server setups people are selling these days. - Perrin
Re: security with mod_perl
Perrin Harkins wrote: On Wed, 2003-06-11 at 12:58, Mike Zelina wrote: I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. I was just talking about this with my co-workers. Here's one way: Set up a front-end apache with mod_proxy. Have it proxy all requests for /~user (or whatever) to an unprivileged port assigned to that user (or a name-based virtual host). Give each user their own mod_perl on that port/host that they can do what they want with, since it runs as an unprivileged user (themselves). You still have a problem to limit available resources. On some platforms BSD::Resource/Apache::Resource can solve this as John has suggested. However, it's quite possible that this is more trouble and less value than the virtual server setups people are selling these days. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: security with mod_perl
Aaron Trevena wrote: [...] http://www.bytemark-hosting.co.uk do some good deals and discounts for free software author and seem nice people. Please submit ISPs that support mod_perl and/or virtual servers. so we can add them to: http://perl.apache.org/help/isps.html I've added the one mentioned above by Aaron. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Security Concern, massive CGI or Headers problems?
I, rather blindly, put a reference to a hash of the HTTP headers and hash of
the CGI params in pnotes for most requests.
Technically, a poorly formed loop might DOS a child if the number of params
or headers is evilly large.
For instance, someone silly could write
my $params = $r-pnotes('params');
foreach my $key_1 (keys %$params) {
foreach my $key_2 (keys %$params) {
next if $key_1 eq $key_2;
warn duplicate message from $key_1 and $key_2 if $params-{$key_1} eq
$params-{$key_2}
}
}
Of course that's silly code, but, looping over the params or headers is
certainly not an impossibility.
Do I need to, should I do any checks before stashing these values in pnotes?
Thx
--
This message is intended only for the personal and confidential use of the designated
recipient(s) named above. If you are not the intended recipient of this message you
are hereby notified that any review, dissemination, distribution or copying of this
message is strictly prohibited. This communication is for information purposes only
and should not be regarded as an offer to sell or as a solicitation of an offer to buy
any financial product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or
error-free. Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such. All information is subject to
change without notice.
Re: Apache::DBI and password security
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of.
Re: Apache::DBI and password security
On Fri, 15 Nov 2002, Rafiq Ismail (ADMIN) wrote: On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by R.
AW: Apache::DBI and password security
Hi, I want to build a database application based on mod_perl and Apache::DBI. The goal of Apache::DBI is to get persistent database connections using only one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? I think, storing it in a file for reading by the script is not the right way (?). Thanks for help! - Wolfgang Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. - Wolfgang
Re: AW: Apache::DBI and password security
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. A thought, although I've never been so secure myself and I'm not sure how secure this would be - but it's one of those silly convoluted ideas you have to tell someone. Since you're using mod_perl and apache_dbi, this is just a thought. Use the Crypt::Blowfish_PP to generate an encrypted password and place it as a variable in a package somewhere. During server startup take a password from the command line, some sort of: Perl Paranoid::CryptDBIPassword::promptForPassword /Perl getliner. Take the value as my $key and: my $bfish = Crypt::Blowfish_PP-new($key) $Apache::PARANOID::dbiPassword = $bfish-decrypt($encryptedPassword); then whenever you want your password you access $Apache::PARANOID::dbiPassword. Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. R.
AW: Apache::DBI and password security
Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. A thought, although I've never been so secure myself and I'm not sure how secure this would be - but it's one of those silly convoluted ideas you have to tell someone. Since you're using mod_perl and apache_dbi, this is just a thought. Use the Crypt::Blowfish_PP to generate an encrypted password and place it as a variable in a package somewhere. During server startup take a password from the command line, some sort of: Perl Paranoid::CryptDBIPassword::promptForPassword /Perl getliner. Take the value as my $key and: =09my $bfish =3D Crypt::Blowfish_PP-new($key) =09$Apache::PARANOID::dbiPassword =09=3D $bfish-decrypt($encryptedPassword); then whenever you want your password you access $Apache::PARANOID::dbiPassword. Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. R. This is an interesting idea. Many thanks to you, Rafiq! - Wolfgang
Re: AW: Apache::DBI and password security
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. This is an interesting idea. Cutting my danglies off? hmm. Sounds painful. Many thanks to you, Rafiq! s'ok, although I wouldn't implement this myself. There are probably nicer ways of being paranoid out there. And just use Crypt::Blowfish if you really want to use Blowfish. :) Good luck. R.
Re: AW: Apache::DBI and password security
On Fri, Nov 15, 2002 at 12:52:13PM +, Rafiq Ismail (ADMIN) wrote: $Apache::PARANOID::dbiPassword = $bfish-decrypt($encryptedPassword); then whenever you want your password you access $Apache::PARANOID::dbiPassword. Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off for that one. Which is why you copied him in the first place? :-) In general, though, there isn't a good way to get any security from any system that has to be able to access sensitive data in an automatic way. MBM -- Matthew Byng-Maddick [EMAIL PROTECTED] http://colondot.net/
Re: AW: Apache::DBI and password security
=?iso-8859-1?Q?=22Fa=DFhauer=2C_Wolfgang=2C_FCI3=22?= [EMAIL PROTECTED] ads.net wrote: Hi, I want to build a database application based on mod_perl and Apache::DBI. The goal of Apache::DBI is to get persistent database connections using only one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? I think, storing it in a file for reading by the script is not the right way (?). Thanks for help! - Wolfgang Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by Yes, that's our plan, too. But the risk still remains that someone will get a look to the script. I think, there is a golden rule: Never put clear text passwords in files. Those files are stored in archives by backup for example. There maybe a lot of people (sysadmin, developer, ...) concerned with the webserver. So it's not easy to secure it. Something we do is put the password in a file outside the document root. The script reads the file. If running with mod_perl, this can be in a file readable only by root read during server startup (assuming the server starts up as root). Then the password can be cached in memory. If it changes, a graceful restart might be sufficiant, but I haven't tried that yet -- most of our current code is PHP that we're are working on replacing. The last time I played with mod_perl and graceful restarts was the early 1.2x or late 1.1x mod_perl and it didn't always work well, iirc. I think some of that has been fixed. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Local file security (in 1.27)
I'm developing an online survey system under mod_perl (with a homemade perlhandler, not under Apache::Registry). Since I've had as a goal to avoid as many dependencies as possible, I store results in local plaintext files. By nature, these files has (?) to be writable by the uid apache runs as. In the mod_perl documentation it is written: When a handler needs write permissions, make sure that only the user, the server is running under, has write permissions to the files. Sometimes you need group write permissions, but be very careful, because a buggy or malicious code run in the server may destroy files writable by the server My files fit this description (the files are chmodded 600). However, as the system is intended for academic use, and it is not entirely uncommon to have one student web server for everything, I cannot force admins not to install (as an example) PHP with default options and allowing the students to write PHP scripts. In PHP, to completely remove all my stored data with one line of code: ? passthru(rm -rf /usr/local/mod_survey/data/*) ? Now, this is obviously a flaw with (in descending order) PHP for not having an installation with a secure default configuration, and with the admins for giving untrusted users access to an inherently insecure scripting language. However, the problem ends up being mine as I have to handle it somehow. So, question is: How do I protect my data files from being accessed by anything else than my own perlhandler? Can I set another uid for all that has to do with my specific perlhandler? Hints are most welcome. // Joel
Re: Local file security (in 1.27)
[...] So, question is: How do I protect my data files from being accessed by anything else than my own perlhandler? Can I set another uid for all that has to do with my specific perlhandler? Hints are most welcome. You can't. The only solution is run a dedicated server for each user. Currently the pure Apache solution is to use suexec, which you cannot run under mod_perl. This is all covered at: http://perl.apache.org/docs/general/multiuser/multiuser.html this issue will be addressed in 2.0 with perchild Apache mpm which allows you to run different groups of servers/threads under different uids/gids. If I remember correctly this mpm is highly experimental at this point. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Local file security (in 1.27)
So, question is: How do I protect my data files from being accessed by
anything else than my own perlhandler? Can I set another uid for all that
has to do with my specific perlhandler? Hints are most welcome.
// Joel
Maybe you are facing the same problem, that I asked earlier in this
list? Question: http://groups.yahoo.com/group/modperl/message/43025
The only solution I came with was to patch mod_perl.c and mod_perl.h
with settings that disable handlers except from httpd.conf. At least I
think these attached patches should do the trick... ;-)
Best wishes, Kari
--- mod_perl.h Thu Jul 18 07:58:54 2002
+++ mod_perl.h.new Thu Jul 18 08:00:48 2002
-768,7 +768,7
#define PERL_DISPATCH_CMD_ENTRY \
PerlDispatchHandler, (crft) perl_cmd_dispatch_handlers, \
NULL, \
-OR_ALL, TAKE1, the Perl Dispatch handler routine name
+RSRC_CONF | ACCESS_CONF, TAKE1, the Perl Dispatch handler routine name
#define PERL_DISPATCH_CREATE(s) s-PerlDispatchHandler = NULL
#else
-875,7 +875,7
#define PERL_AUTHEN_CMD_ENTRY \
PerlAuthenHandler, (crft) perl_cmd_authen_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Authentication handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Authentication handler routine name
#define PERL_AUTHEN_CREATE(s) s-PerlAuthenHandler = PERL_CMD_INIT
#else
-892,7 +892,7
#define PERL_AUTHZ_CMD_ENTRY \
PerlAuthzHandler, (crft) perl_cmd_authz_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Authorization handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Authorization handler routine name
#define PERL_AUTHZ_CREATE(s) s-PerlAuthzHandler = PERL_CMD_INIT
#else
#define PERL_AUTHZ_HOOK NULL
-908,7 +908,7
#define PERL_ACCESS_CMD_ENTRY \
PerlAccessHandler, (crft) perl_cmd_access_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Access handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Access handler routine name
#define PERL_ACCESS_CREATE(s) s-PerlAccessHandler = PERL_CMD_INIT
#else
-927,7 +927,7
#define PERL_TYPE_CMD_ENTRY \
PerlTypeHandler, (crft) perl_cmd_type_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Type check handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Type check handler routine name
#define PERL_TYPE_CREATE(s) s-PerlTypeHandler = PERL_CMD_INIT
#else
-944,7 +944,7
#define PERL_FIXUP_CMD_ENTRY \
PerlFixupHandler, (crft) perl_cmd_fixup_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Fixup handler routine name
+RSRC_CONF, PERL_TAKE, the Perl Fixup handler routine name
#define PERL_FIXUP_CREATE(s) s-PerlFixupHandler = PERL_CMD_INIT
#else
-961,7 +961,7
#define PERL_LOG_CMD_ENTRY \
PerlLogHandler, (crft) perl_cmd_log_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Log handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Log handler routine name
#define PERL_LOG_CREATE(s) s-PerlLogHandler = PERL_CMD_INIT
#else
-978,7 +978,7
#define PERL_CLEANUP_CMD_ENTRY \
PerlCleanupHandler, (crft) perl_cmd_cleanup_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Cleanup handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Cleanup handler routine name
#define PERL_CLEANUP_CREATE(s) s-PerlCleanupHandler = PERL_CMD_INIT
#else
-995,7 +995,7
#define PERL_INIT_CMD_ENTRY \
PerlInitHandler, (crft) perl_cmd_init_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Init handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Init handler routine name
#define PERL_INIT_CREATE(s) s-PerlInitHandler = PERL_CMD_INIT
#else
-1012,7 +1012,7
#define PERL_HEADER_PARSER_CMD_ENTRY \
PerlHeaderParserHandler, (crft) perl_cmd_header_parser_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Header Parser handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Header Parser handler routine name
#define PERL_HEADER_PARSER_CREATE(s) s-PerlHeaderParserHandler = PERL_CMD_INIT
#else
--- mod_perl.c Thu Jul 18 07:58:53 2002
+++ mod_perl.c.new Thu Jul 18 08:00:29 2002
-107,13 +107,13
RSRC_CONF, FLAG, Turn on -w switch },
{ PerlScript, (crft) perl_cmd_require,
NULL,
- OR_ALL, ITERATE, this directive is deprecated, use `PerlRequire' },
+ RSRC_CONF | ACCESS_CONF, ITERATE, this directive is deprecated, use
+`PerlRequire' },
{ PerlRequire, (crft) perl_cmd_require,
NULL,
- OR_ALL, ITERATE, A Perl script name, pulled in via require },
+ RSRC_CONF | ACCESS_CONF, ITERATE, A Perl script name, pulled in via require },
{ PerlModule, (crft) perl_cmd_module,
NULL,
- OR_ALL, ITERATE, List of Perl modules },
+ RSRC_CONF | ACCESS_CONF, ITERATE, List of Perl modules },
{ PerlSetVar, (crft) perl_cmd_var,
NULL,
OR_ALL, TAKE2, Perl config var and value },
-122,19 +122,19
OR_ALL, ITERATE2, Perl config var and value
RE: Doing security for backend applications
Thanks the for info! Where my design was coming from was trying to enforce access control completely outside of application - if a request made it to an application, then the application could be assure that the user was allowed to be there. But I think implementing this would be rather difficult. The solution you suggest is not one I had thought of; I guess letting the application worry about invoking access/authen/authz control is much easier than trying to enforce it at a higher level. All I'll have to do is provide the service (ala Passport) that implements the functionality. Cheers! -klm. -Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 4:18 PM To: Ken Miller Cc: Modperl Subject: Re: Doing security for backend applications On Tue, 4 Jun 2002, Ken Miller wrote: [...] So, php application requests would bounce from the proxy server to the mod perl server to the php server. You could also make it so it's only when requests needs to be authenticated they go to the mod_perl server. Something like having the php server forward authentication requests to the mod_perl server; but support the same cookie format would be relatively simple. This is all related to a single sign-on environment - once the user has signed on an encrypted cookie will contain the application security information used to authorize the user int the various applications. at perl.org we have made it so authentication requests gets forwarded, and then we have an internal interface for the various servers can validate and migrate authentication cookies. You should be able to find documentation on how passport.com does it; if nothing else then on the pages where it's described why their implementation was insecure at some point. ;-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Doing security for backend applications
Let's say I have the following configuration: 1. Front end proxy server (no mod_perl) 2. Back end application server (mod_perl) 3. Back end application server (php) Now, *all* application requests are passed to the mod_perl server (yes, including the php requests). Performing security checks for all the applications on the mod_perl server is easy via a few simple handlers. However, I also want to *transparently* handle high-level application access security for the applications served from the php server using the same perl/db modle I use in the mod perl server. So, php application requests would bounce from the proxy server to the mod perl server to the php server. Is this workable? I currently use mod_rewrite to proxy the requests to the mod_perl server, and I'm assuming I would have to do something similar for the php server. However, I'm not all that sure how to do this, since I don't think mod_rewite will work the way I expect - I need to configure a Location but mod_rewrite doesn't work with Location. Or does it? In case anyone is wondering, I'm working on constructing a dynamic front-end portal that will gate through to various applications, some developed in house, others obtained from third parties - the clients wants to perform a global security check before getting to the application, hence the stuff that I'm creating. This is all related to a single sign-on environment - once the user has signed on an encrypted cookie will contain the application security information used to authorize the user int the various applications. Many thanks! -klm.
Re: Doing security for backend applications
On Tue, 4 Jun 2002, Ken Miller wrote: [...] So, php application requests would bounce from the proxy server to the mod perl server to the php server. You could also make it so it's only when requests needs to be authenticated they go to the mod_perl server. Something like having the php server forward authentication requests to the mod_perl server; but support the same cookie format would be relatively simple. This is all related to a single sign-on environment - once the user has signed on an encrypted cookie will contain the application security information used to authorize the user int the various applications. at perl.org we have made it so authentication requests gets forwarded, and then we have an internal interface for the various servers can validate and migrate authentication cookies. You should be able to find documentation on how passport.com does it; if nothing else then on the pages where it's described why their implementation was insecure at some point. ;-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Security of a modperl enabled site
Hi, I am in front of a security issue. We are running several site using modperl. Last days, a hacker used a script to call some script of our sites for bad purpose. He needed to be authenticated, but we are only using session cookies. Then, once he was loged in, he could retrieve this id and use it in his home made script. This is not the first time this kind of things happends. We use application level security addons to limit the effects. However, I am looking for a tool that could Limit user access by number of requests. I found on the guide Apache::AccessLimitNum, but I can not find it on the cpan, it seems to be discontinuated ... I'am sure i am not the only one to have such problems. How are you, guys, fighting that? Best regards, Fred
Re: Security of a modperl enabled site
I've had people run password guessing scripts and stuff. I've handled it on a case by case basis, ie, limit the number of wrong guesses. There are a bunch of modules that can set limits as well which can come in handy against very brutish sorts of misuses of your site,. I used mod_throttle.c, there is a more flexible perl one or two as well. On Wed, 20 Mar 2002, fred wrote: I'am sure i am not the only one to have such problems. How are you, guys, fighting that? Best regards, Fred
Re: Security of a modperl enabled site
Try this. http://www.snert.com/Software/mod_throttle/ Tor. fred wrote: Hi, I am in front of a security issue. We are running several site using modperl. Last days, a hacker used a script to call some script of our sites for bad purpose. He needed to be authenticated, but we are only using session cookies. Then, once he was loged in, he could retrieve this id and use it in his home made script. This is not the first time this kind of things happends. We use application level security addons to limit the effects. However, I am looking for a tool that could Limit user access by number of requests. I found on the guide Apache::AccessLimitNum, but I can not find it on the cpan, it seems to be discontinuated ... I'am sure i am not the only one to have such problems. How are you, guys, fighting that? Best regards, Fred
Re: Security of a modperl enabled site
I am in front of a security issue. We are running several site using modperl. Last days, a hacker used a script to call some script of our sites for bad purpose. He needed to be authenticated, but we are only using session cookies. Then, once he was loged in, he could retrieve this id and use it in his home made script. Think about what's different between his behavior and legitimate users' behavior. Is it that he's sending tons of requests in a brief period of time? Limit the frequency. Randal wrote a column about how to do this: http://www.stonehenge.com/merlyn/LinuxMag/col17.html - Perrin
RFC: Security/Performance Best Practices (long)
Recently, I've been using Apache::ASP to program a new version of an
existing website that gets over 5 million page views per month. This
website will have to fit on a RaQ4i (450MHz) server, so I'm pretty
conscious about performance. Security is also important due to the
popularity of the site.
I've read various documentation and combined them together into the
following strategy for security and performance on a mod_perl driven
website. I haven't seen these combined strategies formally written up
anywhere, so I thought I would try to do that and ask you guys for
suggestions. This is a bit unorganized right now, but all the general
concepts should be there. The goal is to produce a document that
explains all the principles, and shows all the configuration
directives required to accomplish this.
This website runs off a MySQL database. Although all the webpages are
generated dynamically, they don't change often (unless the webmaster
explicitly updates them).
I setup a lightweight frontend httpd (port 80) that proxies to a
heavyweight mod_perl backend httpd (port 8001). mod_gzip is installed
on the frontend to deliver compressed HTML pages for faster download
time. mod_proxy_add_forward is also installed so that the backend logs
the true IP address of the request in its logs.
In my account, I have these directories:
httpd: apachectl, httpd.conf, logs for the mod_perl httpd
perl: DocumentRoot for backend httpd
web: DocumentRoot for frontend httpd
global: contains *.pm, startup.pl, global.asa (for Apache::ASP)
The proxying is configured in the frontend httpd.conf as follows:
1: RewriteEngine On
2: RewriteRule ^/(.+)\.asp$ http://127.0.0.1:8001/$1.asp [L,P]
3: RewriteRule ^/(.+)\.pl$ http://127.0.0.1:8001/$1.pl [L,P]
4: RewriteCond /home/aw/perl%{REQUEST_URI}index.asp -f
5: RewriteRule ^(.*)/$ http://127.0.0.1:8001$1/ [L,P]
Line 2 passes any URL with a .asp extension to the backend.
Line 3 passes any URL with a .pl extension to the backend.
Line 4,5 passes any request for a directory to the backend, if there
is an index.asp file in that directory.
Notice that to the outside world, the hostname/port of the website is
exactly the same whether it's being served by the frontend or
backend. I prefer this approach since it lets my img src tags refer
to images in the same directory, for example. It also doesn't require
an extra DNS lookup on the client end (which it would if the mod_perl
server and non-mod_perl server were on different hostnames).
I don't have a ProxyPassReverse directive since I haven't thought
about it; I wouldn't need it anyway since I don't do any redirecting
(at least not right now), but I'll probably end up adding it just in
case.
The following users were created on the system:
aw: I login as this user. Group = aw, httpd
aw_guest: mod_perl httpd runs as this user. Group = aw
httpd: lightweight httpd runs as this user. Group = httpd
aw owns all of the files except httpd/logs.
The web directory is world readable. It only contains images that
everyone can get from the web server anyway.
The httpd and global directories are group readable, so only aw
and aw_guest can read it. perl is world readable, but the files
inside are only group readable (this allows the httpd user to tell
what files exist, but nothing more). This protects my source code
(and the database passwords they contain!) from being browsed by
others.
So that I won't accidentally create world readable files, I have this
line in ~/.profile for aw:
umask 027
This creates files as rw-r- by default. Files I upload by FTP
still default to mode rw-r--r--, but I only upload image files that
way (I use vi through ssh to edit the code) so that's perfect.
There is a level of isolation here; in case I write an insecure script
that gets hacked, the hacker will only gain access to the aw_guest
account. The aw_guest account can read all my site's files, but it
can't write to any of them. Also, the MySQL username/password used by
the website has read-only access to the database.
Apache::ASP is set so that every page has headers indicating that it
can be cached for up to one hour:
$Response-AddHeader('Last-Modified', time2str(time));
$Response-{CacheControl} = 'public';
$Response-{Expires} = 3600;
I could have set the expiry time higher, but I decided to put it at
3600 so that in case I change content on the website and forget to
manually clear the cache, it won't be out of date by more than 1
hour. In terms of performance issues, 1 hour should be long enough
such that the backend httpd server doesn't have to do too much work.
In my frontend httpd server, I have a basic cache configuration:
ProxyRequests on
CacheRoot /home/httpd/cache
CacheSize 1 # cache size of 10 MB
CacheGcInterval 1 # clean up the cache every hour
CacheMaxExpire 24 # nothing lives in the cache for 24 hours
CacheDefaultExpire 1 # default expiry time is 1 hour
I can force the frontend httpd server to reload a specific page from
the backend
Re: RFC: Security/Performance Best Practices (long)
Philip Mak: This website runs off a MySQL database. Although all the webpages are generated dynamically, they don't change often (unless the webmaster explicitly updates them). Do you generate reliable Last-Modified and Expires headers? This could help bandwidth usage for you and your users. -- Alessio F. Bragadini[EMAIL PROTECTED]
Re: RFC: Security/Performance Best Practices (long)
Philip Mak wrote: Recently, I've been using Apache::ASP to program a new version of an existing website that gets over 5 million page views per month. This website will have to fit on a RaQ4i (450MHz) server, so I'm pretty conscious about performance. Security is also important due to the popularity of the site. I've read various documentation and combined them together into the following strategy for security and performance on a mod_perl driven website. I haven't seen these combined strategies formally written up anywhere, so I thought I would try to do that and ask you guys for suggestions. This is a bit unorganized right now, but all the general concepts should be there. The goal is to produce a document that explains all the principles, and shows all the configuration directives required to accomplish this. I'm afraid there is no such a thing as a single detailed performance scenario fitting all users of mod_perl, I'd even say even a big chunk of users. Each user has a different hw, different requirements, different amount of $$, in-house knowledge and what not. So IMHO it'd be a mistake to even try to write an ultimate performance document. Hmm, may be such a thing could exist in winXX world, I don't know. You're heartly welcome to help to improve the existing documentation, which already sports I think about 200 printed pages of various scenarious, tips and tricks which comprise a Lego-like set for everybody to learn from and build their own bridge, their own monster and their own crane, using common components. Please don't create another documentation fork, unless you really have to, since it's so much easier for people to read all the docs from one place, rather than jumping between many scattered docs and of course avoid efforts duplication. Quite a few people have complained to me that while the mod_perl guide includes a lot of performance improvement techniques, it doesn't help newbies to make the right choice in first place. So they have to try a few of them first, before making the right choice. So if that's what you think is missing you are welcome to try to fill the gap, but personally I doubt it's possible for the reasons I've mentioned above and many other reasons. I just want to repeat that any attempt to improve the existing documentation and add new docs is very welcome and the 2.0 documentation project is going be the next cool thing if enough people will get involved and give help. You can check the modperl-docs cvs repository to see what's there so far. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: modperl security model question
darren chamberlain wrote:
Be sure to check that $line is defined:
Even better:
perl
use IO::File;
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
my $line = $input-getline() || 'some safe default value, like
""';
die "\$line is not defined" unless (defined $line); # -- Now not really needed
print STDERR $line;
$input-close();
# $line = 'bar';
$Location{'/areaj'} = {
PerlSetVar = [
[foo = $line]
],
SetHandler = 'perl-script',
PerlHandler = 'AreaJ::AreaJ'
}
#push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
/perl
Issac
--
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: modperl security model question
Hi all,
On Mon, 16 Apr 2001, darren chamberlain wrote:
Thomas K. Burkholder ([EMAIL PROTECTED]) said
[snip]
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
Probably doesn't matter in this case, but I'd try to get used to using
the "or" operator instead of the C-style double pipe in this kind of
construct. It has a much lower precedence so it can cause you less
pain. (Camel book, p94). Also I'd use Symbol::gensym (Camel Book,
p502 and the Guide at http://perl.apache.org/guide). It can help to
include the system error string (from the Perl special variable $!) in
the error message which you print after a failed system call so in this
case you'd be a lot wiser after the event (permissions, disc full...:).
73,
Ged.
Re: modperl security model question
Hmm... There might be another solution, but it's probably a bit dangerous - and in any case, one of the more experianced mod_perl people would have to confirm that it works as expected... But it would seem to me that if you can figure out at an early enough stage who you want to run the process as, you could set Apache to run as root:root and then use a ChildInitHandler (or any early stage handler) to do a setuid and setgid. Since perl is part of the child process, this should change the uid gid of the entire process. This would seem slightly better then the below alternative as you can set MaxRequestsPerChild to 1 and just have one parent process spawning children with different uid/gids, instead of having to start up an entire server for each uid/gid pair... Of course, there's the security problem of everything that happens in the child until it gets to the setuid AND it's very important to make sure that there's a default uid/gid pair for the process to put on to prevent any sort of bypass. I don't know that I'd pick this solution without mulling it over for a few days, but maybe people on the list can think up some of the pro's and con's for me :) Issac (PS. Yes I know it's a dangerous approach, so you don't all have to personally bash me over the head with it ;-) ) Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "sterling" [EMAIL PROTECTED] To: "Thomas K. Burkholder" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, April 15, 2001 6:06 PM Subject: Re: modperl security model question On Sun, 15 Apr 2001, Thomas K. Burkholder wrote: Thanks again for the help - I have another one- My application consists of perl modules with file permissions set only to a particular user 'burkhold'. The database password is kept in plaintext in one of those modules. I use the User: and Group: directives in access.conf to cause the uid of the spawned httpd process to have permission to execute the code. It works fine, except that it seems I can't embed 'User: burkhold' inside a Location directive, so all requests have to be served as 'burkhold'. It seems like there should be some simple way in apache to specify what user the httpd should be set to when it's spawned, but except for the global User: I haven't found a way. An httpd process is spawned to handle _all_ locations, that is why the Group/User can only be specified per server. If apache was able to spawn separate processes to only handle one location, your suggestion would work. The only solution i would offer would be to proxy all requests to that location to another apache server, running on a different port, as user bukhold. The main server could then run with whatever user is appropriate, and have a ProxyPass directive to forward requests requiring user burkhold. sterling If I can't make this work, I may have to turf module handlers and go with a Registry and setuid solution, which I think would be a shame since I think handlers are a lot more elegant. This is probably well-trodden territory - anyone got a solution? Thanks again, several of you have been helpful to me, and I do appreciate it. Happy Easter. file://Thomas Thomas K. Burkholder [EMAIL PROTECTED]
Re: modperl security model question
Actually, what I'm trying to do now is, in access.conf:
Note, /tmp/tmppswd is read-only by the installer of the product, but I should
be root in access.conf (right?) so I should be able to read it anyway.
perl
use IO::File;
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open
/tmp/foo.pl";
my $line = $input-getline();
print STDERR $line;
$input-close();
# $line = 'bar';
$Location{'/areaj'} = {
PerlSetVar = [
[foo = $line]
],
SetHandler = 'perl-script',
PerlHandler = 'AreaJ::AreaJ'
}
#push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
/perl
Now I get an error:
[Mon Apr 16 15:43:32 2001] [error] Perl: PerlSetVar takes two arguments, Perl
config var and value
... because $line is somehow being evaluated to 0. If I uncomment the first
commented line, it works, leading me to believe that somehow the values inside
PerlSetVar have to be constants of some sort. Commenting out the PerlSetVar
part and uncommenting the push line just gives me 404 (doesn't even print out
my STDERR statement earlier in the routine, I really don't get that).
I'm obviously being a bonehead. Can anyone help?
Thanks,
//Thomas
Issac Goldstand wrote:
Hmm... There might be another solution, but it's probably a bit dangerous -
and in any case, one of the more experianced mod_perl people would have to
confirm that it works as expected...
But it would seem to me that if you can figure out at an early enough stage
who you want to run the process as, you could set Apache to run as root:root
and then use a ChildInitHandler (or any early stage handler) to do a setuid
and setgid. Since perl is part of the child process, this should change the
uid gid of the entire process. This would seem slightly better then the
below alternative as you can set MaxRequestsPerChild to 1 and just have one
parent process spawning children with different uid/gids, instead of having
to start up an entire server for each uid/gid pair... Of course, there's
the security problem of everything that happens in the child until it gets
to the setuid AND it's very important to make sure that there's a default
uid/gid pair for the process to put on to prevent any sort of bypass. I
don't know that I'd pick this solution without mulling it over for a few
days, but maybe people on the list can think up some of the pro's and con's
for me :)
Issac
(PS. Yes I know it's a dangerous approach, so you don't all have to
personally bash me over the head with it ;-) )
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
- Original Message -
From: "sterling" [EMAIL PROTECTED]
To: "Thomas K. Burkholder" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, April 15, 2001 6:06 PM
Subject: Re: modperl security model question
On Sun, 15 Apr 2001, Thomas K. Burkholder wrote:
Thanks again for the help - I have another one-
My application consists of perl modules with file permissions set only
to a particular user 'burkhold'. The database password is kept in
plaintext in one of those modules. I use the User: and Group:
directives in access.conf to cause the uid of the spawned httpd process
to have permission to execute the code. It works fine, except that it
seems I can't embed 'User: burkhold' inside a Location directive, so
all requests have to be served as 'burkhold'. It seems like there
should be some simple way in apache to specify what user the httpd
should be set to when it's spawned, but except for the global User: I
haven't found a way.
An httpd process is spawned to handle _all_ locations, that is why the
Group/User can only be specified per server. If apache was able to spawn
separate processes to only handle one location, your suggestion would
work.
The only solution i would offer would be to proxy all requests to
that location to another apache server, running on a different port,
as user bukhold. The main server could then run with whatever user is
appropriate, and have a ProxyPass directive to forward requests requiring
user burkhold.
sterling
If I can't make this work, I may have to turf module handlers and go
with a Registry and setuid solution, which I think would be a shame
since I think handlers are a lot more elegant.
This is probably well-trodden territory - anyone got a solution?
Thanks again, several of you have been helpful to me, and I do
appreciate it.
Happy Easter.
file://Thomas
Thomas K. Burkholder
[EMAIL PROTECTED]
Re: modperl security model question
Be sure to check that $line is defined:
Thomas K. Burkholder ([EMAIL PROTECTED]) said something to this effect on
04/16/2001:
Note, /tmp/tmppswd is read-only by the installer of the product, but I should
be root in access.conf (right?) so I should be able to read it anyway.
perl
use IO::File;
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
my $line = $input-getline();
die "\$line is not defined" unless (defined $line);
print STDERR $line;
$input-close();
# $line = 'bar';
$Location{'/areaj'} = {
PerlSetVar = [
[foo = $line]
],
SetHandler = 'perl-script',
PerlHandler = 'AreaJ::AreaJ'
}
#push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
/perl
(darren)
--
The three most dangerous things are a programmer with a soldering iron,
a manager who codes, and a user who gets ideas.
Mea Culpa [Was: Re: modperl security model question]
It's defined all right, it gets printed to STDERR.
The problem was that the file I was actually using was a perl file '/tmp/foo.pl', just
because it didn't matter what was in the file while I tried to make it work. But,
wait, it
does matter, because the first thing in the file was "use Data::Dump;". Apparently,
some
translation that goes on in there turns that string into an execution of it (or
something).
It's probably a bug if anyone cares - just use the same example I gave but make sure
the
first two lines are "use Data::Dump;" and it should reproduce.
Or am I missing something? Is there a perfectly logical reason why having the $line
variable
contain "use Data::Dump;" should result in $line being evaluated to undef a few lines
later?
Thanks to those who helped.
//T
darren chamberlain wrote:
Be sure to check that $line is defined:
Thomas K. Burkholder ([EMAIL PROTECTED]) said something to this effect on
04/16/2001:
Note, /tmp/tmppswd is read-only by the installer of the product, but I should
be root in access.conf (right?) so I should be able to read it anyway.
perl
use IO::File;
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
my $line = $input-getline();
die "\$line is not defined" unless (defined $line);
print STDERR $line;
$input-close();
# $line = 'bar';
$Location{'/areaj'} = {
PerlSetVar = [
[foo = $line]
],
SetHandler = 'perl-script',
PerlHandler = 'AreaJ::AreaJ'
}
#push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
/perl
(darren)
--
The three most dangerous things are a programmer with a soldering iron,
a manager who codes, and a user who gets ideas.
modperl security model question
Thanks again for the help - I have another one- My application consists of perl modules with file permissions set only to a particular user 'burkhold'. The database password is kept in plaintext in one of those modules. I use the User: and Group: directives in access.conf to cause the uid of the spawned httpd process to have permission to execute the code. It works fine, except that it seems I can't embed 'User: burkhold' inside a Location directive, so all requests have to be served as 'burkhold'. It seems like there should be some simple way in apache to specify what user the httpd should be set to when it's spawned, but except for the global User: I haven't found a way. If I can't make this work, I may have to turf module handlers and go with a Registry and setuid solution, which I think would be a shame since I think handlers are a lot more elegant. This is probably well-trodden territory - anyone got a solution? Thanks again, several of you have been helpful to me, and I do appreciate it. Happy Easter. //Thomas Thomas K. Burkholder [EMAIL PROTECTED]
Re: modperl security model question
On Sun, 15 Apr 2001, Thomas K. Burkholder wrote: Thanks again for the help - I have another one- My application consists of perl modules with file permissions set only to a particular user 'burkhold'. The database password is kept in plaintext in one of those modules. I use the User: and Group: directives in access.conf to cause the uid of the spawned httpd process to have permission to execute the code. It works fine, except that it seems I can't embed 'User: burkhold' inside a Location directive, so all requests have to be served as 'burkhold'. It seems like there should be some simple way in apache to specify what user the httpd should be set to when it's spawned, but except for the global User: I haven't found a way. An httpd process is spawned to handle _all_ locations, that is why the Group/User can only be specified per server. If apache was able to spawn separate processes to only handle one location, your suggestion would work. The only solution i would offer would be to proxy all requests to that location to another apache server, running on a different port, as user bukhold. The main server could then run with whatever user is appropriate, and have a ProxyPass directive to forward requests requiring user burkhold. sterling If I can't make this work, I may have to turf module handlers and go with a Registry and setuid solution, which I think would be a shame since I think handlers are a lot more elegant. This is probably well-trodden territory - anyone got a solution? Thanks again, several of you have been helpful to me, and I do appreciate it. Happy Easter. //Thomas Thomas K. Burkholder [EMAIL PROTECTED]
bug in exploder blows up Digest security
anyone know of a way around this? i have a site that depends heavily on anchors for delivering reports. exploder chops off the uri at the arguments, which is not what mod_auth_digest (nor RFC 2617) expect. anyone know of a way to force exploder to use the full uri for the digest authorization header? rewrite doesn't seem likely to help since the hash was generated with the wrong value of the uri to begin with. thanx. GET /tdrdw/Data?menuform=1report=lookup=report=sar_min_esnlookup=99all=0 HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/pdf, */* Accept-Encoding: gzip, deflate Accept-Language: en-us Authorization: Digest username="paul", realm="TDRDW", qop="auth", algorithm="MD5", uri="/tdrdw/Data", nonce="OsOuHA==3be36661a184a9851d9263409b407031c9fc8 928", nc=0007, cnonce="456ac2f6e01485024bbb49b3652923dc", response="3f9fe67dfe9188da6a358520d41e1dbe" Connection: Keep-Alive Host: alpha:8082 Referer: http://alpha:8082/tdrdw/Menu User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) HTTP/1.1 (null) [Thu Mar 29 15:54:58 2001] [error] [client 10.35.2.5] Digest: uri mismatch - /tdrdw/Data does not match request-uri /tdrdw/Data?menuform=1report=lo -- Steven Lembark 2930 W. Palmer St. Chicago, IL 60647 [EMAIL PROTECTED] 800-762-1582
RE: security!
On Thu, 1 Mar 2001, [EMAIL PROTECTED] wrote: I used to believe that too, but now that I've developed applications that make rather extensive use of the Apache API, I would actually love to have an environment similar to CGI but providing the full Apache API, including logging, notes/pnotes, etc. How would it be similar to CGI then? I'm guessing you want to be able to register a separate program to handle any part of the request phase? Similar to CGI in that it would fork a process (and hence we could use suexec or whatever mechanism to suid). And yes, we should be able to register it in whatever request phase. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
[OT] Re: security!
Matt Sergeant ([EMAIL PROTECTED]) said something to this effect on 03/02/2001:
...now that I've developed applications that make rather extensive
use of the Apache API, I would actually love to have an environment
similar to CGI but providing the full Apache API, including logging,
notes/pnotes, etc. I realise a lot of this would be tricky and would
require RPC (thus opening up a security hole in its own right) but
I think it would be worthwhile.
This is off-topic, pretty much, but interesting nonetheless.
I just stumbled across Apache DSSI URL:http://apache_dssi.tripod.com/,
which seems to allow for that. I haven't tried it out, or even
looked at the code yet, but the author apparently considers it
1.0 verion code.
Here is the summary from the page:
By using this extentions to mod_include, you can make your own
function for SSI (Server Side Includes) and you can call your
function with SSI directives. This solution is based on mod_so
and mod_include. By using DSSI, you can integrate your CGI easily
and make your CGI faster than any other CGI accelerator.
The example the author gives pretty much sums it up (this is a
little long, sorry):
temp_dssi.c:
#include "httpd.h"
#include "http_config.h"
#include "http_request.h"
#include "http_core.h"
#include "http_protocol.h"
#include "http_log.h"
#include "http_main.h"
#include "util_script.h"
#include "util_date.h"
int temp_dssi(request_rec *r, char *args)
{
const char *s;
s = ap_table_get(r-subprocess_env,"QUERY_STRING");
if(s *s)
ap_rprintf(r,"%s\n",s);
if(args *args)
ap_rprintf(r,"%s\n",args);
return OK;
}
Compiling:
$ gcc -c -I/apache_root_dir/include -O2 temp_dssi.c
$ gcc -I/apache_root_dir/include -O2 temp_dssi.o -shared -o
temp_dssi.so
$ cp temp_dssi.so /apache_root_dir/libexec/
httpd.conf:
LoadDSSI libexec/temp_dssi.so
temp_dssi.shtml:
htmlbodypre
!--#exec func="temp_dssi $DOCUMENT_ROOT" --
/pre/body/html
(darren)
--
If NT is your answer, you don't understand the question.
Re: security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 9:44 AM +0800 3/1/01, Stas Bekman wrote: At this moment anybody who has an access to mod_perl server can read any data which is accessible by the same server. suexec is not an option because of process persistance. I suspect this is why it is very easy to find hosting providers who provide PHP, and not as easy to find providers who support Embperl, Mason or other mod_perl solutions. Is there any effort to deal with this? (Per-virtual-server-process-sharing, with the option of dropping to zero processes, seems like a good start.) I'd really like to see languages like Embperl stand a better chance going head-to-head against PHP. It's very annoying to be able to whip together a great solution for my own servers, only to have to implement it for one of my clients in PHP, without nearly the power that Perl gives me. - -- Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBOp4JiyZsPfdw+r2CEQJoRACgmZsE3GpeM2AhH2ooYID9iDxlnwAAmwf8 +sZ0r0rmQNuahRV07TpZ761e =BSof -END PGP SIGNATURE-
Re: security
mod_perl 2.0 At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 9:44 AM +0800 3/1/01, Stas Bekman wrote: At this moment anybody who has an access to mod_perl server can read any data which is accessible by the same server. suexec is not an option because of process persistance. I suspect this is why it is very easy to find hosting providers who provide PHP, and not as easy to find providers who support Embperl, Mason or other mod_perl solutions. Is there any effort to deal with this? (Per-virtual-server-process-sharing, with the option of dropping to zero processes, seems like a good start.) I'd really like to see languages like Embperl stand a better chance going head-to-head against PHP. It's very annoying to be able to whip together a great solution for my own servers, only to have to implement it for one of my clients in PHP, without nearly the power that Perl gives me. - -- Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBOp4JiyZsPfdw+r2CEQJoRACgmZsE3GpeM2AhH2ooYID9iDxlnwAAmwf8 +sZ0r0rmQNuahRV07TpZ761e =BSof -END PGP SIGNATURE- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: security
On Thu, 1 Mar 2001, Gunther Birznieks wrote: mod_perl 2.0 At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 9:44 AM +0800 3/1/01, Stas Bekman wrote: At this moment anybody who has an access to mod_perl server can read any data which is accessible by the same server. suexec is not an option because of process persistance. I suspect this is why it is very easy to find hosting providers who provide PHP, and not as easy to find providers who support Embperl, Mason or other mod_perl solutions. Is there any effort to deal with this? (Per-virtual-server-process-sharing, with the option of dropping to zero processes, seems like a good start.) I'd really like to see languages like Embperl stand a better chance going head-to-head against PHP. It's very annoying to be able to whip together a great solution for my own servers, only to have to implement it for one of my clients in PHP, without nearly the power that Perl gives me. See http://perl.apache.org/~dougm/modperl_2.0.html _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: security
Probably a stupid question, but wouldn't named virtuals solve this problem? I'm not all that familiar with MySQL, but we have a similar set up here with slightly different technology - Solaris, Netscape Enterprise Server, and Oracle. I should think that you could replicate this using BSD, Apache, and MySQL, but please don't quote me on that. Then again, we authenticate via LDAP and some of our other parameters vary from what you have as well. Thanks, Stas Bekman wrote: On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho Rios wrote: Hi folks! I have a FreeBSD server configured as a http server, running apache. This installation includes mod_perl+EmbPerl, mod_php4 mod_cgi and mod_fastcgi. Some of my users will be using mysql for database. The problem is that this scenario requires sensitive information inside file. This means no problem when these users write their dymanic pages inside a compiled program. I can chmod a-rw and nobody will be able to take away user/password from a compiled program. The problem happens when write their php or embperl pages! the key user\password are kept inside this file, so anyone can uses an editor to retrieve the user mysql account. I resolve this problem running php on secure mode and chgrping the php file the same user as the http process and removing other flags file access (g-rwx). So nobody besides the owner of the file (or the http process) will be able to read it. since php have some security facilities, like: if the file owner id != the file the script is trying to open = fails. My problem is with perl: how to solve such a problem in a perl environment? Does mod perl allows any kind of security, to prevent ones writing script to read others files? PS: All cgi runs through suexec, so even cgi are not able to run the script, ok? At this moment anybody who has an access to mod_perl server can read any data which is accessible by the same server. suexec is not an option because of process persistance. I understand that you want to store the SQL engine authentication info, and users not to know each other's access credentials. The only solution at this point is to either trust your users not to abuse each other, or run a separate server for each one :( _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ -- Jimi Thompson "It's the same thing we do every night, Pinky."
security!
After some time playing with modperl, i realized some problem (that's the way i call them) related with modperl! By looking the way modperl works today, it's clearly it were not desgined to SECURELY support a multi-user environment. For instance: Any user can write a script that will be able to read any file owned by the httpd server, in a multi-user environment it should not be allowed. A gentle way to prevent this would be not to allow a script read a file whose owner id is not the same from the script owner id, isn't it? Another problem: process creation should be wrapped by apache suexec mechanism, is it currently done this way? Why not? May some here confirm me that if i am a security concious admin, i should not make modperl+embperl available to my user?
Re: security!
Take a look at http://www.freevsd.org. I haven't used it personally, but it looks like something that you need.. This system is a based on making a chroot environment for each user with his own apache and everything. Gustavo Vieira Goncalves Coelho Rios wrote about "security!": After some time playing with modperl, i realized some problem (that's the way i call them) related with modperl! By looking the way modperl works today, it's clearly it were not desgined to SECURELY support a multi-user environment. For instance: Any user can write a script that will be able to read any file owned by the httpd server, in a multi-user environment it should not be allowed. A gentle way to prevent this would be not to allow a script read a file whose owner id is not the same from the script owner id, isn't it? Another problem: process creation should be wrapped by apache suexec mechanism, is it currently done this way? Why not? May some here confirm me that if i am a security concious admin, i should not make modperl+embperl available to my user? -- Best Regards Vladimir Ivaschenko RedHat Certified Linux Engineer (RHCE)
Re: security!
Vladimir Ivaschenko wrote: Take a look at http://www.freevsd.org. I haven't used it personally, but it looks like something that you need.. This system is a based on making a chroot environment for each user with his own apache and everything. i can vouch for this approach to development weve been using it in house for 3 months its so nice multiple developers on one box!!
Re: security
Stas Bekman wrote:
On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho
Rios wrote:
the key user\password are kept inside this file, so
anyone can uses an
editor to retrieve the user mysql account. I resolve
this problem
running php on secure mode and chgrping the php file
the same user as
the http process and removing other flags file access
(g-rwx). So nobody
besides the owner of the file (or the http process)
will be able to read
it.
At this moment anybody who has an access to mod_perl
server can read any
data which is accessible by the same server. suexec is
not an option
because of process persistance.
I understand that you want to store the SQL engine
authentication info,
and users not to know each other's access credentials.
The only solution
at this point is to either trust your users not to abuse
each other, or
run a separate server for each one :(
There is a distinct possibility that I don't understand the
problem, but couldn't you set up a db connection sub in a
file, -750 customer.nobody, like this:
sub connect {
my $r = shift; # we need a request object from somewhere
return undef unless $r-server_name eq
'www.thisvirtualhost.org';
my $db_user = 'user';
my $db_pass = 'pass';
my $db_name = 'name';
use DBI;
my $dbh=DBI-connect(mumblemumblemumble);
return $dbh;
}
You might want to think about another way of doing your
connections, anyway. If you have lots of virtual hosts,
and all of them are opening distinct connections, you're
going to run out of MySQL handles pretty quick, or choke
your server with Apache::DBI cached handles. I've heard
that you can use a single connection module which then
changes to use a specified database, but I've never tried
that myself.
Todd
Re: [OT] security!
Hello, GRBy looking the way modperl works today, it's clearly it were not GRdesgined to SECURELY support a multi-user environment. For instance: Any GRuser can write a script that will be able to read any file owned by the GRhttpd server, in a multi-user environment it should not be allowed. This is a general Unix webserver issue and not specific to mod_perl, so I've marked your message [OT] for off-topic. You cannot easily avoid this problem in general. (1) HTTP requests can come from anybody. (2) All HTTP requests are serviced by the same webserver. (3) The webserver needs to be able to read and execute scripts. Therefore, in general if untrusted users can write webserver executed scripts, they can read anything the webserver can. GRA gentle way to prevent this would be not to allow a script read a file GRwhose owner id is not the same from the script owner id, isn't it? This is fine, but you're talking about revamping Unix permissions here, not at the webserver level. The webserver cannot enforce this condition because the webserver only runs the script, it is not the OS that the script runs on. GRAnother problem: process creation should be wrapped by apache suexec GRmechanism, is it currently done this way? Why not? This could help sidestep the issue. It is not done this way by default, because even using suexec doesn't automatically make your scripts secure, and in fact it can make the situation worse. GRMay some here confirm me that if i am a security concious admin, i GRshould not make modperl+embperl available to my user? If you are a security conscious admin, and you cannot trust your users, you should not make mod_perl available to them. In fact you should not make any dynamic HTTP functionality available to them--CGI, ISAPI, FastCGI, or anything else. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
RE: security!
This is a general Unix webserver issue and not specific to mod_perl, so I've marked your message [OT] for off-topic. Well, workarounds are available for specific webserver environments, so I don't believe it's an inappropriate question. With CGI, you use the suexec mechanism to start executable programs as a particular user. AFAIK you can't impersonate a user on unixy environments without forking a new process. And forking a new process under mod_perl really defeats the purpose. Plus, because it is easy to crash or stall a server running mod_perl, each mod_perl user really needs administrative access to his or her own web server, including the ability to stop and start it. One method (as people have noted) is to create a number of complete virtual chrooted unix environments, each with its own webserver. Another is to have pools of httpds: each pool running as a different user and listening to a unique port; then you run a proxying front-end to direct traffic to each user's server based on hostname or whatever. Complicated, and (I believe) quite memory-intensive. More info is in the guide: http://perl.apache.org/guide/multiuser.html#ISPs_providing_mod_perl_services In mod_perl 2.0 (when it is released) you will have the opportunity (depending on your platform) to use the hybrid process/threading model. Then you will have a single httpd for each user, and that httpd will be able to handle multiple requests via multiple threads. This solution could probably be used in an ISP, to achieve the same level of user-partitioning that is now availble under CGI via suexec. Michael
RE: security!
On Thu, 1 Mar 2001, [EMAIL PROTECTED] wrote: This is a general Unix webserver issue and not specific to mod_perl, so I've marked your message [OT] for off-topic. Well, workarounds are available for specific webserver environments, so I don't believe it's an inappropriate question. With CGI, you use the suexec mechanism to start executable programs as a particular user. AFAIK you can't impersonate a user on unixy environments without forking a new process. And forking a new process under mod_perl really defeats the purpose. Does it? I used to believe that too, but now that I've developed applications that make rather extensive use of the Apache API, I would actually love to have an environment similar to CGI but providing the full Apache API, including logging, notes/pnotes, etc. I realise a lot of this would be tricky and would require RPC (thus opening up a security hole in its own right) but I think it would be worthwhile. I certainly don't like the way we're all assuming mod_perl 2.0 is going to solve all our problems. It won't. It will just give us some fresh ones (like making all modules thread safe). -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
(changing userids/2.0/suexec) was: RE: security!
This is a general Unix webserver issue and not specific to mod_perl, so I've marked your message [OT] for off-topic. Well, workarounds are available for specific webserver environments, so I don't believe it's an inappropriate question. With CGI, you use the suexec mechanism to start executable programs as a particular user. AFAIK you can't impersonate a user on unixy environments without forking a new process. And forking a new process under mod_perl really defeats the purpose. changing userids has nothing to do with fork()... the problem is simply that it requires root priviledges, and since you need to give them up permanently if you're going to run some else's "insecure" code, that usually means a temporary process... (which typically means fork()ing a short lived process, so you could make the connection)... The apache 2.0 model seems to include a mechanism for routing requests to a group of apache child processes which have _already_ switched to the target userid... in short, the pre-fork model is extended to have classes of pre-forked processes... it seems to be a mightly good fix for this particular problem. That said, I only took about two minutes reading one of the URLs posted earlier today, but I got that far and said "that'll work!" and quit reading until I have time to actually test some of this ... -Tom
RE: security!
And forking a new process under mod_perl really defeats the purpose. Does it? Well I confess I just assumed. I used to believe that too, but now that I've developed applications that make rather extensive use of the Apache API, I would actually love to have an environment similar to CGI but providing the full Apache API, including logging, notes/pnotes, etc. How would it be similar to CGI then? I'm guessing you want to be able to register a separate program to handle any part of the request phase? I certainly don't like the way we're all assuming mod_perl 2.0 is going to solve all our problems. It won't. Well, personally, I use my own servers when I use mod_perl, so this particular problem doesn't affect me. But I think that finding a good ISP-friendly mod_perl solution would be good in general to help promote Perl as a viable modern web programming language. I think that promoting perl as a *modern* web programming language would be good for the perl community because it would encourage more people to use modern programming practices (strict mode, OO etc.) rather than the quick one-offs of yore that were so popular with CGI. Not that there's anything wrong with that of course. I know some people who run a small ISP and they would probably consider offering a mod_perl service, if they could put a bunch of users on a box and protect the users from each other reasonably well. Of course, mod_perl is not the only way to promote Perl on the web, but this is a mod_perl list :) Michael
security
Hi folks! I have a FreeBSD server configured as a http server, running apache. This installation includes mod_perl+EmbPerl, mod_php4 mod_cgi and mod_fastcgi. Some of my users will be using mysql for database. The problem is that this scenario requires sensitive information inside file. This means no problem when these users write their dymanic pages inside a compiled program. I can chmod a-rw and nobody will be able to take away user/password from a compiled program. The problem happens when write their php or embperl pages! the key user\password are kept inside this file, so anyone can uses an editor to retrieve the user mysql account. I resolve this problem running php on secure mode and chgrping the php file the same user as the http process and removing other flags file access (g-rwx). So nobody besides the owner of the file (or the http process) will be able to read it. since php have some security facilities, like: if the file owner id != the file the script is trying to open = fails. My problem is with perl: how to solve such a problem in a perl environment? Does mod perl allows any kind of security, to prevent ones writing script to read others files? PS: All cgi runs through suexec, so even cgi are not able to run the script, ok?
Re: security
On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho Rios wrote: Hi folks! I have a FreeBSD server configured as a http server, running apache. This installation includes mod_perl+EmbPerl, mod_php4 mod_cgi and mod_fastcgi. Some of my users will be using mysql for database. The problem is that this scenario requires sensitive information inside file. This means no problem when these users write their dymanic pages inside a compiled program. I can chmod a-rw and nobody will be able to take away user/password from a compiled program. The problem happens when write their php or embperl pages! the key user\password are kept inside this file, so anyone can uses an editor to retrieve the user mysql account. I resolve this problem running php on secure mode and chgrping the php file the same user as the http process and removing other flags file access (g-rwx). So nobody besides the owner of the file (or the http process) will be able to read it. since php have some security facilities, like: if the file owner id != the file the script is trying to open = fails. My problem is with perl: how to solve such a problem in a perl environment? Does mod perl allows any kind of security, to prevent ones writing script to read others files? PS: All cgi runs through suexec, so even cgi are not able to run the script, ok? At this moment anybody who has an access to mod_perl server can read any data which is accessible by the same server. suexec is not an option because of process persistance. I understand that you want to store the SQL engine authentication info, and users not to know each other's access credentials. The only solution at this point is to either trust your users not to abuse each other, or run a separate server for each one :( _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
security
Hi folks! I have just seted mod_perl with apache and i am using embperl too. I am worried about security concerns for mod_perl. How can i limit, for instance, the amount of memory used for embperl? the ammount of time allowed for a perl code to spend. With php is easy, there is directives like max_execution_time and memory_limit? Another questions: is there support for suexec in mod_perl (sorry if i did not get the ideia behind mod_perl and this concept does not apply to mod_perl)? Thanks for your support!
RE: security suggestion
On Fri, 17 Nov 2000, mgraham wrote: Maybe another approach would be to explicitly list the handlers that are allowed to be used in any given context. Kind of like 'Options', but for perl handlers. Something like 'PerlOptions', perhaps? Location /users PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler" /Location something like that is already implemented in mod_perl-2.0: http://perl.apache.org/~dougm/modperl_2.0.html probably will not happen for 1.xx
Re: security suggestion
In the context of what you are talking about, I think giving ExecCGI permissions should not allow them to change mod_perl handlers or do anything to adjust mod_perl either. ExecCGI is a lot less problematic than exposing access to mod_perl from a shared web server security standpoint especially if CGI's are suexec'ed. So I would advocate an ExecModPerl option or something like that so that user's could not arbitrarily install their own Perl Handlers. At 12:20 PM 11/19/2000 +, Richard Goerwitz wrote: Gunther Birznieks wrote: The CGI scripts on your site would not be passed through Apache::Registry or Apache::PerlRun, they would run as normal CGIs. No? So that makes sense as a motivation to allow mod_perl on a server for content handlers that are tightly defined. But don't allow the users access to anything else in mod_perl. Precisely. I feel as though I've been explaining myself poorly because I've been so widely misunderstood. But what you said above about sums it up. I'm only talking about giving people access to specific mod_perl modules (or to modules in very specific places). I don't want to give people blanket Apache::Registry access as part of that package (except in cases where I specifically say so). At the risk of repeating myself, I'm looking for a way of setting up mod_ perl so that, if I turn off ExecCGI for a given directory (and maybe spe- cify a list of Perl modules or paths), it will mean that, as far as mod_perl is concerned, 1) users can only use specific modules (or modules in specific places) 2) users can't (by implication) use Apache::Registry unless I say so 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv) 4) users can't include any Perl code indirectly or otherwise (e.g., Perl) Re (1) above, I wonder whether it matters if modules I allow load modules that I _don't_ allow. My sense is that as long as I can control the ini- tial loading, I don't care whether the thing that's loaded runs amok. It is my responsibility (if I allow access to a module) to make sure that module will behave itself. Those more versed in security issues will perhaps want to think this through. I've been receiving a steady trickle of off-list mail, by the way, from ISPs and webmasters/sysadmins working in organizations where you just can't allow everyone CGI access (or full mod_perl/Perl access) - but where it would be very useful to allow people selective access to specific Perl modules. They are excited by the thought that they could offer new functionality (and added value) to their services, without necessarily having to trust all their web users (publishers, web developers - whatever) enough to allow them to execute arbitrary Perl code. Those of you who are working on your own, or in small/controlled shops, may not have an intuitive grasp of the circumstances the rest of us work under. But if you think about how things must be for us (some of us w/ hundreds, if not thousands, of web developers), you'll see that we can't monitor every account and audit every change. Universities with lots of student workers/accounts are classic cases. Students are smart and mis- chievous, and they come and go regularly. They make web pages and sys- tems, and they do the same part-time for departments and workgrous with- in the institution. We may want to give them access to a specific Perl module (e.g., some institution-wide authentication system that's imple- mented with a PerlAuthenHandler). But we certainly don't want giving them that sort of access to open up a floodgate by allowing them to exe- cute arbitrary Perl code on the server - unless we say so (e.g., by giv- ing them ExecCGI permission). -- Richard Goerwitz PGP key fingerprint:C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Gunther Birznieks wrote:
At the risk of repeating myself, I'm looking for a way of setting up mod_
perl so that, if I turn off ExecCGI for a given directory (and maybe spe-
cify a list of Perl modules or paths), it will mean that, as far as mod_perl
is concerned,
1) users can only use specific modules (or modules in specific places)
2) users can't (by implication) use Apache::Registry unless I say so
3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv)
4) users can't include any Perl code indirectly or otherwise (e.g.,
Perl sections, literal 'sub { ... }'s as handlers)
...I would advocate an ExecModPerl option or something like that so that
user's could not arbitrarily install their own Perl Handlers.
Some thoughts:
If a user has ExecCGI privileges he or she can commandeer the most important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
on familiar turf. Sysadmins will understand the implications of turning it
on (i.e., they'll know that turning it on means the ability to execute code
on the server, using the ID under which Apache runs). And re-using ExecCGI
would relieve us of having to reserve another (mostly redundant) word.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
At 08:42 AM 11/20/00 -0500, Richard L. Goerwitz wrote:
Gunther Birznieks wrote:
At the risk of repeating myself, I'm looking for a way of setting up mod_
perl so that, if I turn off ExecCGI for a given directory (and maybe spe-
cify a list of Perl modules or paths), it will mean that, as far as
mod_perl
is concerned,
1) users can only use specific modules (or modules in specific places)
2) users can't (by implication) use Apache::Registry unless I say so
3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv)
4) users can't include any Perl code indirectly or otherwise (e.g.,
Perl sections, literal 'sub { ... }'s as handlers)
...I would advocate an ExecModPerl option or something like that so that
user's could not arbitrarily install their own Perl Handlers.
Some thoughts:
If a user has ExecCGI privileges he or she can commandeer the most important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
I don't think that this is the case if you configure apache to use suexec
option. With suexec, the CGI script a user invokes cannot even run with
the permissions of the web server, it runs with the permissions of the
individual user. No scripts can trample over each other (other than a
denial of service on CPU and disk) maliciously. But if you open up
mod_perl, then you give the user power over the entire web server including
the prospective capability to hijack another user's URLs.
I do believe there would be ISPs that would enable CGI and special mod_perl
handlers, but not want to enable a user installing their own handlers.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
on familiar turf. Sysadmins will understand the implications of turning it
on (i.e., they'll know that turning it on means the ability to execute code
on the server, using the ID under which Apache runs). And re-using ExecCGI
would relieve us of having to reserve another (mostly redundant) word.
I am not sure I agree that ExecCGI gives similar power as mod_perl based on
the argument of suexec behavior.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard L. Goerwitz" [EMAIL PROTECTED] wrote: Gunther Birznieks wrote: ...I would advocate an ExecModPerl option or something like that so that user's could not arbitrarily install their own Perl Handlers. If a user has ExecCGI privileges he or she can commandeer the most important part of the request cycle (the response phase), so I'm not sure we get better security or control by having a separate ExecModPerl option. NB: If we re-use ExecCGI for mod_perl, people will feel as though they're on familiar turf. Sysadmins will understand the implications of turning it on (i.e., they'll know that turning it on means the ability to execute code on the server, using the ID under which Apache runs). And re-using ExecCGI would relieve us of having to reserve another (mostly redundant) word. I don't think it's redundant at all. In fact it is already possible to configure a Location or VirtualHost section within a mod_perl server in which mod_perl functionality is disabled (or overridden) with an old-style ExecCGI directive (scripts fork into separate SUID user-owned processes). In that scenario, which is not as unlikely as it might at first seem, for an ISP, the directive ExecCGI already has meaning, and "reusing it" would cause some bad ambiguouity. -dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Gunther Birznieks" [EMAIL PROTECTED] wrote: In the context of what you are talking about, I think giving ExecCGI permissions should not allow them to change mod_perl handlers or do anything to adjust mod_perl either. ExecCGI is a lot less problematic than exposing access to mod_perl from a shared web server security standpoint especially if CGI's are suexec'ed. So I would advocate an ExecModPerl option or something like that so that user's could not arbitrarily install their own Perl Handlers. [snip] 1) users can only use specific modules (or modules in specific places) 2) users can't (by implication) use Apache::Registry unless I say so 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv) 4) users can't include any Perl code indirectly or otherwise (e.g., Perl) It seems like what you're really asking for is some sort of "LessModPerl" directive that disallows raw perl (perl sections, PerlModule and PerlRequire directives, others?) in .htaccess and limits @INC within .htaccess to a certain path, but allow users to add PerlSetVar youconfigvalue PerlHandlder YourPredefined::handlers to their .htaccess sections I agree - this has very useful applications in shared hosting. Having developed on large shared-server ISPs that successfully manage multiple developers, I've always thought it was going to be problematic for ISP's to deploy it because all of mod_perls power is just as easily invoked from .htaccess as it is from conf files (where the shared users are forbidden to go). that's where to enforce the security. administrators need to be able to set up the server conf files such that users can use .htaccess to configure what mod_perl handlers they want to use, but they can't specify handlers outside of a read-only (to them) "handlerlib" area and so cannot write their own handlers, "PerlRequire" scripts, or "PerlModule" modules. -dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Gunther Birznieks wrote: The CGI scripts on your site would not be passed through Apache::Registry or Apache::PerlRun, they would run as normal CGIs. No? So that makes sense as a motivation to allow mod_perl on a server for content handlers that are tightly defined. But don't allow the users access to anything else in mod_perl. Precisely. I feel as though I've been explaining myself poorly because I've been so widely misunderstood. But what you said above about sums it up. I'm only talking about giving people access to specific mod_perl modules (or to modules in very specific places). I don't want to give people blanket Apache::Registry access as part of that package (except in cases where I specifically say so). At the risk of repeating myself, I'm looking for a way of setting up mod_ perl so that, if I turn off ExecCGI for a given directory (and maybe spe- cify a list of Perl modules or paths), it will mean that, as far as mod_perl is concerned, 1) users can only use specific modules (or modules in specific places) 2) users can't (by implication) use Apache::Registry unless I say so 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv) 4) users can't include any Perl code indirectly or otherwise (e.g., Perl) Re (1) above, I wonder whether it matters if modules I allow load modules that I _don't_ allow. My sense is that as long as I can control the ini- tial loading, I don't care whether the thing that's loaded runs amok. It is my responsibility (if I allow access to a module) to make sure that module will behave itself. Those more versed in security issues will perhaps want to think this through. I've been receiving a steady trickle of off-list mail, by the way, from ISPs and webmasters/sysadmins working in organizations where you just can't allow everyone CGI access (or full mod_perl/Perl access) - but where it would be very useful to allow people selective access to specific Perl modules. They are excited by the thought that they could offer new functionality (and added value) to their services, without necessarily having to trust all their web users (publishers, web developers - whatever) enough to allow them to execute arbitrary Perl code. Those of you who are working on your own, or in small/controlled shops, may not have an intuitive grasp of the circumstances the rest of us work under. But if you think about how things must be for us (some of us w/ hundreds, if not thousands, of web developers), you'll see that we can't monitor every account and audit every change. Universities with lots of student workers/accounts are classic cases. Students are smart and mis- chievous, and they come and go regularly. They make web pages and sys- tems, and they do the same part-time for departments and workgrous with- in the institution. We may want to give them access to a specific Perl module (e.g., some institution-wide authentication system that's imple- mented with a PerlAuthenHandler). But we certainly don't want giving them that sort of access to open up a floodgate by allowing them to exe- cute arbitrary Perl code on the server - unless we say so (e.g., by giv- ing them ExecCGI permission). -- Richard Goerwitz PGP key fingerprint:C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
I think Randal was making a similar point I was making last night (SG time). That as long as you execute Perl code, you can manipualte the memory space of Perl (and hance change the behavior of Apache::Registry). But you explained it in your reply to me. Basically you want explicit handlers that are tightly defined to run but you aren't talking about allowing users to run Apache::Registry scripts arbitrarily. Just explicitly defined pieces of code like a handler for counter() logic. The CGI scripts on your site would not be passed through Apache::Registry or Apache::PerlRun, they would run as normal CGIs. No? So that makes sense as a motivation to allow mod_perl on a server for content handlers that are tightly defined. But don't allow the users access to anything else in mod_perl. At 04:36 PM 11/17/00 -0500, Richard L. Goerwitz wrote: "Randal L. Schwartz" wrote: I think y'all are missing it. As soon as I have any Perl code access via Apache::Registry or anything like that, I can do this: *Apache::Registry::handler = \my_trojan_horse; Can you explain in what server-configuration context the above directive would be executed? (I'm not disputing anything you say; just trying to follow.) -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
I think these are good points. However, to some degree, if this is an attempt to allow an ISP protection, it's not because most ISPs offer CGI access to their customers. In addition, the moment you give mod_perl access to a developer they have the rights to do a LOT of stuff that goes beyond putting PerlHandlers in an htaccess file. It's possible to go through the Apache::Registry package and walk the subroutine tree of precompiled scripts and conceivably figure out stuff about other people's scripts. Actually probably easier to just figure out what packages exist in memory and walk the memory and variables directly. If some of those variables are config vars, then oh well. In fact, I should think it is conceivable that one mod_perl script could theoretically replace another mod_perl script within the Apache::Registry by manipulating the global variables within Apache::Registry. So in other words, if you can't have a semblance of trust your developers against each other, then mod_perl simply cannot be configured in a way that developers can truely share the same web server. However, I don't think many people advocate sharing mod_perl web servers in teh real world with apache 1.3. When Apache and mod_perl 2.0 come out, I suspect the new architecture will allow very cool things like Perl Interpreter segmentation among virtual hosts. But until that happens, there's really not much you can do. It seems to me that mod_perl wasn't really designed for safety against your own developers doing something malicious. And most if not all people pretty much run their servers that way. Most people who run mod_perl run it as their own dedicated server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Gunther Birznieks wrote:
It seems to me that mod_perl wasn't really designed for safety against your
own developers
I accept this point. But it's really beside _my_ point, which was that
mod_perl modules can offer critical added functionality to run-of-the-mill
web publishers (whether it be a counter, a new authentication method, a
special content handler, or just some thingie I wrote for them). I think
it would be great to be able to offer web publishers the ability to _use_
those modules without giving them direct access to Perl.
Not all shops consist of a small group of twenty-something developers who
all eat pizza and beer together on Fridays. Many of us operate in hetero-
geneous environments with hundreds, if not thousands, of web "developers"
who are part of our community, and who may really need some custom modules
written for them, but who I can't be bothered monitoring on a day-to-day
basis - and who I don't want to grant blanket access to my server inter-
nals to.
Let me return to my C module analogy. When I compile in mod_auth_dbi, I
am giving users added functionality. But I'm not giving them the ability
to execute arbitrary C code. I think everyone would agree that this is a
useful (no, critical) feature of Apache.
I simply want to be able to do the same thing in Perl with mod_perl. I
want to be able to give developers ("users" - whatever you want to call
them) added functionality, without giving them the ability to execute
arbitrary Perl code.
I'd have no problem if mod_perl was set up to turn off PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of Perl modules
in non-system paths (except where ExecCGI is turned on). I don't know
what else would need to be done, but it all strikes me as critical to
the use of mod_perl in shops that don't fit the "pizza and beer" model
that something along these lines be done.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard I simply want to be able to do the same thing in Perl with mod_perl. I
Richard want to be able to give developers ("users" - whatever you want to call
Richard them) added functionality, without giving them the ability to execute
Richard arbitrary Perl code.
Use Template Toolkit, and disable the "EVAL_PERL" option for their space.
Set up Plugins and Filters that call your Cool Perl Code.
Then they write arbitary text files to be delivered, but when they
want your added functionality, all they can do is call your interfaces
using the mini-Toolkit language embedded in their files.
And they get a slick templating system for free!
Best of both worlds.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Randal L. Schwartz" wrote: Use Template Toolkit, and disable the "EVAL_PERL" option for their space. Set up Plugins and Filters that call your Cool Perl Code. Then they write arbitary text files to be delivered... Suppose it were possible to set Perl-based modules to work the same way C modules currently do (in the sense that they let you offer developers, users, etc. access to the module without letting them execute arbitrary code on the server). Would you agree that this would be a good thing? Your solution above is great. But it's another one of those "I have a workaround" suggestions. I wonder if there is a way to skip the workarounds. If there is, would you agree that it would be a good (no, wonderful) thing? And would you agree that, if it's possible to do it, mod_perl would be more useful if it were set up in such a way that merely enabling it didn't essentially give everyone with access to the webserver's docroot the ability to execute arbitrary Perl? I'm interested in knowing what's possible here. My knowledge of mod_ perl right now is pretty good, from a module developer's standpoint. I'm just not familiar enough (yet) with its internals to be able to think and speak creatively about the security possibilities. -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: security suggestion
I'd have no problem if mod_perl was set up to turn off
PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of
Perl modules
in non-system paths (except where ExecCGI is turned on).
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
/Location
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
mgraham wrote:
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
/Location
That's a neat idea.
The only quibble I can think of is that this doesn't go far enough.
This lower level of privilege we're talking about is one in which -
1) Only specific Perl modules are available (or ones in specific
paths; no literal 'sub { ... }' handlers)
2) PerlSetEnv (and PerlPassEnv?) aren't usable
3) PERL5LIB isn't changeable
4) Perl sections are unavailable
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard That's a neat idea.
Richard The only quibble I can think of is that this doesn't go far enough.
Richard This lower level of privilege we're talking about is one in which -
Richard 1) Only specific Perl modules are available (or ones in specific
Richard paths; no literal 'sub { ... }' handlers)
Richard 2) PerlSetEnv (and PerlPassEnv?) aren't usable
Richard 3) PERL5LIB isn't changeable
Richard 4) Perl sections are unavailable
I think y'all are missing it. As soon as I have any Perl code access
via Apache::Registry or anything like that, I can do this:
*Apache::Registry::handler = \my_trojan_horse;
Unless you use "Safe", any access to any Perl invocation means you are
insecure.
So mod_perl is inherently unsafe. Either you have access to Perl, or
you don't. And when you don't, you might as well invent a meta-API,
like the one I suggested with Template Toolkit. You can't use the
generic tools... they're too powerful.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Randal L. Schwartz" wrote: I think y'all are missing it. As soon as I have any Perl code access via Apache::Registry or anything like that, I can do this: *Apache::Registry::handler = \my_trojan_horse; Can you explain in what server-configuration context the above directive would be executed? (I'm not disputing anything you say; just trying to follow.) -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Following up on the security suggestion (I'm actually responding to private mail, so I'll just quote the person who wrote to me without giving a name) - Of course you can do this in an .htaccess file, too: Perl arbitrary perl code... /Perl I'd argue that people shouldn't be able to do that - unless, of course, they can ExecCGI. The general idea is this: Regular users without ExecCGI may have good reason to say things like, PerlAuthenHandler Apache::SomeNewAuthModule E.g., suppose you want them to be able to use some local secure cookie- based auth handler. Or they may want to use a locally written response handler that converts HTML to XHTML on the fly - or innumerable other modules. Although we want those users to have access to these modules (and to the added functionality they bring), we may not want them to be able to execute arbitrary Perl code. And if we DO want them to execute arbitrary Perl code, we should have to explicitly grant them permission to do it. Permission shouldn't be granted implicitly by doing something else (e.g., by enabling another module like mod_perl). My sense is that the existing ExecCGI mechanism is a perfectly reasonable way of handling the permissions here, since being able to execute arbi- trary Perl code is basically the same as ExecCGI privileges (it's a bit more powerful, but why introduce more options if we don't really need to?). -- Richard Goerwitz[EMAIL PROTECTED]
RE: security suggestion
-Original Message-
From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 10:11 AM
To: [EMAIL PROTECTED]
Cc: Geoffrey Young
Subject: Re: security suggestion
Following up on the security suggestion (I'm actually responding to
private mail, so I'll just quote the person who wrote to me without
giving a name) -
Of course you can do this in an .htaccess file, too:
Perl
arbitrary perl code...
/Perl
I'd argue that people shouldn't be able to do that - unless,
of course,
they can ExecCGI.
The general idea is this: Regular users without ExecCGI may have good
reason to say things like,
PerlAuthenHandler Apache::SomeNewAuthModule
but what about
PerlSetEnv PERL5LIB '/my/lib/'
PerlAuthenHandler My::Handler
there's nothing that says an AuthenHandler has to authenticate :)
maybe it would be possible to limit
PerlAuthenHandler 'sub {do something desctructive};'
via a directive, but this is mod_perl - I can't see how you would be able to
allow good activity without there being some way around it for destructive
types...
at least not in a generic sense - you could write an Init handler that
pushes Your::Validator to the front of each phase which runs all configured
handlers through various checks (of course one that seemed valid could push
another bad handler to the stack on the fly)
see what I mean - protection is not guaranteed...
Although we want those users to have access to these modules
(and to the
added functionality they bring), we may not want them to be able to
execute arbitrary Perl code.
PERL_SECTIONS=0 at build time can deactivate this across the board
--Geoff
RE: security suggestion
Perhaps you ought to gfind a way to use Safe; then?
-Original Message-
From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 9:09 AM
To: mod_perl list
Subject: security suggestion
At Doug's suggestion I'm moving a brief conversation we've had
in private
to this list so others can get involved.
I've been following out the security implications of mod_perl here at
Brown University, and from what I can see, enabling it gives people the
same basic access privileges that ExecCGI does. How does it do this?
Well, for one thing, you can inject arbitrary Perl code at any stage in
the Apache request cycle by using a literal
PerlWhateverHandler 'sub { ... }'
in an htaccess file. You can also specify
PerlWhateverHandler
Some::Arbitrary::Path::To::An::Arbitrary::Module.pm
I've been thinking that, since giving users the ability to do these
things is essentially like giving them ExecCGI privileges, that these
things should only be allowed where the ExecCGI option is turned on.
There's also the problem, if a person can ExecCGI, that they can then
use Apache (), and then access all dir_config, notes, and
other settings.
At times it may be useful for a systems administrator to create private
dir_config variables that run-of-the-mill CGI scripts simply can't see.
These are two separate issues, of course.
The more pressing one, I think, is the first, namely that we need to
tie the ability to use arbitrary Perl subroutines and arbitrary Perl
modules (i.e., modules in non-system paths) to the ExecCGI option.
I realize that forcing us all to turn ExecCGI on for directories where
we want to use arbitrary Perl subroutines would be a bit of a pain at
this point. So for the current 1.24_0x series I'd suggest adding some
new "paranoid" compile-time option that would deny arbitrary subs and
modules in non-system paths unless ExecCGI is enabled. Another idea
that I haven't really thought through would be to create some new
PerlLiteralSubs On|Off directive that could not be overridden once
turned on.
For the future, though, it might be useful to tie arbitrary subs and
the ability to use Perl modules to ExecCGI. ExecCGI-like privileges
something a sysadmin should always have to decide to do. My sense is
that they should never be turned on implicitly, e.g., by simply adding
and enabling a module.
Does this make sense to anyone else?
--
Richard Goerwitz
[EMAIL PROTECTED]
RE: security suggestion
Maybe it's just me, but it seems that the responses richard has gotten haven't really touched on the core of the problem. That mod_perl isn't exactly friendly to sysadmin's who want to run apache on a (i'm guessing), student accessed server, with user dir's and all that other stuff. I'm pretty sure (for no particular reason), that there aren't many people on this list that are doing that. If you have .htaccess stuff turned on right now, you can do all sorts of great things through apache that you wouldn't want untrusted accounts on the box being able to do. The servers that had apache on them for users when i was at school didn't even allow normal cgi, so i have no idea how one would approach doing something like this with mod_perl. If, on the other hand, i'm misinterpreting richards problems, feel free to ignore me. Adam
RE: security suggestion
The thing is, though, that as a web administrator I don't want those same developers (or at least all of them) to be able to create and in- stall _arbitrary_ handlers or arbitrary perl code. Sometimes the de- velopers just don't know enough. And sometimes I just don't trust them enough to allow it. And just putting your configuration for their portion of the site into the main configuration files would be insufficient? Christian
Re: security suggestion
"Adam Prime" [EMAIL PROTECTED] wrote:
Maybe it's just me, but it seems that the responses richard has gotten
haven't really touched on the core of the problem. That mod_perl isn't
exactly friendly to sysadmin's who want to run apache on a (i'm guessing),
student accessed server, with user dir's and all that other stuff. I'm
pretty sure (for no particular reason), that there aren't many people on
this list that are doing that.
I assumed the question was related to the situation of an ISP (or more specifically
web hosting provider) who wants to offer some mod_perl functionality to users on a
shared server. the environment may be similar to the educational scenario, but the
difference is that a web presence provider that is "first" to offer mod_perl (at
prices competitive with oher shared hosting services) stands to differentiate itself
ffrom it's competition and see a signficant revenue reward for it's efforts, either
from being able to charge extra for the mod_perl add-on service, or simply as a swell
of users flock to signup for new service there.
It's an interesting problem in that context. offering mod_perl in such an environment
"safely" would be a big advantage to my hosting provider for instance (pair.com) who
*does* offer custom CGI, is extremely developer-friendly (supports perl, C, php and
python CGI) but has so many users sharing the same httpd that the mod_perl problems
are many and varied. we can't access .conf files or restart apache so we're limited
to .htaccess configuration.
There are so many active developers already that they run "reaper" processes on each
server to kill runaway scripts, and enforce resource limits on user processes.
If they could enforce these rlimits and automatically kill runaway code in users'
mod_perl processes, and *if* those user scripts could be isolated such that they can't
bring down the parent httpd process, mod_perl would be an awesome feature of the
service!
...If you have .htaccess stuff turned on right
now, you can do all sorts of great things through apache that you wouldn't
want untrusted accounts on the box being able to do.
right. it seems like raw perl in .htaccess files would almost *have* to be disabled.
or would it? bad/uncompilable code in .htaccess would just affect the requests that
invoked it, not the parent process...
as long as the server is running as an unpriveledged nobody-user or SetUID as the
~/user who is owns it, the security concerns should be minimal. if a mod_perl process
can attain root priveledges that would, uh, be a bad thing :-)
Of course, in such a restricted environment, many of mod_perl's advantages would be
nullified; scripts would not stay compiled in memory, and modules would be reloaded
on every request (since editing conf files or startup.pl or restarting apache isn't
possible). But hooking into the auth process alone would add a LOT of flexibility to
the many sites hosted on shared servers there.
plus there are endless support requests on "how to do this or that with mod_rewite
regexps"... (i agree with Randal here... how did that ever catch on? heheh).
rewriting and redirecting with mod_perl is *so* much simpler and more flexible.
The servers that had apache on them for users when i was at school didn't
even allow normal cgi, so i have no idea how one would approach doing
something like this with mod_perl.
right. many (lazy) commercial web hosting providers don't even (to this day) offer
perl CGI either. But most decent ones have realized that even the unwashed masses
need perl scripts to run, and have already successfully addressed ExecCGI security
issues in order to remain competitive.
pair has even recently begun to equip servers with mod_php... but i think mod_perl has
been deemed too powerful for use on shared servers, for now... {sigh}
-dave (secretly hoping that the mod_php scripters here crash the servers with endless
loops and stuff)
Re: mod_perl security :: possible solution
On Thu, 7 Sep 2000, Félix C.Courtemanche wrote: Hi, I have been looking around for some time already about this and here are the 2 solutions I came up with... I would like some comments, especially if you think it would be safe / fast to use. Uhm, did you read the proposed solutions at http://perl.apache.org/guide/multiuser.html Solution #1 (apache solution) ¯ - Use a centralized apache server for all html request, graphics, etc. mod_php and mod_perl disabled on this server - Redirect a certain directory or sub domains to a personalized apache server (on an unprivileged port), running under the client's uid. - That personalized server would be compiled with mod_perl and mod_php, and running with the following apache directives: - RLimitMEM (http_core.c) :: Soft/hard limits for max memory usage per process - RLimitNPROC (http_core.c) :: Soft/hard limits for max number of processes per uid - It would also have the Apache-Watchdog-RunAway perl module installed to kill zombies. That solution would allow the fastest setup (as far as I am concerned) but I am afraid that redirecting the directory to a personalized apache server could generate some problems... I thought of redirect using the [P] flag (proxy) so that the url viewed in the browser stay the same... however, for each queries, 2 httpd process will have to handle it. This may hurt the performances for a web site using a lot of scripts. Nauh, it won't hurt the performance. Almost everybody uses this scenario. See http://perl.apache.org/guide/strategy.html Solution #2 (perl module solution) ¯ - Only use 1 apache server for everyone - Use Apache:SizeLimit (included with mod_perl) (memory watchdog) - Use Apache-watchdog-runaway (same as above) - Use apache:resources for other control - Use Apache:safe and apache:safe:hole to restrict the use of mod_perl... however I may have to fight with it a bit to allow DBI and other similar modules to be used as well That solution appears to be faster for me, but a lot harder to set up and configure. It may involve some programmation, etc. What is your opinion on these... and do you have a better solution? Wich one is the best? I am open for any comments and help... I plan to set up some package or at least a web page to explain to others how to do it once it is working perfectly for me. I noticed that perl security (along with shell security) is one of the worst seucirty/privacy treat in almost all web hosting companies... and I intend to solve this. :) I don't see any security-wise differences between #1 and #2. These are performance issues, where #1 wins in most cases, while #2 is Ok for specific content delivery setups. See the Strategy chapter link above. You still run mod_perl in both setups, so this is the only thing that you have to solve. I've an overdue article in the queue of things that I've to do, that talks about this, mainly based on the multiuser.html chapter and the information I've collected from ISPs a month ago. (Not much though, so if you have some information to share with public and plug the name of your mod_perl ISP service in make sure to contact me.). _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: mod_perl security on a shared web server
On Wed, 6 Sep 2000, Félix C.Courtemanche wrote:
Hello,
I couldn't find any occurance of this question in the archives, but if it
does exists, please forward me to it.
I have been working on a set of Administration Tools for commercial web
hosting companies for quite some times. Lately I have been trying to figure
out the MOST secure way to host multiple accounts on the same server, with
mod_perl enabled AS FAST AS POSSIBLE.
In the best world, I would have the possibility of:
- Restricting the opened files by any .pl script to the user's base
directory.
- Allowing custom shell commands or not
- Setting a maximum execution time for a script
The first directive would be used to prevent anyone from reading the source
of another program, wich would allow someone to grab the sensitive data
stored in configuration files, such as Database Passwords, etc. It is the
MOST important of all and I really must find a solution. I previously saw
some perl wrapper that would only allow files owned by the script's owner to
be read. However, that wrapper greatly reduced the execution speed of .pl
and it was not that effective. Any suggestions?
http://perl.apache.org/guide/multiuser.html
Finally, the third directive would allow me to kill any script running for
too long or using too much CPU.
Apache::Watchdog::RunAway does the 'too long' part.
Apache::{SizeLimit|GTopLimit} do the 'too much memory/too low sharing'
part.
Apache::Resource does the rest.
I understand that there is probably no tool to do all of it, but if I can
gather the tools to make it as effective as possible, it would be really
usefull for me and others.
Please don't tell me to monitor the user's scripts, since that is almost
impossible to do when you have more than 10 sites to monitor, wich will
happen quickly :)
Any other tips and tricks to improve the security of mod_perl is greatly
appreciated as well.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Félix C.Courtemanche . Head Designer
Co-Administrator . Can-Host Networks
http://www.can-host.com
[EMAIL PROTECTED]
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
mod_perl security :: possible solution
Hi, I have been looking around for some time already about this and here are the 2 solutions I came up with... I would like some comments, especially if you think it would be safe / fast to use. Solution #1 (apache solution) ¯ - Use a centralized apache server for all html request, graphics, etc. mod_php and mod_perl disabled on this server - Redirect a certain directory or sub domains to a personalized apache server (on an unprivileged port), running under the client's uid. - That personalized server would be compiled with mod_perl and mod_php, and running with the following apache directives: - RLimitMEM (http_core.c) :: Soft/hard limits for max memory usage per process - RLimitNPROC (http_core.c) :: Soft/hard limits for max number of processes per uid - It would also have the Apache-Watchdog-RunAway perl module installed to kill zombies. That solution would allow the fastest setup (as far as I am concerned) but I am afraid that redirecting the directory to a personalized apache server could generate some problems... I thought of redirect using the [P] flag (proxy) so that the url viewed in the browser stay the same... however, for each queries, 2 httpd process will have to handle it. This may hurt the performances for a web site using a lot of scripts. Solution #2 (perl module solution) ¯ - Only use 1 apache server for everyone - Use Apache:SizeLimit (included with mod_perl) (memory watchdog) - Use Apache-watchdog-runaway (same as above) - Use apache:resources for other control - Use Apache:safe and apache:safe:hole to restrict the use of mod_perl... however I may have to fight with it a bit to allow DBI and other similar modules to be used as well That solution appears to be faster for me, but a lot harder to set up and configure. It may involve some programmation, etc. What is your opinion on these... and do you have a better solution? Wich one is the best? I am open for any comments and help... I plan to set up some package or at least a web page to explain to others how to do it once it is working perfectly for me. I noticed that perl security (along with shell security) is one of the worst seucirty/privacy treat in almost all web hosting companies... and I intend to solve this. :) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Félix C.Courtemanche . Head Designer Co-Administrator . Can-Host Networks http://www.can-host.com [EMAIL PROTECTED]
Re: mod_perl security on a shared web server
On Wed, 6 Sep 2000, Félix C.Courtemanche wrote: Hello, I couldn't find any occurance of this question in the archives, but if it does exists, please forward me to it. I have been working on a set of Administration Tools for commercial web hosting companies for quite some times. Lately I have been trying to figure out the MOST secure way to host multiple accounts on the same server, with mod_perl enabled AS FAST AS POSSIBLE. In the best world, I would have the possibility of: - Restricting the opened files by any .pl script to the user's base directory. - Allowing custom shell commands or not - Setting a maximum execution time for a script The first directive would be used to prevent anyone from reading the source of another program, wich would allow someone to grab the sensitive data stored in configuration files, such as Database Passwords, etc. It is the MOST important of all and I really must find a solution. I previously saw some perl wrapper that would only allow files owned by the script's owner to be read. However, that wrapper greatly reduced the execution speed of .pl and it was not that effective. Any suggestions? The _only_ way I see you being able to do this securely is to use a Safe compartment with a Safe::Hole through to your custom open() function which does all the checking. The problem then becomes enabling something like DBI support. You'd need to provide a safe hole through to DBI (not sure if you'd have to write a wrapper or what - never tried it personally). And then the same goes for something like CGI.pm, probably. The other stuff can be done with the resource limiting modules. If you come up with something it would be great if you could share it. I started working on something like it a while back (even had an Apache::SafeRegistry module built, but it didn't work because Safe::Hole didn't exist back then). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: mod_perl security on a shared web server
I would suggest www.freevsd.org, because what you need is complete compartmentalization. F?lix C.Courtemanche ([EMAIL PROTECTED]) was saying: Hello, I couldn't find any occurance of this question in the archives, but if it does exists, please forward me to it. I have been working on a set of Administration Tools for commercial web hosting companies for quite some times. Lately I have been trying to figure out the MOST secure way to host multiple accounts on the same server, with mod_perl enabled AS FAST AS POSSIBLE. In the best world, I would have the possibility of: - Restricting the opened files by any .pl script to the user's base directory. - Allowing custom shell commands or not - Setting a maximum execution time for a script The first directive would be used to prevent anyone from reading the source of another program, wich would allow someone to grab the sensitive data stored in configuration files, such as Database Passwords, etc. It is the MOST important of all and I really must find a solution. I previously saw some perl wrapper that would only allow files owned by the script's owner to be read. However, that wrapper greatly reduced the execution speed of .pl and it was not that effective. Any suggestions? The second directive would allow me to specify wether or not a user can run commands that would be passed as shell OR specify what paths are available (only /usr/bin for example) Finally, the third directive would allow me to kill any script running for too long or using too much CPU. I understand that there is probably no tool to do all of it, but if I can gather the tools to make it as effective as possible, it would be really usefull for me and others. Please don't tell me to monitor the user's scripts, since that is almost impossible to do when you have more than 10 sites to monitor, wich will happen quickly :) Any other tips and tricks to improve the security of mod_perl is greatly appreciated as well. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Félix C.Courtemanche . Head Designer Co-Administrator . Can-Host Networks http://www.can-host.com [EMAIL PROTECTED] -- [EMAIL PROTECTED] "With pain comes clarity."
Re: mod_perl security on a shared web server
In fact, I would like to see something similar to what you sent, but that would only apply to mod_perl (or any other way toe xecute perl scripts in apache) since I am also using other languages, databases, etc that would be somewhat harder to isntall with such a comparmentization. I am currently taking a look at the safe perl module to see if it can do the job for me. I had someone mention ressource restricting modules, especially for the amount of cpu, ram and time of execution used. Anyone can direct me specifically to any of theses (or all of them)? I can't seem to find one that is completed and working well. Please keep in mind that security and optimization are the top 2 priorities in this adventure :) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Félix C.Courtemanche . Head Designer Co-Administrator . Can-Host Networks http://www.can-host.com [EMAIL PROTECTED] -Message d'origine- De : Jonathan Leto [EMAIL PROTECTED] À : Félix C.Courtemanche [EMAIL PROTECTED] Cc : [EMAIL PROTECTED] [EMAIL PROTECTED] Date : 6 septembre, 2000 03:05 Objet : Re: mod_perl security on a shared web server I would suggest www.freevsd.org, because what you need is complete compartmentalization. F?lix C.Courtemanche ([EMAIL PROTECTED]) was saying: Hello, I couldn't find any occurance of this question in the archives, but if it does exists, please forward me to it. I have been working on a set of Administration Tools for commercial web hosting companies for quite some times. Lately I have been trying to figure out the MOST secure way to host multiple accounts on the same server, with mod_perl enabled AS FAST AS POSSIBLE. In the best world, I would have the possibility of: - Restricting the opened files by any .pl script to the user's base directory. - Allowing custom shell commands or not - Setting a maximum execution time for a script The first directive would be used to prevent anyone from reading the source of another program, wich would allow someone to grab the sensitive data stored in configuration files, such as Database Passwords, etc. It is the MOST important of all and I really must find a solution. I previously saw some perl wrapper that would only allow files owned by the script's owner to be read. However, that wrapper greatly reduced the execution speed of .pl and it was not that effective. Any suggestions? The second directive would allow me to specify wether or not a user can run commands that would be passed as shell OR specify what paths are available (only /usr/bin for example) Finally, the third directive would allow me to kill any script running for too long or using too much CPU. I understand that there is probably no tool to do all of it, but if I can gather the tools to make it as effective as possible, it would be really usefull for me and others. Please don't tell me to monitor the user's scripts, since that is almost impossible to do when you have more than 10 sites to monitor, wich will happen quickly :) Any other tips and tricks to improve the security of mod_perl is greatly appreciated as well. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Félix C.Courtemanche . Head Designer Co-Administrator . Can-Host Networks http://www.can-host.com [EMAIL PROTECTED] -- [EMAIL PROTECTED] "With pain comes clarity."
RE: mod_perl security on a shared web server
Felix, There's not much available that is efficient and does per-resource throttling based upon CPU, RAM, and time of which I know. I looked around for such things about 8 months ago. I instead decided that, for my needs, limiting simultaneous client access to resource hogs was good enough. I wrote mod_throttle_access to serve this purpose. It is available through the Apache Module Registry or directly here: http://www.fremen.org/apache/ Regards, Christian From: Félix C.Courtemanche [mailto:[EMAIL PROTECTED]] I had someone mention ressource restricting modules, especially for the amount of cpu, ram and time of execution used. Anyone can direct me specifically to any of theses (or all of them)? I can't seem to find one that is completed and working well.
mod_perl security on a shared web server
Hello, I couldn't find any occurance of this question in the archives, but if it does exists, please forward me to it. I have been working on a set of Administration Tools for commercial web hosting companies for quite some times. Lately I have been trying to figure out the MOST secure way to host multiple accounts on the same server, with mod_perl enabled AS FAST AS POSSIBLE. In the best world, I would have the possibility of: - Restricting the opened files by any .pl script to the user's base directory. - Allowing custom shell commands or not - Setting a maximum execution time for a script The first directive would be used to prevent anyone from reading the source of another program, wich would allow someone to grab the sensitive data stored in configuration files, such as Database Passwords, etc. It is the MOST important of all and I really must find a solution. I previously saw some perl wrapper that would only allow files owned by the script's owner to be read. However, that wrapper greatly reduced the execution speed of .pl and it was not that effective. Any suggestions? The second directive would allow me to specify wether or not a user can run commands that would be passed as shell OR specify what paths are available (only /usr/bin for example) Finally, the third directive would allow me to kill any script running for too long or using too much CPU. I understand that there is probably no tool to do all of it, but if I can gather the tools to make it as effective as possible, it would be really usefull for me and others. Please don't tell me to monitor the user's scripts, since that is almost impossible to do when you have more than 10 sites to monitor, wich will happen quickly :) Any other tips and tricks to improve the security of mod_perl is greatly appreciated as well. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Félix C.Courtemanche . Head Designer Co-Administrator . Can-Host Networks http://www.can-host.com [EMAIL PROTECTED]
Re: .htacess security
On Thu, 3 Aug 2000, Ken Williams wrote: [EMAIL PROTECTED] (Rob Giseburt) wrote: Are .htaccess files secure? I don't want users to be able to use perl.../perl sections or any other mod_perl constructs (setting scripts to run via the Registry, for example) in .htaccess files. However, I need ..htaccess files turned on so users can password protect directories site-wide (so I can't shut .htaccess files off completely.) I assume you need Perl sections in your main httpd.conf? If not, you can just shut it off altogether. Alternatively, you might want to shut it off and use a templating system to generate your httpd.conf file(s) so they don't have Perl sections in them. One extra question: Can I turn on mod_perl SSI and have normal SSI calls at the same time? In other words, can I have one page (file.pshtml maybe) parsed by perl-extended SSI and another (file.shtml) be parsed by normal (without perl, mod_ssi?) SSI? I'm not sure (I think probably not), but you can get the same effect if you use Apache::SSI for some pages and regular mod_ssi for the others. It also depends on what you mean by "mod_perl SSI". If Rob is talking about Ken's Apache::SSI handler, that's one thing, but compiling PERL_SSI=1 to add #perl extentions to "regular" mod_include is another. Setting up Apache::SSI to handle some files and mod_include to handle others is not a problem. But is it possible to selectively allow #perl in only some mod_include files? If you're worried about people using Perl sections in .htaccess files, you're going to have to worry about !--#perl sub="whatever" -- in SSI files too.
.htacess security
Are .htaccess files secure? I don't want users to be able to use perl.../perl sections or any other mod_perl constructs (setting scripts to run via the Registry, for example) in .htaccess files. However, I need .htaccess files turned on so users can password protect directories site-wide (so I can't shut .htaccess files off completely.) Is there any need to worry? I can't have users writing any code that will be executed by the primary httpd process ... all user CGI execution is done via mod_cgi and SuEXEC. Thanks, -Rob Giseburt Random Quote: "When the chips are down, the buffalo is empty." (author unknown)
Re: .htacess security
On 8/3/2000 9:54 AM, Erich L. Markert at [EMAIL PROTECTED] wrote: Damn good question... I know the default apache config has a rule that prevents .htaccess files from being accessed via a URL but not from within an embedded. One way around this would be to use a database to handle accounts and use Apache::AuthDBI and then place directory access restrictions in your httpd.conf I'd like to avoid that approach if at all possible. I want the users to have a 'standard apache interface' experience ... where the way to add/remove passwords to a directory is via .htaccess. But, a web-interface to directory access might look better... One extra question: Can I turn on mod_perl SSI and have normal SSI calls at the same time? In other words, can I have one page (file.pshtml maybe) parsed by perl-extended SSI and another (file.shtml) be parsed by normal (without perl, mod_ssi?) SSI? -Rob Giseburt Random Quote: "Change is inevitable, except from a vending machine." (author unknown)
Re: .htacess security
[EMAIL PROTECTED] (Rob Giseburt) wrote: Are .htaccess files secure? I don't want users to be able to use perl.../perl sections or any other mod_perl constructs (setting scripts to run via the Registry, for example) in .htaccess files. However, I need ..htaccess files turned on so users can password protect directories site-wide (so I can't shut .htaccess files off completely.) I assume you need Perl sections in your main httpd.conf? If not, you can just shut it off altogether. Alternatively, you might want to shut it off and use a templating system to generate your httpd.conf file(s) so they don't have Perl sections in them. One extra question: Can I turn on mod_perl SSI and have normal SSI calls at the same time? In other words, can I have one page (file.pshtml maybe) parsed by perl-extended SSI and another (file.shtml) be parsed by normal (without perl, mod_ssi?) SSI? I'm not sure (I think probably not), but you can get the same effect if you use Apache::SSI for some pages and regular mod_ssi for the others.
ANNOUNCE: Apache::ASP v1.95 - Security Hole Fixed
ANNOUNCE Apache::ASP v1.95 - Security Hole Fixed Apache::ASP http://www.nodeworks.com/asp/ had a security hole in its ./site/eg/source.asp distribution examples file, allowing a malicious hacker to potentially write to files in the directory local to the source.asp example script. The next version of Apache::ASP v1.95 going to CPAN will not have this security hole in its example ./site/eg/source.asp The general CHANGES for this release is below. Note that CPAN may not have the 1.95 version for another 24 hours. Until you have the latest examples, I would recommend deleting this source.asp file from any public web server that has Apache::ASP installed on it. The original report on a similar perl open() bug was at ZDNet's eWeek at http://www.zdnet.com/eweek/stories/general/0,11011,2600258,00.html where a hacking contest at openhack.org turned up a bug on its minivend ecommerce software. --Joshua Chamas =item $VERSION = 1.95; $DATE="07/10/00"; ! EXAMPLES SECURITY BUG FOUND FIXED ! --FIXED: distribution example ./site/eg/source.asp now parses out special characters of the open() call when reading local files. This bug would allow a malicious user possible writing of files in the same directory as the source.asp script. This writing exploit would only have effect if the web server user has write permission on those files. Similar bug announced by openhack.org for minivend software in story at: http://www.zdnet.com/eweek/stories/general/0,11011,2600258,00.html !! -$0 now set to transferred file, when using $Server-Transfer -Fix for XMLSubsMatch parsing on cases with 2 or more args passed to tag sub that was standalone like Apps:header type="header" title="Moo" foo="moo" /
[OT - Security] Linux vulnerability
Hi all, I thought this might be of interest to Apache users running Linux. A vulnerability in some versions of Linux has recently been identified. SYSTEMS AFFECTED Linux kernel versions 2.2.x before 2.2.16 (2.0.x are safe; 2.2.16 is safe) IMPACT Any local user can gain root privileges TO FIX Upgrade to kernel 2.2.16 REFERENCES Postings regarding the vulnerability to BUGTRAQ: http://www.securityfocus.com/templates/archive.pike?list=1date=2000-06-01m [EMAIL PROTECTED] http://www.securityfocus.com/templates/archive.pike?list=1date=2000-06-01m sg=070b01bfd0cd$95b678e0$[EMAIL PROTECTED] http://www.securityfocus.com/templates/archive.pike?list=1date=2000-06-01m [EMAIL PROTECTED] Source for Linux kernel version 2.2.16: http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.16.tar.gz NOTES Don't be confused by the references to Sendmail in the descriptions of the bug - its role in this vulnerability is incidental and other setuid programs may be usable in a similar way. 73, Ged.
Re: [OT - Security] Linux vulnerability
On Sat, 10 Jun 2000, Ged Haywood wrote: Hi all, I thought this might be of interest to Apache users running Linux. [snip] Note that this is not a vulnerability that Apache/Linux suffers from particularly, except in the case of a mod_perl or CGI exploit that allows the user to get a local account on the machine, in which case he/she can "upgrade" that account to root using this exploit. Of course you should probably say "to hell with my 90+ days uptime" and upgrade anyway ;-) -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Security in displaying arbitrary HTML
Matt Sergeant writes: Unfortunately there's also a browser bug to contend with. They treat \x8b (I think that's the right code) as and there's a similar code for . Since most web developers are just doing s//lt;/g; they are open to attacks based on character sets like this. Sad, but true. Even our loved CGI.pm was (is?) open to this bug - I think Lincoln has fixed the HTMLEncode function now though. Gerald, what about Embperl, does it escape \x8b? Dirk
RE: Security in displaying arbitrary HTML
Jeremy Howard wrote: I'm interested in providing 'HTML email' support for my users (like HotMail, Outlook Express, Eudora 4.0, etc provide), but I'm very nervous about security. Essentially, providing HTML email involves letting any arbitrary HTML get displayed by Apache... I've been through this problem with my webmail program, acmemail. The problem is much greater with webmail than general other web applications due to the fact that you actually want to allow HTML emails to display properly. I currently use some code based on John Hardin's "Defang HTML active-content tags" routine in his procmail security package. URL:http://www.wolfenet.com/~jhardin/procmail-security.html He's been working on it for a while, and appears to have it down to a fine art. It hopefully disables any (possibly malicious) code in an HTML message. However, I'm sure it doesn't cope with everything. Someone should really come up with an ultimate, general, solution... Leon -- Leon Brocard | perl "programmer" | [EMAIL PROTECTED]
Re: Security in displaying arbitrary HTML
Matt Sergeant writes: Unfortunately there's also a browser bug to contend with. They treat \x8b (I think that's the right code) as and there's a similar code for . Since most web developers are just doing s//lt;/g; they are open to attacks based on character sets like this. Sad, but true. Even our loved CGI.pm was (is?) open to this bug - I think Lincoln has fixed the HTMLEncode function now though. Gerald, what about Embperl, does it escape \x8b? Dirk
RE: Security in displaying arbitrary HTML
Gerald, what about Embperl, does it escape \x8b? No, there is no html escape for \x8b (and I guess the other one Matt mentioned is \0x8d for ) I know, so Embperl will not escape it, but this could be simply change by an entry in epchar.c. Any suggestion to what this should be escaped? Then I will make a patch. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: Security in displaying arbitrary HTML
On Fri, 28 Apr 2000, Gerald Richter wrote:
Gerald, what about Embperl, does it escape \x8b?
No, there is no html escape for \x8b (and I guess the other one Matt
mentioned is \0x8d for ) I know, so Embperl will not escape it, but this
could be simply change by an entry in epchar.c. Any suggestion to what this
should be escaped? Then I will make a patch.
"#" . ord("\0x8a") . ";"
Whatever that produces. Same for \0x8d.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: Security in displaying arbitrary HTML
On Thu, 27 Apr 2000, Matt Sergeant wrote: Unfortunately there's also a browser bug to contend with. They treat \x8b (I think that's the right code) as and there's a similar code for . Since most web developers are just doing s//lt;/g; they are open to attacks based on character sets like this. Sad, but true. Even our loved CGI.pm was (is?) open to this bug - I think Lincoln has fixed the HTMLEncode function now though. Mmm? Which browsers? Do they have to be configured for any particular character set? And can you provide an example that demonstrates it? I can't reproduce it...
Re: Security in displaying arbitrary HTML
On Fri, 28 Apr 2000, Marc Slemko wrote: On Thu, 27 Apr 2000, Matt Sergeant wrote: Unfortunately there's also a browser bug to contend with. They treat \x8b (I think that's the right code) as and there's a similar code for . Since most web developers are just doing s//lt;/g; they are open to attacks based on character sets like this. Sad, but true. Even our loved CGI.pm was (is?) open to this bug - I think Lincoln has fixed the HTMLEncode function now though. Mmm? Which browsers? Do they have to be configured for any particular character set? And can you provide an example that demonstrates it? I can't reproduce it... Well if you have Apache 1.3.12, it implicitly sets the Content-Encoding, or the character set, so this bug is minimised. But only on static content. If there's no character set in the Content-type or Content-Encoding the browser sniffer comes into play, and Netscape (IIRC) picks it up as Latin-1, or US-ASCII, I can't recall which. The details are all available over the web. Tom Christiansen had an excellent informative discussion about it on p5p - search the archives. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
