[VUNERABILITY] Accessing PHP source from remote user

[Frosty]

I have no idea if this has been discovered yet, but if you were to make a simple application in PHP, with the following code...

<?php
header("Content-type: image/jpeg");
readfile("/home/remoteuser/domains/userdomain.com/public_html/phpfile.php");
?>

...You are able to view the source of the file. I've tested this on a file with the CHMOD of 644. I think this is a problem with DirectAdmin, because it is the part dealing with the users.

So...ummm...this is a pretty serious thing. Yes the attacker would need to know the username, but that's not too hard to get.

 

[nobaloney]

It's not a DA issue. It's a PHP issue. You can turn on safe_mode and turn off open_basedir.

Of course then some scripts won't work.

Security is a tradeoff.

You can find these discussions everywhere PHP is discussed.

Jeff

 

[Frosty]

Exactly, some scripts don't work...
Kinda, how are we supposed to have a professional hosting service, with this vunerabilty, and the only way to prevent it is to make about 1/3 of the scripts not work. We had the safe_mode on once, everything was fine, except we got a lot of complaints.

DirectAdmin handles the user system, and DirectAdmin should be able to secure the user system. Really, I think it'll only take about 3 lines of code to fix this, so please, as a request, fix it.

 

[Frosty]

Well I just found out, even with safe_mode enabled, it is still working. This, imo, is extremely bad.

 

[jmstacey]

Did DirectAdmin write the PHP interpreter? Not that I know of

Take it to the php bug list.

 

[Frosty]

Did DirectAdmin write PHP? Not that I know of

Take it to the php bug list.

Listen, it's not the PHP.
PHP was developed with one user in mind...
DirectAdmin is manipulating the users... It should be able to secure this. It is creating the users, not PHP.

 

[Frosty]

Safe_mode on:
http://test123.mihopahost.com/index.php
http://noescape.mihopahost.com/imag.../test123.mihopahost.com/public_html/index.php

 

[jmstacey]

Really, I think it'll only take about 3 lines of code to fix this, so please, as a request, fix it.

Please endulge us with the fix you created.

Listen, I just reread the thread looking for anything I missed (which happens quite often mind you) and either I'm still missing it or your in denial. (Most gentle way I could put it).

Why in the world would DirectAdmin make and release a modified version of PHP when:
1. The problem is with PHP
2. A few configuration changes can fix the problem.
3. Oh... And it's not really their problem.

Regardless of what I have just said, I do have an open mind, so if there is something I'm overlooking please enlighten all of us.

 

[Frosty]

Please endulge us with the fix you created.

Listen, I just reread the thread looking for anything I missed (which happens quite often mind you) and either I'm still missing it or your in denial. (Most gentle way I could put it).

Why in the world would DirectAdmin make and release a modified version of PHP when:
1. The problem is with PHP
2. A few configuration changes can fix the problem.
3. Oh... And it's not really their problem.

Regardless of what I have just said, I do have an open mind, so if there is something I'm overlooking please enlighten all of us.

1. Like I said, PHP was developed with one user in mind.
2. Then please share what those could be, I would appreciate it.
3. If that is how the developers see it, then I really do not want to be a customer of their's. If their customer has a problem with their product, then they should not see it as "not my problem".

I told you, DirectAdmin is the one creating the users, not PHP.

Btw, GXX, open_basedir didn't work. Any other ideas?

 

[jmstacey]

1. Who's creating the users has nothing to do with this as far as I see. The user exists whether DirectAdmin created him or you did with adduser...

2. GXX says it all. Thanks man

3. I in no way represent the developers or staff of JBMC Software. That is MY personal view on the "issue"
I have no doubt that they care, but I strongly doubt that they are going to make a customized verions of PHP especially for an issue that has been around for over a year now.

I would really like to see your 3 line fix, where is it?

Come to think of it, I can't think of any other controlpanels that do it either. Hmm, I wonder why

 

[Frosty]

1. Who's creating the users has nothing to do with this as far as I see. The user exists whether DirectAdmin created him or you did with adduser...

2. GXX says it all. Thanks man

3. I in no way represent the developers or staff of JBMC Software. That is MY personal view on the "issue"
I have no doubt that they care, but I strongly doubt that they are going to make a customized verions of PHP especially for an issue that has been around for over a year now.

I would really like to see your 3 line fix, where is it?

Come to think of it, I can't think of any other controlpanels that do it either. Hmm, I wonder why

Well, I get the feeling that you are trying to turn this into a flame war. Kinda, I come here looking for help, and then I get this? I'm not saying you are trying to flame me, but hmmm.

1. DirectAdmin creating the users is basically an addon to PHP, and the addon is not secure.
2. Yes, thank you GXX, I'll try this a bit later.
3. I did not say that you represent them... All I implied was, if this is how they treat their customers, then I don't want to be one. Notice the "if"? Also, I am not saying they should make a customized version. Like I just said, DirectAdmin is an addon, and it should be secure.

