Bug#437658: apache: bad sideffects of Location+LimitExcept after upgrading Apache 1.3 from Sarge to Etch

Package: apache
Version: 1.3.34-4.1
Severity: normal

Hello,

after upgrading from Sarge to Etch I found following apache configuration directives to have a bad sideffect:

<Location />
<LimitExcept GET POST HEAD>
Order Allow,Deny
Deny from all
Satisfy all
</LimitExcept>
</Location>

FYI this config was the last in my conf.d directory as suggested by http://httpd.apache.org/docs/1.3/sections.html

The idea behind this directives is to globally disallow any request which is not POST, GET or HEAD. AFAIK this worked fine under Debian Sarge. Under Debian Etch this ignores all directives Order, Allow and Deny, even in .htaccess. This also affects access control using Oder, Allow and Deny in File-Sections which for instance disallow access to .htaccess files, such that .htaccess files get publicly accessible.

After removing these config everything worked fine again. However Apache now answers all HTTP commands, not only GET, POST and HEAD, which can be considered a lowered security on my server.

How to reproduce this problem (I did not test it on a fresh install):

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

Use the default install of Debian Etch with mod_userdir active. Then as some user (non-root) do:

mkdir public_html
cd public_html
cat >>.htaccess <<EOF
Order allow,deny
Deny from all
EOF
lynx "http://127.0.0.1/~$USER/.htaccess"

Access will be denied as expected.

As root create file /etc/apache/conf.d/test.conf with following contents:

Reload Apache. Try to access the .htaccess file again (as above). Under Sarge access still is denied (I think). Under Etch the contents of the .htaccess file is presented to your browser now.

You can revert to the correct behavior by removing /etc/apache/conf.d/test.conf and reloading Apache.

Notes:

Accessing .htaccess files publicly is not the only thing affected. When the Location+LimitExcept section is present, access control through .htaccess does no more work. So in the example above you would be able to access all files in public_html even that .htaccess shall deny access. Note that "Require" is not affected, only "Order, Allow, Deny". Perhaps there are even more sideeffects I did not notice.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

Unfortunately this problem was discovered on my last machine I upgraded to Etch. Only this machine had the problematic setup. I am not sure the last version of Sarge worked as intended before my upgrade, but I am pretty sure elder versions of Sarge worked as I usually test the .htaccess limitations. ;)
However I currently have no more Sarge running to cross-check.

Perhaps this behavior change is intended, however I consider this problem to be very weird. So I consider it a bug as LimitExcept shall not affect access control of *other* HTTP methods.

I was unable to find any similar bug in the Debian Bug database. Perhaps it's a mod_access bug. However LimitExcept and Location are in Apache core and mod_access is in package apache-common.

-Tino

• System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages apache depends on:

ii  apache-common               1.3.34-4.1   support files for all Apache webse
ii  debconf [debconf-2.0]       1.5.11       Debian configuration management sy
ii  libc6                       2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libdb4.4                    4.4.20-8     Berkeley v4.4 Database Libraries [
ii  libexpat1                   1.95.8-3.4   XML parsing C library - runtime li
ii  libmagic1                   4.17-5etch2  File type determination library us
ii  logrotate                   3.7.1-3      Log rotation utility
ii  lsb-base                    3.1-23.1     Linux Standard Base 3.1 init scrip
ii  mime-support                3.39-1       MIME files 'mime.types' & 'mailcap
ii  perl                        5.8.8-7      Larry Wall's Practical Extraction 

apache recommends no packages.

• debconf information:
  * apache/server-name: hydra.geht.net
  
  • apache/document-root: /var/www
  • apache/server-port: 80
  • apache/enable-suexec: false
  • apache/init: true
  • apache/server-admin: webmaster@20k.de

-- 
To UNSUBSCRIBE, email to debian-apache-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org