3 ms·

Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in a

by sebcat 8y ago

Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in apache httpd you should be aware of this. [1] https://www.vdoo.com/blog/vdoo-discovers-significant-vulnerabilities-in-axis-cameras/ https://www.vdoo.com/blog/vdoo-discovers-significant-vulnera...

combatentropy 8y ago
If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't. 1. 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. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists. 2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661. 3. The attack then depended on a bug in dbus, CVE-2018-10662 4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection. So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.
- sebcat 8y ago
  > 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.
  - combatentropy 8y ago
    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"

by sebcat 8y ago

combatentropy 8y ago

If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't. 1. 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. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists. 2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661. 3. The attack then depended on a bug in dbus, CVE-2018-10662 4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection. So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.

sebcat 8y ago
> 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.
- combatentropy 8y ago
  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"