You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Daryl Tester <dt...@handcraftedcomputers.com.au> on 2010/09/09 22:33:11 UTC
[users@httpd] Securing handler from direct access via URL.
Howdee.
I'm attempting to set up a PHP application in a chrooted FastCGI environment
under Apache 2.2.14 under Ubuntu 10.04. My (abbreviated) configuration is:
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
FastCgiServer /usr/lib/cgi-bin/php5
<Directory "/var/www/webmail">
AddHandler php-fastcgi .php
DirectoryIndex index.php
Action php-fastcgi /cgi-bin/php5
</Directory>
This works as it should, but a side effect is that Action is exposing
http:///cgi-bin/php5 to the outside world (which barfs when accessed
directly). Access permissions on the cgi-bin directory appear to get
propagated to the resources I'm trying to "handle", so that doesn't
help.
Is there a way I can set up a handler but not have it directly exposed
via URL (as opposed to the URLs it "handles")?
Cheers.
--
Regards,
Daryl Tester
"It's bad enough to have two heads, but it's worse when one's unoccupied."
-- Scatterbrain, "I'm with Stupid."
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Securing handler from direct access via URL.
Posted by Daryl Tester <dt...@handcraftedcomputers.com.au>.
Jefferson Ogata wrote:
> Yes, inasmuch as you didn't clarify that you perceive the configuration
> as an actual vector for attack, rather than an aesthetically displeasing
> feature. Instead you mention that it "barfs when accessed directly",
> which implied to me that you didn't recognize the potential threat.
Opening sentence mentioned chroot'ing.
> I wrote was therefore not merely for your benefit, but for that of
> anyone who comes across this thread in the future.
Fair enough.
--
Regards,
Daryl Tester
"It's bad enough to have two heads, but it's worse when one's unoccupied."
-- Scatterbrain, "I'm with Stupid."
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Securing handler from direct access via URL.
Posted by Jefferson Ogata <ap...@antibozo.net>.
On 2010-09-09 21:37, Daryl Tester wrote:
> Yes, again, I know it's dangerous, hence the concern of my original post.
> Was my subject line ambiguous?
Yes, inasmuch as you didn't clarify that you perceive the configuration
as an actual vector for attack, rather than an aesthetically displeasing
feature. Instead you mention that it "barfs when accessed directly",
which implied to me that you didn't recognize the potential threat. What
I wrote was therefore not merely for your benefit, but for that of
anyone who comes across this thread in the future.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Securing handler from direct access via URL.
Posted by Daryl Tester <dt...@handcraftedcomputers.com.au>.
Jefferson Ogata wrote:
> That sounds like a potentially extremely dangerous configuration.
Agreed, which is why I'm asking how to not do it. All the non-mod_php
examples I seem to find on the net are set up in this configuration.
I cannot get "Action" to point to something other than a cgi script,
and I don't know if there's another directive that will do what I want
(SetHandler will kibosh all files in that directory, which will affect
the non-php resources).
> Interpreters in general should never be accessible as direct CGIs if
> there's any way for an attacker to submit input to them for
> interpretation. (Consider also POSTing to http:///cgi-bin/php5+/dev/fd/0.)
Yes, again, I know it's dangerous, hence the concern of my original post.
Was my subject line ambiguous?
--
Regards,
Daryl Tester
"It's bad enough to have two heads, but it's worse when one's unoccupied."
-- Scatterbrain, "I'm with Stupid."
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Securing handler from direct access via URL. *RESOLUTION*
Posted by Daryl Tester <dt...@handcraftedcomputers.com.au>.
Jefferson Ogata wrote:
> On 2010-09-09 20:33, Daryl Tester wrote:
>> This works as it should, but a side effect is that Action is exposing
>> http:///cgi-bin/php5 to the outside world (which barfs when accessed
>> directly). Access permissions on the cgi-bin directory appear to get
>> propagated to the resources I'm trying to "handle", so that doesn't
>> help.
> That sounds like a potentially extremely dangerous configuration. I
> wonder what happens when you POST to that CGI.
Bear in mind that this is Ubuntu 10.04's *default* location for php in
their php5-cgi package (potentially copied from Debian - I neither know
nor care any more about these arbitrary distinctions), so this wasn't
something I'd set up. It didn't help that FastCGI's canonical
configuration of supporting script handlers is by forcing the interpreter
to live in URL accessible space either (see use of Action directive at
<http://www.fastcgi.com/drupal/node/5?q=node/10>, and other PHP+FastCGI
documents).
To "fix" this issue, I've subsequently discovered the mod_fcgid module
which allows me to have an AddHandler without Action directive, so now
my interpreters are existing well outside of access from URLs. Now I'm
a moderately happy camper (or at least, sleeping slightly better at night).
Cheers.
--
Regards,
Daryl Tester
"It's bad enough to have two heads, but it's worse when one's unoccupied."
-- Scatterbrain, "I'm with Stupid."
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Securing handler from direct access via URL.
Posted by Jefferson Ogata <ap...@antibozo.net>.
On 2010-09-09 20:33, Daryl Tester wrote:
> This works as it should, but a side effect is that Action is exposing
> http:///cgi-bin/php5 to the outside world (which barfs when accessed
> directly). Access permissions on the cgi-bin directory appear to get
> propagated to the resources I'm trying to "handle", so that doesn't
> help.
That sounds like a potentially extremely dangerous configuration. I
wonder what happens when you POST to that CGI.
Interpreters in general should never be accessible as direct CGIs if
there's any way for an attacker to submit input to them for
interpretation. (Consider also POSTing to http:///cgi-bin/php5+/dev/fd/0.)
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org