And about that three lines of code...
"Really, I think it'll only take about 3 lines of code to fix this, so please, as a request, fix it."
You should notice the "I think" in that line. Also, it seems that you think I also said I know the three lines that it should take. And who said I created a fix??

Also, "I can't think of any other controlpanels that do it either"...
You must not be thinking hard enough. If I'm mistaking, now I'm not sure here, but I think cPanel corrects this.

"Listen, I just reread the thread looking for anything I missed (which happens quite often mind you)..."
You weren't kidding when you said, "which happens quite often".

 

[Aspegic]

Having read through this thread, and unless I'm missing something, I think I have to agree with jmstacey.

Look at it this way:
Delete all DirectAdmin binaries from your server.
The problem still exists.
Now add a new user manually.
The problem now exists for that user to.
But DirectAdmin is no longer on your server so how could it be responsible?

The solution would be to modify some part of PHP, but the authors of PHP are not the same as those who developed DA. So the most logical thing to do would be to contact the PHP developers, just as jmstacey suggested.

Unless I'm missing something of course...

 

[Frosty]

Having read through this thread, and unless I'm missing something, I think I have to agree with jmstacey.

Look at it this way:
Delete all DirectAdmin binaries from your server.
The problem still exists.
Now add a new user manually.
The problem now exists for that user to.
But DirectAdmin is no longer on your server so how could it be responsible?

The solution would be to modify some part of PHP, but the authors of PHP are not the same as those who developed DA. So the most logical thing to do would be to contact the PHP developers, just as jmstacey suggested.

Unless I'm missing something of course...

Well I totally agree with you, but if DirectAdmin made the user in the first place, shouldn't it secure it? I'm not sure how to explain my thoughts, but the DirectAdmin is controlling the users....
I don't really want to argue about it any more, though, until I am able to see if GXX's soulution works.

 

[Aspegic]

DirectAdmin made the user in the first place, shouldn't it secure it?

I do understand what you mean, but I'm not sure if it's even possible for DA to solve the problem...

I assume you're talking about file-access rights and user/group rights. But if DA would create new users with more restricted access rights that would break the system because Apache would not be able to access the user files anymore.
PHP essentially has the same rights on the server as Apache, and of course Apache has access to all the user directories (otherwise it wouldn't be able to serve the websites). So PHP also has access to all user files. So it should be PHP who prevents the use of the exploit you discovered.

@gxx: we're not arguing, just expressing some thoughs

 

[Aspegic]

Hm, i just had a scary thought...

Could the script that frosty posted also be used to display other files (not .php files)?
Something like config.inc or something which could contain username/password information?
Brrr.... I think I'm going to check that open_basedir setting on my server right now!

 

[jmstacey]

Frosty,
I feel like there is no better way that I can explain it.

As far as I know there is limited correlation between the way DirectAdmin creates user accounts and that particular command (readfile) in PHP. I looked through the user comments in the PHP manual for this command and this issue is mentioned end of 2004 and on up to the latest in 2005. I would have to say some at the very least were not using DirectAdmin when they discovered the issue.

 

[Aspegic]

cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom
perl -pi -e 's/#php_admin_value open_basedir/php_admin_value open_basedir/' virtual_host*.conf
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

Just do it already ppl

Yeah, yeah, I don't just blindly execute every script somebody posts without first understanding what it does hehe

Since I'm not very familiar with perl it took me some time, especially these last two lines, but I must say, very ingenious

As I understand it you first backup the current config files to "custom"
Then you schedule a search and replace that uncomments the "php_admin_value open_basedir"-line in the virtual_hosts config files, right?

 

[Aspegic]

It works. Many thanks gxx!!!

 

[fusionictnl]

The fix posted would stop users from getting out there own user dir. Sort of jailing. Make sure to correctly setup the include directories as PEAR files etc. These would in some scripts result in errors. Furthermore I don't think DA is responsible for the problem, but can prevent it like cPanel does by giving the administrator an option to use php as CGI. So it runs within the SuExec enviroment. (suPHP is one of the ways).

If they implement a fix correctly this wouldn't brake the current setup and shouldn't give any major problems then the problems you'll have with CGI-BIN files. As long as I don't have to order all my customers to add #!/usr/local/bin/php to their scripts I'm fine.

Furthermore this will fix the problems with php files being written as apache and couldn't be deleted by the user. Still don't know if all the currently available fixes like suPHP and the one cPanel uses are usable. But this isn't the problem of PHP as everyone speaks of It's a problem with PHP and APACHE. Apache 3.0 would fix this

 

[hostpc.com]

Are you saying you want to run EVERY php process as CGI ? That's crazy. Think of the calls something like vbulletin, OSCommerce or 90% of the user forums that would run as a CGI (CPU intensive process).

While I agree it WOULD probably stop this activity - running it as CGI would severely limit the number of accounts per server - and would increase server loads dramatically.