On Mon, Jun 26, 2017 at 5:34 PM, Yann <[email protected]> wrote: > On Mon, Jun 26, 2017 at 11:51 PM, William A Rowe Jr <[email protected]> > wrote: >> On Mon, Jun 26, 2017 at 4:44 PM, William A Rowe Jr <[email protected]> >> wrote: >>> >>> On Mon, Jun 26, 2017 at 3:40 PM, Gregg Smith <[email protected]> wrote: >>>> >>>> On 6/24/2017 10:02 AM, William A Rowe Jr wrote: >>>>> >>>>> On Sat, Jun 24, 2017 at 12:49 AM, <[email protected]> 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.
Howso? > What could be the "security blunders" with 404 vs 403? A 403 says "go away, you are denied". Hopefully modules are smart about that. A 404 says "no such resource". Modules such as mod_speling try to interpret what the user typed in an accommodating way, and come up with something that aught to be served instead. In the general example, /indez.html might be recognized as /index.html. In the particular example, /CON (device) might be interpreted as /.conf (file). But if the admin/author is attentive, they deny access to .conf and the remap attempt fails. What I'm wondering is whether we should offer an early "Absolute 404" state that informs modules not to try to recover, or whether we should offer a late 403->404 anonymization feature?
