debian.apache.txt

`An issue with Apache on Debian  
  
Andrei D. Caraman ([email protected])  
Mon, 5 Apr 1999 19:53:35 +0300   
  
[ Aleph1,  
  
I don't remember this being posted on Bugtraq, but feel free to  
kill it, if it's yesterday's news. ]  
  
  
This pertains to the Apache configuration as shipped with Debian 2.1  
(codename slink).  
  
The default setup of Apache (apache_1.3.3-7.deb) makes the /usr/doc  
directory available to anyone as http://some.host/doc/. The relevant  
line is in the srm.conf file:  
  
Alias /doc/ /usr/doc/  
  
That would allow any user from the net (malicious or not) to know the  
exact version of the software packages installed on a Debian box. It  
looks more of a privacy issue then a security one. However, if a  
security vulnerability affecting any of those packes is found, attackers  
may already know which targets to hit (and maybe the ones to be avoided).  
  
At first I thought that alias should be disabled, but upon further  
reading the lines below (`The above line is for Debian webstandard 3.0,  
which specifies that /doc refers to /usr/doc. Some packages may not  
work otherwise.') I'd say that access to that location should be only  
allowed from localhost (note that a web proxy on the same machine might  
render that limitation useless). The site administrator could easily  
change that if he/she so needs.  
  
  
Johnie Ingram (the Apache maintainer for Debian) has been notified, and  
replied that this was already formally reported on the Bug Tracking System  
by another Debian user (details available here:  
  
http://www.debian.org/Bugs/db/34/34099.html  
  
including this suggested fix:  
  
<Directory /usr/doc>  
AllowOverride None  
order deny,allow  
deny from all  
allow from localhost  
</Directory>  
)  
  
Johnie said he intended to change the old default it in the following  
release.  
  
On March 26 he also stated that a new apache deb package was to be  
uploaded on the following day, so I suppose it has already made it's  
way to the Debian mirrors.  
  
<propaganda>  
  
This is not a serious bug, since the Debian is the safest Linux  
distribution. That's why I'm using it.  
  
</propaganda>  
  
I haven't bothered to check other distributions...  
  
  
  
Regards,  
---------------------------------------------------------------  
Andrei D. Caraman phone: +40 (1) 2050 637  
Network Engineer fax: +40 (1) 2050 655  
Mediasat SA office hours: 10:00 - 18:00 GMT  
  
----------------------------------------------------------------------------  
  
BOA was: An issue with Apache on Debian  
  
Stephen Gregory ([email protected])  
Mon, 5 Apr 1999 16:18:05 -0300   
  
FYI:  
  
The Debian Boa package, a (very) lightweight web server, does this as  
well. Version 0.93.16.1-1, Debian 2.2 (unstable/potato). Due to boa's  
limited configurability I think the best option is to disable the  
redirect. The relavent line in /etc/boa/boa.conf is  
  
#Alias /doc /usr/doc  
  
  
  
The maintainer will be notified via Debian bug tracking.  
  
--  
Stephen Gregory  
  
  
  
On Mon, Apr 05, 1999 at 07:53:35PM +0300, Andrei D. Caraman wrote:  
> The default setup of Apache (apache_1.3.3-7.deb) makes the /usr/doc  
> directory available to anyone as http://some.host/doc/. The relevant  
> line is in the srm.conf file:  
>  
> Alias /doc/ /usr/doc/  
>  
  
----------------------------------------------------------------------------  
  
Re: BOA was: An issue with Apache on Debian  
  
Leszek Gerwatowski ([email protected])  
Thu, 8 Apr 1999 10:09:45 +0200   
  
On Mon, Apr 05, 1999 at 04:18:05PM -0300, Stephen Gregory wrote:  
> FYI:  
>  
> The Debian Boa package, a (very) lightweight web server, does this as  
> well. Version 0.93.16.1-1, Debian 2.2 (unstable/potato). Due to boa's  
> limited configurability I think the best option is to disable the  
> redirect. The relavent line in /etc/boa/boa.conf is  
>  
> #Alias /doc /usr/doc  
>  
>  
>  
> The maintainer will be notified via Debian bug tracking.  
>  
> On Mon, Apr 05, 1999 at 07:53:35PM +0300, Andrei D. Caraman wrote:  
> > The default setup of Apache (apache_1.3.3-7.deb) makes the /usr/doc  
> > directory available to anyone as http://some.host/doc/. The relevant  
> > line is in the srm.conf file:  
> >  
> > Alias /doc/ /usr/doc/  
> >  
  
