Not a bug Full Path Disclosures in Error Handling

[pegasus]

I made some manual changes to a XenForo file to see what the paths look like in the error output:

An exception occurred: Undefined variable: test1 in /home/vw/public_html/xf/library/XenForo/ViewPublic/Forum/List.php on line 17

1. XenForo_Application::handlePhpError() in XenForo/ViewPublic/Forum/List.php at line 17
2. XenForo_ViewPublic_Forum_List->renderHtml() in /home/vw/edge/upload/library/vw/XenForo/ViewPublic/Forum/List.php at line 66
3. vw_XenForo_ViewPublic_Forum_List->renderHtml() in XenForo/ViewRenderer/Abstract.php at line 227
4. XenForo_ViewRenderer_Abstract->renderViewObject() in XenForo/ViewRenderer/HtmlPublic.php at line 71
5. XenForo_ViewRenderer_HtmlPublic->renderView() in XenForo/FrontController.php at line 604
6. XenForo_FrontController->renderView() in XenForo/FrontController.php at line 158
7. XenForo_FrontController->run() in /home/vw/public_html/xf/index.php at line 13

This appears consistent with what I believed would happen after reviewing the code of XenForo_Error. But unfortunately, as you can see, a number of absolute paths appear with the user's account name. This is a vulnerability type referred to as Full Path Disclosure (FPD), which makes other types of attacks easier, because the account name is revealed.

In the current implementation, XenForo only hides the path to library/ files. As you can see in trace #7, the file that started the request (index.php) still shows the full path.

Also, in trace #2, an add-on that allowed me to specify the path where I keep its files (outsite XenForo's library dir) also has the path revealed. Apparently there is no way to notify XenForo's error handler of other paths.

While some argue that FPD is a server misconfiguration (such as XenForo's debug mode being turned on in production), many counter that if there is an opportunity to prevent that at the software level, that should also be done. I believe XenForo is in the second camp, because it bothers to hide the /library path already, and it provides .htaccess files for /library to prevent fatal errors when visiting the files directly. Still, here is one blog's discussion of FPD: http://blog.dewhurstsecurity.com/2011/10/05/full-path-disclosure-fpd.html

Aside from Parse Errors and Fatal Errors, this vulnerability can be largely avoided in XenForo by making the following changes:

1. Allow include paths to be registered with XenForo_Error. Something like:

   XenForo_Error::add_path('/hide/this/custom/path', '[replace it with this]')

   Then, when the error handler is called, replace all the registered paths with the replacement strings.
2. Register both the CWD and the library directory. Register any other paths you can customize in config.php.

Note also that even though the front-end currently hides some paths, the Server Error Logs page in the AdminCP hides none. I foresee there are many cases where the server administrator doesn't give a forum admin FTP access and would prefer that admins not know the full path. You hide passwords and auth tokens from these logs, so why not the absolute path too?

EDIT: I think I will also be taking this up with the developers of PHP, because leaks via the default error handlers (the error text of parse and fatal errors are not changeable and are not affected by include_path) contributes to a culture among PHP developers that diminishes the importance of full-path disclosures.

 

[Mike]

This isn't really something I would consider a full path disclosure because:

While some argue that FPD is a server misconfiguration (such as XenForo's debug mode being turned on in production)

This is absolutely a misconfiguration and something we never recommend. If you have debug mode on, an attacker can obtain much more information, including potentially secret values being inserted into the database. Further, beyond the full path, this is leaking a backtrace which may give further information.

Without debug mode on, we don't display error details/back traces to untrusted users. Note that an admin is always considered to be at least somewhat trusted. You mentioned the logs in the control panel showing the path. Even if we did, there are other ways an admin can determine the file path. We do not consider the file path to be something that needs to be hidden from an admin generally browsing, which would be distinct from passwords.

I believe XenForo is in the second camp, because it bothers to hide the /library path already, and it provides .htaccess files for /library to prevent fatal errors when visiting the files directly.

The paths being hidden is mostly out of avoiding it being overly verbose. Preventing library/ from being browsed does help prevent a full path disclosure there -- but that's a situation where we would have no control over the configuration. When XF's framework has been initialized, we can control what is displayed, so it goes back to the debug mode/trusted user elements.

If you can trigger a full path disclosure by an untrusted user in a file in the root directory, we do fix those. But I don't see a bug here as the out of the box and recommended configuration doesn't trigger anything when an error occurs.