https://bz.apache.org/bugzilla/show_bug.cgi?id=70190

            Bug ID: 70190
           Summary: Failed basic auth does not return 401 on broken
                    symbolic link etc.
           Product: Apache httpd-2
           Version: 2.4.68
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

By default, Apache httpd-2 gives 401 response when HTTP basic auth fails.
However, the document tree is traversed before checking basic auth. Under
certain circumstances (e.g. broken symbolic link) httpd gives 403 response.

Way to reproduce:

0. I am using Debian 13 (Linux). This bug is likely reproducible on other Linux
distributions.
1. Compile and install httpd-2.4.68 following the `INSTALL` file.
2. Update `PREFIX/conf/httpd.conf` to configure basic auth

```
<Directory "PREFIX/htdocs">
        # Add the following 4 lines.
        AuthType Basic
        AuthName "Authentication Required"
        AuthUserFile "/dev/null"
        Require valid-user
        # ...
        # Replace "Require all granted" with the following 2 lines.
        Order allow,deny
        Allow from all
</Directory>
```

3. Run the following bash script to prepare the htdocs folder

```
cd PREFIX/htdocs
(mkdir a; echo '<title>200</title>' > a/a)
(mkdir b)
(mkdir c; ln -s not_exist c/c)
(mkdir d; touch d/d; chmod 000 d)
(
        mkdir e
        cd e
        touch 0
        for i in {1..512}; do ln -s $((i-1)) $i; done
        ln -s $i e
)
```

4. Restart httpd: `PREFIX/bin/apachectl restart`
5. Access the files without any credentials

```
for i in a b c d e; do
        echo $i/$i
        curl -s http://127.0.0.1/$i/$i | grep title
done
```

Expected behavior:

- For all files, see 401 response. (This is the behavior of nginx.)

Actual behavior:

- a/a: 401 response (normal file).
- b/b: 401 response (file does not exist).
- c/c: 403 response (broken symbolic link).
- d/d: 403 response (parent directory without permission).
- e/e: 403 response (too many levels of symbolic links).

Error log messages:

```
[core:error] [pid 912:tid 979] [client 127.0.0.1:50870] AH00037: Symbolic link
not allowed or link target not accessible: PREFIX/htdocs/c/c
[core:error] [pid 914:tid 987] (13)Permission denied: [client 127.0.0.1:50876]
AH00035: access to /d/d denied (filesystem path 'PREFIX/htdocs/d/d') because
search permissions are missing on a component of the path
[core:error] [pid 914:tid 991] [client 127.0.0.1:50884] AH00037: Symbolic link
not allowed or link target not accessible: PREFIX/htdocs/e/e
```

Additional information:

I have performed preliminary debugging on this bug. See the relevant stack
trace below. `ap_run_map_to_storage` traverses the directory, then
`ap_run_access_checker_ex` performs the basic auth check. However, for a broken
symbolic link `ap_directory_walk` returns 403 directly, so
`ap_run_access_checker_ex` is never called.

```
ap_process_request_internal
        ap_run_map_to_storage
                core_map_to_storage
                        ap_directory_walk
        ap_run_access_checker_ex
                authorize_userless
                        authorize_user_core
```

In certain cases I think this bug can lead to security concerns. The attacker
is assumed to be someone who can access the website but does not have valid
basic auth credentials. For example:

- By guessing the paths, the attacker can gain information about the document
tree (e.g. existence of broken symbolic link).
- There is a covert channel between someone who can modify the document tree
(sender) and the attacker (receiver).
- The attacker may launch a denial of service attack if the document tree is on
a slow file system.
- If the document tree is on a slow file system, the attacker may observe the
speed of 401 responses. The attacker can guess directory names and build a tree
of all directories in the document tree.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to