From: "Sebastian Bergmann" <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 2:24 PM
> Hi there,
>
> I just updated to 2.0.25 on my Win32 system, where I have the
> following lines in the httpd.conf to use PHP 4 as CGI
>
> ScriptAlias /php/ "e:/server/php/"
> AddType application/x-httpd-php .php
> Action application/x-httpd-php "/php/php.exe"
> Action application/x-httpd-php-source "/php/php.exe"
>
> This worked fine until now. Now I only get an
>
> The requested URL /php/php.exe/index.php was not found on
> this server.
>
> error when trying to access /index.php.
>
> Were there any changes that I might have missed?
Yes, the directory negotiation and AddType handling. I need to walk back
now and look at the action directive. Perhaps I interfered with it, or
perhaps it's interfering with my patch.
I hope to have an answer today.
Also - note that names are -heavily- canonicalized now, so it's possible
that something that just 'slipped through' in spite of one of the
ap_os_canonicalize_filename flavors is now caught. Likewise, I've tried
to catch every abuse of ap_make_full_path and toggle it to apr_filepath_merge,
leaving ap_make_full_path stuff to merge URIs. I may have missed the correct
choice to treat-as-uri, or to treat-as-path.
Finally, ap_directory_walk now insists on real file names. If a module will
circumvent the filesystem (e.g. it invents a bogus filename _just to get by_,
we should now catch that.) An entry should appear in your error log.
If a module (or an action - I'll look!) needs to bypass the filesystem to do
funny business, that's fine, it just returns an OK result code from the new
map_to_storage hook (register it simply as APR_HOOK_MIDDLE) if it can claim
the request.
This alone should eliminate entire classes of security advisories that have
revolved around canonical paths, 'tricking the server' into serving instead
of parsing dynamic content, etc. More work remains, but this was the underpinning.
Bill
