httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann <ylavic....@gmail.com>
Subject Re: Anonymizing 403 responses [Was: svn commit: r1799731]
Date Mon, 26 Jun 2017 22:34:02 GMT
On Mon, Jun 26, 2017 at 11:51 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Mon, Jun 26, 2017 at 4:44 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>>
>> On Mon, Jun 26, 2017 at 3:40 PM, Gregg Smith <gls@gknw.net> wrote:
>>>
>>> On 6/24/2017 10:02 AM, William A Rowe Jr wrote:
>>>>
>>>> On Sat, Jun 24, 2017 at 12:49 AM,  <gsmith@apache.org> 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.

Why modules couldn't (or shouldn't) recover from such 404s like any other one?
If mod_speling is doing strange things when substituting what it
thinks is a typo (like serving hidden/forbidden files) that's
mod_speling's bug IMHO.
What could be the "security blunders" with 404 vs 403?


Regards,
Yann.

Mime
View raw message