I was only referring to the actual case here. All the path tells you that there is a webroot at
/usr/local/apache2/htdocs/
a dir called roundcube/ and a page called index.php
So the info is:
- linux/unix system running apache2 (info is easily established otherwise)
- /usr/local exists (what a surprise )
- webroot is called htdocs (anotehr surprise )
- roundcube should already show in the URI as is index.php
You are so right, and yet so wrong...
Truth is you're quite right - in this specific case, on that specific server, a path disclosure is not a major risk. Those paths are going to be the first thing a hacker checks for. They don't need a path disclosure - other than to confirm it. Why give them that confirmation though?
You're also completely wrong. This is a security advisory - which usually means the PHP app tested is widely distributed. It is indeed therefore a real risk - either your server PHP ini has display_errors off, or that apps developer needs to compensate for the default in a shared hosting environment. Not everyone will have the default linux paths...many will be using virtual hosts which oddly offer a little extra protection (albeit obscurity to a degree).
I'm not in the perfectionist camp - as far as I am concerned anything that obscures is valid security. It adds to the work for a hacker doesn't it? It wipes out the inexperienced or playful scriptkiddies eh?
Again - a path disclosure in and of itself, and mutually exclusive of any other exploit is not a security risk.
In reality however, exploits do not exist in isolation. A Path Dislosure, in combination with several other exploits can be a devastatingly effective tool for a hacker.
In fact all you need is one other exploit to take advantage - something as dumb as include files relying on a variable which is neither filtered, validated or cleaned (stripped of "../" like prepends). This is a Path Traversal exploit - the ability to access files on paths either on or off the webroot with a GET (or other) request.
Put both of these together and you better pray for some serious good luck.
Maybe that's something we should all keep in mind. Often developers are too focused on individual security elements to really consider the impact of the combined weakness of several lower priority weaknesses. Its why I would argue hard against Roja's assertion above - you can't ignore every single weakness. It can be justified by cost, etc. (we don't roll in cash and time) but you have to consider them all and make certain you don't miss the obvious.
Stopping this ramble - just think of the following:
display_errors 0
Is that worth arguing over? Its such a simple, tiny measure - 5 seconds of your time. You can even change it on a per directory or per file basis - its a PHP_INI_ALL level config option. You can change it via php.in, .htaccess, .php files...