>Number: 3139 >Category: other >Synopsis: [PATCH] disallow access to hard linked files >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: change-request >Submitter-Id: apache >Arrival-Date: Mon Oct 5 04:10:00 PDT 1998 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.3.2 >Environment: % uname -a SunOS povondra 5.6 Generic sun4u sparc SUNW,Ultra-1 % gcc -v Reading specs from /export/tools/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version 2.8.1 >Description: Thanks to Apache's "SymLinkIfOwnerMatch" Option, it's possible to protect against content authors trying to get around UNIX's security by creating a soft link to a protected file and using Apache to display the file.
There is currently no fix for hard links. I have come across this on a server running as root (!), where a quick % ln /etc/shadow ~/public_html/shadow Allowed all to read the contents of /etc/shadow through http://server/~me/shadow The answer to this specific problem is never to run a server as root, and to make sure that any sensitive files readable by Apache (but not users) are not in a user-readble directory on the same file system as a user-writable part of the document tree. (Another example: Apache's log files may be considered sensitive - and therefore chmod 600'd to the web user - and are commonly on the same filesystem as the document tree.) >How-To-Repeat: On UNIX, assuming Apache runs as 'httpd' and another user, 'user' can write to the document tree: httpd% cd $DOCUMENT_ROOT/.. httpd% echo "user mustn't see this" > foo httpd% chmod 600 foo user% cd $DOCUMENT_ROOT user% ln ../foo bar The file 'foo' is now visible to the user at http://server/bar. Note: this is a real situation; some sites maintain password files (perhaps passwords for web authorisation) in stupid places - like on the same filesystem as the document tree. >Fix: Since a hard link cannot be distinguished from the original file, there's no way of implementing a HardLinkIfOwnerMatch option. However, we can tell when a file has more than one link through stat's st_nlink member. If the file isn't a directory and st_nlink > 1, a hard link has been created to the original file. (If it's a directory, st_nlink will always be > 1, and unless we look at the directory's contents, we have no way of knowing whether an extra hard link has been created, but that doesn't matter 'cause only root can hard link to directories, anyway.) The patch below modifies the behaviour of the 'AllowSymLinks' option. With said option not set, Apache refuses to serve files with a link count > 1. I wanted to introduce a new option to do this, but as you know we've run out of bits in the option structure. (An alternative to this patch would be to patch the documentation to warn of these rather esoteric cases, but I prefer the code, myself.) The patch has been tested on: apache_1.3.0 SunOS 5.6 sun4u apache_1.3.1 SunOS 5.6 sun4u apache_1.3.2 SunOS 5.6 sun4u (I'm sorry: I don't have access to other platforms.) --- apache_1.3.2/src/main/http_request.c Tue Aug 11 00:09:46 1998 +++ apache_1.3.2_no-hard-links/src/main/http_request.c Mon Sep 28 18:16:27 1998 @@ -153,9 +153,17 @@ * the like may cons up a way to run the transaction anyway)... */ - if (!(res >= 0) || !S_ISLNK(lfi.st_mode)) + if (!(res >= 0)) return OK; + /* Is it a hard linked file? (We can't tell about directories.) */ + + if (!S_ISDIR(lfi.st_mode) && (lfi.st_nlink > 1)) + return HTTP_FORBIDDEN; + + if (!S_ISLNK(lfi.st_mode)) + return OK; + /* OK, it's a symlink. May still be OK with OPT_SYM_OWNER */ if (!(opts & OPT_SYM_OWNER)) >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]