When I notified maintainer of Debian Apache package about this issue he  
answered that this alias is required in every Debian packaged web server  
by Debian packaging policy and if I want to report it as a bug I should  
change first the policy. But I've chosen to comment one line in srm.conf ;-)  
  
  
--  
o------------------o ___  
|Leszek Gerwatowski| _/_|_\  
o------------------o (o\__/o)=)))))))))))))  
"It took the computing power of three C-64s to fly to the Moon.  
It takes a 486 to run Windows 95. Something is wrong here."  
  
----------------------------------------------------------------------------  
  
Re: BOA was: An issue with Apache on Debian  
  
Martin Stjernholm ([email protected])  
Sun, 11 Apr 1999 21:10:15 +0200   
  
Leszek Gerwatowski <[email protected]> wrote:  
  
/.../  
> > On Mon, Apr 05, 1999 at 07:53:35PM +0300, Andrei D. Caraman wrote:  
> > > The default setup of Apache (apache_1.3.3-7.deb) makes the /usr/doc  
> > > directory available to anyone as http://some.host/doc/. The relevant  
> > > line is in the srm.conf file:  
> > >  
> > > Alias /doc/ /usr/doc/  
> > >  
>  
> When I notified maintainer of Debian Apache package about this issue he  
> answered that this alias is required in every Debian packaged web server  
> by Debian packaging policy and if I want to report it as a bug I should  
> change first the policy. But I've chosen to comment one line in srm.conf ;-)  
  
