Bug 28515 - A reference to a broken symbolic link results in a "broken" error response page.
Summary: A reference to a broken symbolic link results in a "broken" error response page.
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.0.49
Hardware: Sun Solaris
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
: 36716 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-21 15:01 UTC by Rolf Sponsel
Modified: 2008-02-19 14:29 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rolf Sponsel 2004-04-21 15:01:54 UTC
The verify this, to the best of my knowledge, after having performed a clean
installation of httpd 2.0.49 (using the default 'httpd.conf' file) I created
three additional file system entries in the directory 'htdocs', being part of
the standard httpd distribution, as follows:

cd htdocs
ln -s index.html.var SYMLINK
ln -s non-such-file BROKEN-SYMLINK
touch READ-PROTECTED-FILE
chmod 600 READ-PROTECTED-FILE

After starting the httpd daemon, I accessed the server by entering the following
 URLs into my browser (Mozilla):

1). http://192.168.0.100/
      which renders the Test Page for Apache Installation.

2). http://192.168.0.100/NO-SUCH-FILE
      rendering a std '404 Not Found' response like this (which is okay):

> Not Found
> 
> The requested URL /NO-SUCH-FILE was not found on this server.
> Apache/2.0.49 (Unix) Server at 192.168.0.100 Port 80

3). http://192.168.0.100/READ-PROTECTED-FILE
      rendering a std '403 Forbidden' response like this (which is also okay):

> Forbidden
>
> You don't have permission to access /READ-PROTECTED-FILE on this server.
> Apache/2.0.49 (Unix) Server at 192.168.0.100 Port 80

and finally

4). http://192.168.0.100/BROKEN-SYMLINK
      rendering a std '403 Forbidden' response like this (which seems a little
broken to me):

> Forbidden
>
> You don't have permission to access /BROKEN-SYMLINK on this server.
>
> Additionally, a 403 Forbidden error was encountered while trying to use an
ErrorDocument to handle the request.
> Apache/2.0.49 (Unix) Server at 192.168.0.100 Port 80


That "Additional" 403 error indicates a reference to a document just as if the
server wanted to reference a 'Customized Error Response' document, usually
defined by an 'ErrorDocument' directive, to wich it doesn't have access. This
although we have *not* enabled (at least not explicitly) the use of 'Customized
Error Responses'.


To verify that the problem is not that we wouldn't be allowed to follow symlinks
in the 'htdocs' directory, you could use:

http://192.168.0.100/SYMLINK


And this is what can be found in the 'error_log' file:

[Wed Apr 21 16:08:18 2004] [error] [client 192.168.0.101] File does not exist:
/usr/local/apache2/htdocs/NO-SUCH-FILE
[Wed Apr 21 16:08:35 2004] [error] [client 192.168.0.101] (13)Permission denied:
file permissions deny server access: /usr/local/apache2/htdocs/READ-PROTECTED-FILE
[Wed Apr 21 16:08:59 2004] [error] [client 192.168.0.101] Symbolic link not
allowed: /usr/local/apache2/htdocs/BROKEN-SYMLINK


An issue seems to be burried here somewhere.

Please come back to me if you should need more information on this.


Best Regards,
Rolf Sponsel


Ps. There probably is another issue, which initially triggered my investigation
of this, that could be related to this issue. But that I'll first have to track
down a little further, and report it as an separate issue. Once I have done that
I'll, if I don't have forgotten it by then, add a reference to to this report
(and vice versa). Need to take one step at a time :-)
Comment 1 Rolf Sponsel 2004-04-21 15:07:23 UTC
I Forgot to mention that I acctually changed one thing in the standard
httpd.conf file. The 'GroupId' directive was changed from '#-1' to 'nobody'.

Best Regards,
Rolf Sponsel
Comment 2 Rolf Sponsel 2004-04-21 16:45:13 UTC
I have now studied that *other* issue mentioned at the end of my first post, and
have come to the conclusion that it's very likely to be related to the problem
initially posted. And therefore have decided to append it to this issue.

I also have raised the severity because, under unfortunate circumstances, it
could become - if not a security issue, then at least - an *integrity* issue.

If you follow the same steps as described in my initial posting after having
enabled the 'Customized Error Responses' feature you will notice that in the
case with the broken link the standard error response is displayed instead of
the customized one, one would expect.


Why this might lead to an *integrity* issue?

I noticed this problem in the process of "hiding" any error responses returned
due to non-authorized access attempts, e.g. made by a"harvesting" web-crawler
attempting to gain access to information by visiting a site via an it's
IP-Address, and which will reveal information, e.g. the email address of the
system's administrator, etc. And until this has been fixed it could, under
unfortunate circumstances, lead to the revealing of more information than
intended, by accident.


As always, feel free to ask for complimentary information concerning this.

Best Regards,
Rolf Sponsel

Comment 3 Joshua Slive 2005-09-09 21:59:57 UTC
This same confusing error message is returned if you symlink to a path where a
parent directory is not searchable by the web server user.

I believe the problem is that any error returned by an apr_stat on the symlink
is treated as "symlink not allowed".  Instead, the real error from apr_stat
should be propogated to the error log.  (But this wouldn't fix the "Additionally
..." error to the browser.)
Comment 4 Joshua Slive 2005-09-10 18:38:26 UTC
SVN rev 280018 makes the error message a little more accurate but doesn't fix 
any of the other problems mentioned in this bug.
Comment 5 Joshua Slive 2005-09-19 22:06:46 UTC
*** Bug 36716 has been marked as a duplicate of this bug. ***
Comment 6 Nick Kew 2008-02-19 14:29:42 UTC
This bug doesn't happen on 2.2.8 - marking fixed.

I haven't tested 2.0.current.  If that's not fixed, it's unlikely anyone'll want
to put the effort in, so I'd suggest not reopening unless you're attaching a patch.