DirectAdmin BUG!!??

A

azet

New member
Joined
Feb 3, 2006
Messages
4
Hello,

We are using uebimaiu as an webmail for our customers. There is a
problem with security issues. When customer read an email message it is
copy from mailbox to webmail_directory/tmp. Even after logout procedure
it is not deleted. If You know where webmail source was placed You can
read messages of another customers without knowing any password !
it is pretty easy using simple php script f.e.



Is there any solution to fix this problem ?
 
If this is a bug, it's a UebiMiau bug. I think it's more of a cross-site-scripting problem. And I think it'll only happen if you've got openbasedir on.

But I could be wrong. Anyone else?

Jeff
 
The .eml files are written in /var/www/html/webmail/tmp/usern/inbox as apache:apache

They are written after somebody has read an email. If you delete the eml file, the mail is marked as unread. So it's just for the read flag?
I don't like this.
 
This won't be fixed by open_basedir, as everyone has /var/www/html in their open_basedir path.

As apache creates the file, it must be readable by apache.. and so is a security flaw. I'd contact uebimiau and suggest to them to use a different tmp directory (as then all user-viewed email can be created in a tmp directory located in the domain's root).
 
can a mod edit the post please, ok there is a flaw but we shouldnt be publishing it.
 
I won't; perhaps one of the other moderators will if you click on "report this thread".

Personally I believe in announcing flaws.

There are lots of arguments on the subject all over the web; you and I are just on different sides of this one.

But if one of the other moderators wants to delete it, that's fine with me.

Report it :) .

Jeff
 
I see that You just started. I post today here my reply about this thread, and You have deleted it.