This has already been reported as a security issue in the Debian  
policy almost ten months ago; see bug report #23661  
(http://www.debian.org/Bugs/db/23/23661.html). The dhttpd package  
exposes the same problem (naturally, as it's a good policy-following  
Debian package) by making a symlink from /usr/doc to /var/www/doc.  
That has been reported in #23659.  
  
The response so far has been that eliminating this is merely "security  
by obscurity", and that it therefore isn't a real security issue. I  
disagree; it's more comparable to shadow passwords as a security  
measure. It's in any case an obvious help for doing large scans for  
vulnerabilities; among other things the risk of getting noticed in  
logs is much smaller.  
  
Being a "metabug", i.e. a bug in the policy, accentuates it even more  
since packages _have_ to implement this weakness and activate it by  
default.  
  
----------------------------------------------------------------------------  
  
Re: BOA was: An issue with Apache on Debian  
  
[email protected]  
Tue, 13 Apr 1999 12:56:59 -0000   
  
  
  
I know I don't have the same credentials as some of the net.gods  
that post here, but as a maintainer of the web server Boa, and a  
generally active *nix user/programmer/admin who cares about  
security, I'd like to weigh in on the subject of web server setup  
and more general issues of computer security technique. I hope  
this essay doesn't come across as too pedestrian or long-winded.  
  
There is certainly some value in not leaking machine configuration  
onto the net at large. In a perfect world, it wouldn't matter,  
but people and their software are not perfect [1].  
  
OTOH, you would rightly ignore an assertion that zyxmail was  
insecure, because any user on the system can use it to send a  
copy of /etc/passwd to alt.2600. Hey, you're the one who gave  
the luser an account, you can yank it too. Why, then, should  
one be concerned that a user can "ln -s / $HOME/public_html"?  
  
I know Apache can be configured to not follow symbolic links from  
user directories [2]. Many other programs, Boa included, don't  
attempt to recreate or second guess the protection mechanisms built  
into the OS they run under. This is a personal beef I have with  
people who ask for, and programmers that provide, bloated programs.  
  
Daemons run with the uid/gid selected by the sysadmin [3],  
typically an "unprivileged user" [4]. The nominal expectation  
should be that remote users of a such a daemon can make it take  
any action on their behalf, limited by the permissions of that  
uid/gid. This is certainly true of Boa when semi-untrusted users  
are given control over part of the web virtual space, such as  
with the usual $HOME/public_html mechanism. It is also true of  
any daemon that has an exploitable buffer overflow bug; containing  
such attacks is a big motivation for using an untrusted uid in the  
first place.  
  
My recommendation: if you have semi-untrusted users on your system,  
and you consider some configuration files sufficiently sensitive  
that you don't want them splattered all over the internet, don't  
protect them 755 [5].  
  
There are times when a webserver should show a different virtual  
spaces depending on from where the request comes in -- e.g., local,  
intranet, or big bad world [6]. I suspect this concept has to make  
it into the Debian web policy, in particular to show /doc to local  
users, but not the outside world. Of course, Apache can do that.  
With minor tweaks or hacks, most other web servers can too [7].  
  
I have learned that the *nix security model, while less than perfect,  
is far more adaptable and flexible than most people give it credit  
for. Don't ignore it or fight it, use it to your advantage.  
  
- Larry Doolittle <[email protected]>  
  
  
[1] It is actually quite reassuring that we have the time to  
worry about subtle information leakage. It doesn't seem like  
too long ago that bugtraq was full of instant remote root exploits.  
  
[2] Of course, to implement this, Apache stat()'s every  
component of the path on every request.  
  
[3] Or system integrator. People who put a Red Hat or other  
preconfigured system live on the 'net without investigating  
what's really there are fools.  
  
[4] Historically nobody/nogroup. This is arguably overused.  
A more modern setup allocates a specific uid/gid for each task.  
  
[5] I personally get frustrated trying to make such a machine  
work (in a mortal user role), because I can't self-diagnose  
problems. I found a "final solution" to this problem many years  
ago, now I have root privileges on my own machine.  
  
[6] Based on IP number, not name, of course. DNS is too slow  
for me, and raises security questions of its own.  
  
[7] I haven't checked how easy it is with the features of the Debian  
version of Boa. If someone tells me it's needed and will be used,  
_and_ gives a useful description of how to configure it, I can  
certainly program it. Test and internal use copies of Boa have  
already implemented features along this line.  
  
----------------------------------------------------------------------------  
  
Re: An issue with Apache on Debian  
  
Karellen ([email protected])  
Fri, 9 Apr 1999 00:48:14 +0300   
  
On Mon, Apr 05, 1999 at 07:53:35PM +0300, Andrei D. Caraman wrote:  
> That would allow any user from the net (malicious or not) to know the  
> exact version of the software packages installed on a Debian box. It  
  
That reminds me of something else. On Debian 2.0, after I read the Apache  
manual I tried that neat example they suggest 'ln -s / ~/public_html'  
lynx http://localhost/~username -- I actually got to see my root directory!  
Any user with shell acess could do this and allow people browse through your  
/etc, /home and what not. To fix this, add the following lines to the top of  
your /etc/apache/apache.conf.  
  
<Directory />  
AllowOverride None  
Options None  
Order deny,allow  
Deny from all  
</Directory>  
  
I had someone confirm this for me, and I got a positive answer.  
The package maintainer has been notified. I am using v1.3.3-4.  
  
----------------------------------------------------------------------------  
  
Re: An issue with Apache on Debian  
  
Mikael Willberg ([email protected])  
Fri, 16 Apr 1999 17:48:14 +0300   
  
On Fri, 9 Apr 1999, Karellen wrote:  
>  
> That reminds me of something else. On Debian 2.0, after I read the Apache  
> manual I tried that neat example they suggest 'ln -s / ~/public_html'  
> lynx http://localhost/~username -- I actually got to see my root directory!  
> Any user with shell acess could do this and allow people browse through your  
> /etc, /home and what not. To fix this, add the following lines to the top of  
> your /etc/apache/apache.conf.  
>  
> <Directory />  
> AllowOverride None  
> Options None  
> Order deny,allow  
> Deny from all  
> </Directory>  
  
I don't know what kind of configuration comes with Debian, but I suggest  
replacing "FollowSymLinks" option with "SymLinksIfOwnerMatch" option to  
prevent symlink misuse. This option makes the server follow symbolic links  
only if the link is owned by the same UID as the terget of the link. And  
here is a little example:  
  
<Directory /home>  
...  
Options ... SymLinksIfOwnerMatch ...  
...  
</Directory>  
  
  
Mig  
  
--  
**** Mikael Willberg ***** "Oh dear", says God, "I hadn't thought of that" **  
* Hypermedia laboratory * and promptly vanishes in a puff of logic. *  
* University of Tampere * (Douglas Adams) *  
******** Finland ********* http://www.uta.fi/~tymiwi/ ***********************  
  
`