Keep PHP out of my IMAP folder...

marcel

Verified User
Joined
May 13, 2005
Messages
25
I have a CENTOS server running directadmin. The folder '/home/[account]/imap' and subfolders of this folder contain all email from the emailaccounts associated with this user. If i now run the following PHP code on one of the websites:

die(json_encode(scandir("/home/[account]/imap")));

I get the full email content of these mailboxes, which means php can just access all of the imap email. Because of this, it could only take a single malicious wordpress plugin or composer package to have all my emails leaked!

I would like to prevent php running on the server from accessing these folders. When i search google about this issue, nothing relevant comes up. This worries me. Does this mean that everyone has the same 'problem'? Or is my directadmin/server just misconfigured? Is there some setting in PHP, DirectAdmin or the server that i overlooked?

I do not care about Perl (or other), just about PHP. I do know about the open_basedir setting and I do know about custom httpd configurations, but until now all efforts in this direction have had no succes for us.

Is there a good solution to have this solved (and should DIrectadmin not do so in general?). Help is much appreciated!
 
Last edited:
die(json_encode(scandir("/home/[account]/imap")));
I don't know if the code missing something, but I don't get any content of mailboxes when I run this command in the public_html directory.

I replaced [account] with the real accountname and the only thing I get as response is this:
[".","..","domain.nl"]
where domain.nl is the domain name of the user. Which means the plugin or the malicious code must also get this name first. That might not be too difficult maybe.

But even when using the /user/Maildir/cur behind the command it only gives me a list of the mails, still no content. I tried with 1 mail and then I got "false" als a response.

We do have open_basedir and php safe mode in effect. So all basic configuration, no custom httpd configurations.
 
Richard, code was just an example to show that it is possible for PHP to enter your email directories from out of your web directory. The code for extracting mail would be different. Open_basedir in basic configuration does not 'solve' this and therefor your mail would be open to the world.

We want to close the mail directory to be sure that no (web)script has access to it. But unsure on what to add to the custom httpd config as any trials in this direction did not help.

Any suggestion is welcome
 
If you'd like to change mail partition you may follow https://docs.directadmin.com/other-...to-store-e-mail-data-on-a-different-partition.

Alternative would be to store imap files under other user than PHP runs as.
Thanks, yes. The idea about an other user also crossed my mind. But I am not sure how to handle this with the mail domains (DNS) and the necessary downtime to get this going. Same for the 'different partition approach', this sounds even harder. Will investigate again on these 2. In the meantime, what would be the changes to custom httpd config as this sounds the easiest, would be sufficient for us, but we did not get this running 'correctly'. Any thoughts/direction on this?
 
I would like to know - inside the same machine, how to run the website and email under different user identity.
(I assume the same domain name). :D

Alternative would be to store imap files under other user than PHP runs as.
 
I would like to know - inside the same machine, how to run the website and email under different user identity.
(I assume the same domain name). :D
I suppose he meant 'different username/account' and one account for website (www.test.com) and one account for mail (mail.test.com)
 
Inside DA panel, we cannot create 2 DA users with the same domain name.
one account (ww1.test.com) for website (test.com) and one account (ww2.test.com) for mail (mail.test.com) would work I suppose (?)
 
Possible.

You may create one DA account for test.com email.
Another one for (e.g.) web.test.com for website (however, it cannot be "www", I tested).
Then, inside email account one, make a URL redirection from www.test.com (and test.com) to web.test.com

(However, it will change the website URL to (e.g.) web.test.com , not www.test.com normally)

---

Or, if you have 2 machines, you may use 1 for website, 1 for email.
 
Open_basedir in basic configuration does not 'solve' this and therefor your mail would be open to the world.
I'm no scripter, so thank you for the explanation. Open to the world would still require some malicious script to know the username and local path.
But you do have a point there. So I had a look how this was on cPanel.
Unfortunately this seems to be the same issue there. I guess this is also the case with Plesk and maybe others.
This doesn't make it any better, but it seems indeed only another account or another partition might be the only solution.
 
This sounds like a real security problem to me. Customers on the same server could guess usernames, or even see it with the webshell in the network traffic, and the pathes they know already from their own account.
An own partition is without doubt the most preferable option to me, as this would also allow to split the user quotas into two parts, one for webusage, and one for emails (and could open the possibility to sell them at two different prices), as it is done by a lot of big companies.
 
Guys, look at the folder permissions please. Only user and mail group have access (on my server: permissions: 770 / UID/GID: user/mail) . So other users can guess the path, but won't be able to open the folders/files.

Further, separating things won't help for this because the user/mail server always needs to have access to this...
 
Customers on the same server could guess usernames, or even see it with the webshell in the network
No that wouldn't be possible as the open basedir protection would prevent this. At least... with open basedir in effect and using decent methods like php-fpm or mod_php with mod_ruid2. And indeed permissions would not allow it either.
Otherwise people on the same server would be able to get the database credentials of other users too by source reading the wp-config.php for example via a script.

If this was really the case, then all professional panels wouldn't leave it like this for such a long time.
So it can only be done from the account itself, with some script like @marcel said which should be able to find the correct path and a way to open all mails.
I don't know if this is indeed easy, otherwise hackers would probably already have done this more often. However... one never nows.
 
I'm no scripter, so thank you for the explanation. Open to the world would still require some malicious script to know the username and local path.
But you do have a point there. So I had a look how this was on cPanel.
Guys, look at the folder permissions please. Only user and mail group have access (on my server: permissions: 770 / UID/GID: user/mail) . So other users can guess the path, but won't be able to open the folders/files.

Further, separating things won't help for this because the user/mail server always needs to have access to this...

Unfortunately this seems to be the same issue there. I guess this is also the case with Plesk and maybe others.
This doesn't make it any better, but it seems indeed only another account or another partition might be the only solution.

Nick, script does not need to guess the path, it knows the path... Also there is no issue with permissions as the user has the permissions. Indeed, I am not talking about other users, that were some concerns from other forum users. Foremost why would a web application in the public_html directory (by design and general) need access to the IMAP directory? At our company we do not have scripts which would need this access to my knowledge...(?!)

Richard, a malicious script knows the path (username) or can just simply inform about the path. No guessing needed. To my opinion 'Hackers would already have done it' is never a good reason -not to think- about it... (See latest Exim hack for instance).

:) Anyways, not here for a discussion about it. Just want to raise concerns and solve my own issue, being: I am/was not able to find a good solution to keep PHP out of my IMAP directory. Want to make changes to custom httpd config as this sounds the easiest and would be sufficient for us, but we do not get this running 'correctly'. Any thoughts/direction on this?
 
Last edited:
About "custom httpd config"
if you use PHP-FPM, you need to add at php-fpm custom section.


Example:
#CUSTOM# section
Code:
|?OPEN_BASEDIR_PATH=`DOCROOT`:`HOME`/tmp:/tmp|

this will limits to only "domains DOCUMENT_ROOT directory, /home/{USER}/tmp, /tmp".
 
If you use mod_fcgid with bubblewrap (jailshell), you may consider to bind (--ro-bind-try) a dummy folder onto $HOME/imap and $HOME/Maildir

(Note: it involves some customization)

BubbleWrap / Jailshell can work only in mod_fcigd mode.
 
Back
Top