httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Anonymizing 403 responses [Was: svn commit: r1799731]
Date Mon, 26 Jun 2017 21:51:11 GMT
On Mon, Jun 26, 2017 at 4:44 PM, William A Rowe Jr <> wrote:
> On Mon, Jun 26, 2017 at 3:40 PM, Gregg Smith <> wrote:
>> On 6/24/2017 10:02 AM, William A Rowe Jr wrote:
>>> On Sat, Jun 24, 2017 at 12:49 AM,  <> wrote:
>>> While we are at it, why even forking WIN32? If you want to prevent
>>> APR_CHR files on Windows (or netware or os2 or...) from being
>>> identified, why wouldn't you simply change the behavior across all
>>> architectures with a new test case ahead of the != APR_DIR check...
>>>              else if (thisinfo.filetype == APR_CHR) {
>>>                  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
>>>                                "Forbidden: %s points to a char stream path",
>>>                                r->filename);
>>>                  return r->status = HTTP_NOT_FOUND;
>>>              }
>> Uh yes, but as shown up front the 404 is what we'd get on Unix and forcing
>> it 404 is what I was doing while improperly.
> No no no. Unix has CHR devices!!! You can mount them whereever, by
> convention they all live under /dev/. But that doesn't mean they cannot
> be found elsewhere. Unix httpd will 403 on these.
> We should consider if it's worthwhile "hiding" CHR references under some
> response 404, but ***ONLY*** if we can assert this is a terminal 404, not
> a recoverable 404. We don't have such a construct yet in httpd, AFAIK.
>>> Let's please back out that patch entirely and start again by asking
>>> the question, do we want to treat CHR file paths as not found rather
>>> than forbidden, and does anyone see an opportunity for httpd's
>>> core or third party modules to proceed to try to work around that
>>> file/path leading to potential security blunders? E.g. mod_speling?

So coming back to this core question, what would be the workaround
to force a 'final determination' of a 404 NOT FOUND in place of any
security-related 403's? E.g. if we trip over a disallowed symlink, 403,
if we trip over a CHR file, 403... but admin wants to present a 404
instead. This must happen after all modules have looked at the 403
and stepped out of the way, as opposed to trying to substitute content
in the 404 case.

This seems doable, IMO.

View raw message