You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2006/02/21 14:36:18 UTC
DO NOT REPLY [Bug 38733] New: - mod_access doesn't obey any allow/deny rules when using a limit connect statement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
Summary: mod_access doesn't obey any allow/deny rules when using
a limit connect statement
Product: Apache httpd-2
Version: 2.0.55
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Core
AssignedTo: bugs@httpd.apache.org
ReportedBy: makezi@luukku.com
I just found out a new bug/feature(!) concerning mod_access and location/limit
statements. If applied, no error messages will be printed, and the errorcode 403
will NEVER be sent. Actually, ALL access will be granted despite of any access
rules set. Administrator doesn't get any clue whatever about the possible
security hole, or where to look a solution for it. Log files will report
"correctly" code200 for all files requested/got (should be 403 and denied).
When using the statement below to deny the connect method, ALL mod_access checks
are neutralized in a way that mod_access will only check if a user is allowed to
see the files in a directory tree. When autoindex is used, it will still display
a directory HEADER/FOOTER and the hr-lines, but hides all the files between. If
the user knows the correct file name, mod_access does absolutely NOTHING despite
of any "deny from all" rules.
Critical httpd.conf section follows:
<Location />
<Limit CONNECT>
Order deny,allow
Deny from all
</Limit>
</Location>
Access rules used:
Order deny,allow
Deny From All
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
------- Additional Comments From makezi@luukku.com 2006-02-21 16:58 -------
As the limit restricts only CONNECT method, how does that affect to GET method
as well? There is no previous rules set for CONNECT, and I really wanted to
eliminate the whole method (it's irrelevant here why). The same problem affects
to LimitExcept too. I think this problem should be documented somehow.
This can be fixed by moving the same Limit block under all directory statements,
and making sure that .htaccess is not allowed to override limits, but that kinda
sucks. Location definition would be so easy way to set global blocking, i.e. no
PUT/CONNECT/DELETE/etc. methods allowed for entire server (dozen virtualhosts).
But obviously that doesn't work...
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
nd@perlig.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From nd@perlig.de 2006-02-21 16:16 -------
One could say, it's a design problem, a well known, though.
You configuration says, literally:
Deny all URLs beginning with /, but only if the HTTP method is CONNECT. This
overrides any rules before - as usual. But not what you obviously have expected
in this case.
We're not gonna change the configuration mechanism in 2.0. There's a lot of work
going on in the 2.3 development branch, though.
Solution in your case: Alaways test you access configurations. Drop the
CONNECT-403 thing. It's not necessary at all (and obviously jeopardizes your
whole config).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
------- Additional Comments From makezi@luukku.com 2006-02-22 13:05 -------
(In reply to comment #4)
> The problem is that mod_access lumps its configuration together with a method
> list. If no <limit> is set, all methods are implicitly in this list. Now you
> have a <Location> container, which overrides both the configuration *and* the
> method list. Bang.
This is the caveat that should be documented on Limit description.
For Ruediger, let me explain it a little further, although I think you guys are
already aware of the problem, which is most important now (as this can be
avoided). Still irrelevant here is why somebody would want to configure it this
way. The point is that administrator doesn't expect that limit statement to
affect to any acl lists, and the mistage is only identified by somebody who is
normally denied access.
An example of my configuration follows, the critical section first:
-- httpd.conf:
<Location />
<Limit DELETE PUT> (whatever here, except GET)
Order deny,allow
Deny from all
</Limit>
</Location>
NameVirtualHost *:80
<VirtualHost *:80>
ServerName testing.local
DocumentRoot /www/docs
<Directory /www/docs>
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
allow from all
</Directory>
...
</VirtualHost>
-- /www/docs/secure/.htaccess (simplified for easy testing)
order deny,allow
deny from all
-- contents of /www/docs/secure/
README
secret.txt
a/whatever.html
b/
--
* Web browser going to /secure sees README printed on top, but EMPTY folder
(still gets code 200!). The directory seems really to be empty. Error logs
however complain:
[error] [client ...] client denied by server configuration: /www/docs/secure/a
[error] [client ...] client denied by server configuration: /www/docs/secure/b
[error] [client ...] client denied by server configuration:
/www/docs/secure/secret.txt
* /secure/secret.txt -> code 200, opened normally!
* /secure/a/ -> code 200, normal directory listing
* /secure/a/whatever.html -> code 200, opened normally
The most interesting part is the first one, where directories and files will get
identified as denied (and hidden), but nothing is actually done. So this really
is different from default (hidden) statement which would override htaccess
restrictions with "allow from all".
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
------- Additional Comments From rpluem@apache.org 2006-02-21 22:22 -------
I am not sure if I understand your problem correctly, so could you please post a
larger part of your configuration that contains the neutralized mod_access checks?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
------- Additional Comments From makezi@luukku.com 2006-02-22 13:11 -------
Oh, btw. if that location/limit statement is set, there's no difference putting
the same .htaccess contents to httpd.conf. So the problem is not associated with
.htaccess in any way.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
------- Additional Comments From rpluem@apache.org 2006-02-22 23:19 -------
Meanwhile I understand the problem much better. So the configuration I proposed
in #5 actually works as expected. What one has to keep in mind is that if there
are configuration directives from the same module (access in this case) for a
resource that could be taken from either a Directory container that matches the
resulting physical resource (file) or a Location container that matches the
virtual resource (URL), httpd always takes the configuration from the matching
Location container. So it does not seem to be a good idea to me to mix Directory
and Location containers for the same configuration directives (like access
control in this case) as this might lead to unexpected results. .htaccess is
seen in the same way as a Directory container in this context.
So general configuration alternatives seem to be the following for me:
1. Do everything with Location (does not play well with .htaccess)
2. Try to create the general rules (like the limit in your case) with
DirectoryMatch or maybe even <Directory />. This should work with .htaccess
BTW: Something very similar to your configuration can be found at the end of
http://httpd.apache.org/docs/2.0/sections.html as something that does not work.
So it seems already documented. But as you can see from my questions here I also
did not know before :-).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
------- Additional Comments From rpluem@apache.org 2006-02-21 23:08 -------
(In reply to comment #4)
> The problem is that mod_access lumps its configuration together with a method
> list. If no <limit> is set, all methods are implicitly in this list. Now you
> have a <Location> container, which overrides both the configuration *and* the
> method list. Bang.
Ok. Maybe I am a bit slow today, so that I don't get it :-).
mod_access lumps this together in access_dir_conf, but this is a dir config.
So
<Location />
<Limit CONNECT>
Order deny,allow
Deny from all
</Limit>
</Location>
<Location /noentry>
Order deny,allow
Deny from all
</Location>
should prevent all access to /noentry (what I regard as expected).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38733] - mod_access doesn't obey any allow/deny rules when using a limit connect statement
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38733
------- Additional Comments From nd@perlig.de 2006-02-21 22:37 -------
The problem is that mod_access lumps its configuration together with a method
list. If no <limit> is set, all methods are implicitly in this list. Now you
have a <Location> container, which overrides both the configuration *and* the
method list. Bang.
Funnily the httpd only allows methods it can deal with (and rejects the other
ones with 405). I bet, you have PHP or something installed, which doesn't care
at all for the requested method (and the scripts don't either). This is the
reason why you want to forbid some methods. I don't understand the reason, but I
don't have to ;-)
An alternative way to forbid methods, is setting up mod_rewrite, like
RewriteCond %{REQUEST_METHOD} =CONNECT
RewriteRule ^ - [F,L]
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org