Full server path... dangerous?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Full server path... dangerous?

Post by Ambush Commander »

I recently remembered an interesting post to the PHP-Sec security list; Marco had responded to my question on whether or not one of the security advisories was really a security problem. His reply:
Well, assuming that it really happens, it discloses the location of your site and at least portion of the structure of your disk storage... which is not good.
The error went along the lines of:
**PHP Error in /usr/local/apache2/htdocs/roundcube/index.php (301)*:* Invalid
request failed/file not found

The requested page was not found!
Please contact your server-administrator.
I'd like to throw it to you guys. Is this really a security problem?
malcolmboston
DevNet Resident
Posts: 1826
Joined: Tue Nov 18, 2003 1:09 pm
Location: Middlesbrough, UK

Post by malcolmboston »

personally, i would say that it is because as has already been stated, it does print out site structure, and could be used to give hints to any suspective hacker....however, i , personally would not worry about it too much
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Security is relative, and is about reducing risk. Every system has some level of risk, and programmers (should) do their best to reduce the overall risk.

Consider a tragically coded program that stores passwords in a file called password:

/usr/local/apache2/htdocs/roundcube/passwords.txt

And a filesystem that sets that file to writable for anyone.

Suddenly, the attacker knows where the file is, and has the ability to modify it. Its a fairly risky situation.

Thats why security researchers generally support a concept known as defense-in-depth. While one control (filesystem access) is insecure, another is there providing a hindrance (the location of the file).

Now, in this particular example, its a bit of over-exaggeration on my part, because obscurity (not knowing where the file is) isn't truly security - its just knowledge reduction.

The point is, yes, it does reduce the overall security (risk reduction) program, but the impact may be (probably is) trivial or far less important than other issues.

But if given the chance, you might as well reduce that risk.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Giving another take.

If you host multiple PHP applications - chances are you really do not want people being capable of knowing your directory structure so easily - its knowledge reduction by obscurity, but this is also one of the most common ways of figuring out that nugget of information - so its plain stupid not to block it. How many have hosts who display errors with full path disclosure by default? See... Go figure.

So you have a path, maybe an idea of where that passwd file is not located.

Maybe another PHP application on that same server has a remote directory access bug - letting a user call up some file from anywhere on the system (if they know the path - oops).

This does happen, and unfortunately its not altogether unusual in PHP. Keep an eye out on the php-sec list and you'll see all sorts of wonderful exploits for commonly used PHP apps. Many are rarities with strange dependencies, others are absolute jaw dropping whoppers.

Truth is the exploit methods are obscure to most people - so they remain blind to the problem, so they are rarely publicised - that does not mean they are uncommon.
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

This should not be serious but it could be if the directory in question was not in your web dir.

At this point you disclose no additional info but if that is e.g. your include folder it would be a big problem.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

This should not be serious
Unintentional disclosure of system details which are considered at least private, at most secretive is serious. Especially when there is a real risk of misuse. Even the webroot is a risk - its appended to a root path isn't it?

Lets say all that gets disclosed is my webroot (generally the installation path for PHP apps). Nice. Now what if I'm on a shared host were directory structure may follow a known predictable pattern? I can now use your path disclosure to make an educated guess at your non-webroot directories. Not exactly difficult is it?

Then, what if there are uniquely named directories. Can't work them out - but I still know where they can now be found... Next step is reading that directory - and that can be done in numerous PHP apps. Just watch the php-sec list for a while and you'll be horrified...;)

There is a reason why path disclosure is a commonly reported SECURITY exploit - because it lends itself to misuse. Like any such information it poses a security risk, which in a fair PHP application must be mitigated - or at least it should be... Of course its not a lot times.

Should not != Is not ;)

Think of this less as a single exploit, and more part of a sequence of exploits. A good hacker (or nearly any experienced developer really) with time can play exploits against one another. The more PHP apps (or others with exploits) are available on a server - the more tools a hacker has to work with.

There was a pretty good post maybe a month or two ago on php-sec on vBulletin. The guy lost access to ssh/ftp/etc. In an attempt to recover it, he decided to investigate gaining ssh access via vBulletin. Now in this case he required admin priveleges (can potentially be done by a hacker via session hijacking or other), and the use of several key exploits in the forum.

Last words - he did get that access - using a common forum app.

So whether one perceives a path disclosure as serious or not is important - it should be viewed as serious, in all cases, in all contexts. Anything less is giving the hackers an extra tool.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Maugrim_The_Reaper wrote:So whether one perceives a path disclosure as serious or not is important - it should be viewed as serious, in all cases, in all contexts. Anything less is giving the hackers an extra tool.
I'm going to take the counter position.

The process of improving security is unfortunately often a binary choice - A programmer can spend X hours, and has to choose which items to improve in that time. In such a situation, he should focus on items with more severity or criticality.

In that scenario, I would argue that path disclosure has less severity than (for example) not filtering user input. With less severity, it should be lower on the list of things the programmer should focus on.

In an ideal situation, you engineer a solution from the beginning, and ensure that "the right steps" are taken from day one. Things like filtering input, escaping output, limiting priveldges, and yes, ensuring that we don't expose data to an attacker if we don't have to.

Unfortunately, its rarely an ideal situation. More often than not (and the OP's example is one) you are retrofitting security onto an existing app. In that situation, you do need to focus on the higher severity (serious) issues.

There is an argument to be made that all security risks are equally dangerous in the wrong situation, but as a programmer fixing shortcomings, I think there is definitely merit to putting some risks higher in the pecking order to fix first.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Someone always has to go plug reality as a valid alternative to theoretical perfection...

Cheat ;)

In the interests of time one could always list the reasons why a path is disclosed in an application. In many cases the fix is deceptively simple...

display_errors off

In the end - path disclosure in many cases is not a huge time investment...

Once you do the simple deed you can then argue the merits of investing time in other path disclosure exploits. There can only be so many ways to get PHP to output the system path to a file - so I would argue that yes, benefits eventually diminish but if you do nothing you're going to miss the most obvious (and usually the most prevalent) causes. Retrofitting may be a pain in the ass - but its not an excuse to lower the bar, and miss the obvious. There's too much of that already in some of the most commonly used apps...ahem...phpNuke...

I won't argue against the prioritisation - XSS vs Path Disclosure... Has to be the first one. But the second still shouldn't be ignored completely...
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Path disclosure, theoretically, should be extremely easy to fix. So there's not so much the usability vs. security problem that's prevalent with other security problems.
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

Maugrim_The_Reaper wrote:
This should not be serious
Unintentional disclosure of system details which are considered at least private, at most secretive is serious. Especially when there is a real risk of misuse. Even the webroot is a risk - its appended to a root path isn't it?

Lets say all that gets disclosed is my webroot (generally the installation path for PHP apps). Nice. Now what if I'm on a shared host were directory structure may follow a known predictable pattern? I can now use your path disclosure to make an educated guess at your non-webroot directories. Not exactly difficult is it?
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

So in this case no additional info is disclosed. As I stated if this is an error in an included file and the roundcube dir is the accessible include dir there is a lot of danger.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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...
Post Reply