> It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin
The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket.
a.srv ended up in PATH_INFO because index.html existed.
The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.
MultiViews doesn't let HTML files have PATH_INFO by default. Only files that Apache considers "scripts" get PATH_INFO (e.g., .php). Therefore /index.html/a.srv would normally return 404 Not Found, even with MultiViews on.
They could have done further configuration to let HTML files take PATH_INFO, but this Rube Goldberg machine of multiple mistakes bears no more connection to MultiViews than mod_rewrite. In fact, I see no mention in the article of MultiViews or its module, mod_negotiation. So how do we know they were using MultiViews and not mod_rewrite, which people use much more often for this amount of indirection?
Either way, this exploit is impossible in the original suggestion, to just use MultiViews with PHP files to remove the ".php"
The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket.
a.srv ended up in PATH_INFO because index.html existed.
The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.