Good work DirectAdmin`s team :/.
 
Its not about the flaw been announced its about how to do the flaw itself, securica etc. dont ever post the flaw itself.
 
I have a potential fix..

Uebimiau needs to have its tmp folder accessible by apache, so this needs to be in your open_basedir for PHP.
However you can set this as you like in the config.php file.

I've noticed that the user's mail is stored in a subdirectory to the tmp directory - with the name <user>_<mailserver>.

So, if you edit the uebimaiu configs, change the tmp to /tmp/UebiMiau; and add /tmp/UebiMiau/|USER|_localhost to your php open_basedir you should be safer from users reading each other's mails.

I havn't tested this yet - have a look yourself and see if you have the same configuration as me. Also, there is a login_type option to Uebi where logging in as <user>@<site> doesn't give the same directory as logging in as <user>.

There is a known problem with placing the Uebi tmp directory inside the Uebi webmail directory as shown in this UebiMiau Forum post
 
Looking at the UebiMiau source as installed by DA, it has been modified.

The login must be the user, without the @domain bit, and it always creates a folder <user>_<servername> (where servername is the smtp server defined in Uebi's config.php (localhost in mine).

So. to fix any rogue php scripts: change the temporary_folder in Uebi's config.php to be /tmp/uebimiau then edit your open_basedir to contain this directory with |USER|_localhost appended.

You're still insecure with CGI programs, but a .htaccess in that directory restricting access might help.
 
gbjbaanb said:
The login must be the user, without the @domain bit
Click to expand...
UebiMiau won't work without the user@domain login; DA allows multiple "user" parts, one for each domain.

Jeff
 
That's interesting... my config.php (in /var/www/html/webmail/inc) says

PHP: 
$mail_server_type       = "ONE-FOR-ALL";
and
PHP: 
$one_for_all_login_type = "%user%";

And this is a DA-supplied install, untouched by me except for the tmp path change I made. So why would it be like this and not user@domain. (which is the login for DETECT server type, but as you see, that's not set).

I am running with Dovecot, centos 64bit. Does this make the difference?
 
oh yes, I've tried it - wondering why I couldn't log in when I was following the instructions exactly :)

It seems to only accept DA users. ie 'admin'. Not [email protected] which I'd expect to be valid as I have a pop3 account created with that name.

Similarly, the reseller I created can only log in with his username, not the full email address.
 
the one bundled with DA has the modified code but the config.php is incorrect.

edit /var/www/html/webmail/inc/config.php

line 186

$one_for_all_login_type = "%user%@%domain%";

save
 
Only on FreeBSD or for all solutions?

Has this only occurred recently?

Do you know when (version or date) it first appeared?

Jeff
 
Hello,

I do remember patching Uebimiau quite a bit and doing the username formatting in the patches, not the config. If you set:
$one_for_all_login_type = "%user%@%domain%";
You might be breaking that.. user account may end up like

[email protected]@domain.com

so you might want to test this out.

We've used:
$one_for_all_login_type = "%user%";

since the very beginning.. so I'm not sure why things would have changed now.

If you're using a script downloaded directly from the Uebimiau site, then that would explain it. We use a customized version so that both the "username" and "[email protected]" username will work and be accepted.

As for the Uebimiau bugs, it's a Uebimiau bug. No matter where you put the path, it's written by apache, so it will be read by apache.

Using open_basedir will work to remove /var/www/html, but then you close yourself off from actually accesing webmail. The solutino (if open_basedir is on) would be to setup a seperate webmail.domain.com virtualhost that allows access to webmail, while everything else is shut off.
http://help.directadmin.com/item.php?id=92

John
 
I've been experimenting..

I have a user 'admin', and I can login into webmail as 'admin' to see his emails.
Unfortunately, when I look in the pop3 users page of DA, I see account called [email protected], combine this with the docs that you login to webmail as user@domain and I get quite confused.

However, create a new pop3 user, it shows up as [email protected] ... with its own password and I can log in by typing the full email username.

so, it seems the UB config is correct, just slightly confusing. However, I'm not sure how emails for the 3 domains I created under the admin user end up in the same account (or rather, an email to [email protected] ends up in the 'master' admin account).

Now I only have difficulty in receiving emails to the admin user, and sending from the admin user appear as coming from [email protected] (as that's the latest domain I created). I guess I can get round this by creating a new email account, using that and forwarding all emails to admin there.

Maybe my login problem is because I am using dovecot?


As for the security bug, I still think that a open_basedir fixed at the directories a user's emails end up in would fix this (they are admin_localhost and test_mydomain_localhost.. probably putting them all in would start getting a bit long)(but the UB tmp dir will have to be outside /var/www/html/...)

Perhaps if we patched UB a bit more to place all all emails for a users domains in a subdirectory in /tmp/uebimiau and adding that to open_basedir. Then only the accounts created by each user would be insecure, instead of all accounts created by all users. Alternatively, install Taleon instead, which I'm told has a fix for this security bug in place and is a damn sight easier to spell!
 
Actually, the solution that wouldn't require a Uebimiau overhaul would be to set it to use imap instead of pop.

Edit /var/www/html/webmail/inc/config.php. Change:

$default_protocol = "pop3";
//$default_protocol = "imap";
$default_port = "110";
//$default_port = "143";

to

//$default_protocol = "pop3";
$default_protocol = "imap";
//$default_port = "110";
$default_port = "143";

It addresses the php issue, because no emails are actually stored locally (I think).. everything is done via imap, so user permissions come into play.

As for your login format question, the "admin" is a system account. Meaning it has a system UID (User ID #). All files in your DA account are owned by this UID. The way the email works, is [email protected] will point to the system admin inbox. This is done using a forwarder in /etc/virtual/domain.com/aliases to forward [email protected] to [email protected] (just 'admin', exim appends the hostname). The system inbox will generally end up in /var/spool/mail/admin, or /home/admin/Maildir for system accounts.

If you take note of the email table in DA, there are 2 colums for the name. The first is "Account", which is where you email TO to send an email. The 2nd column says "Login" which is the name you'd use to login to webmail, squirrelmail or outlook.

John
 
You must log in or register to reply here.
Back
Top