WTF?? webmail login sessions in /tmp with password in plain text

Portal Home > Knowledgebase > Articles Database > WTF?? webmail login sessions in /tmp with password in plain text

Posted by Johnny Cache, 05-03-2012, 12:43 PM
WTF??? http://forums.cpanel.net/f185/webmai...xt-272081.html This is one of three HA servers I had turned up last week. I also have a VPS container set up, in another DC entirely, that I use for testing and security, and it's occurring there also. I cannot recall having ever seen this before, and I can't say that I like it. Last edited by Johnny Cache; 05-03-2012 at 12:54 PM.
Posted by Patrick, 05-03-2012, 12:51 PM
The session files under /tmp are chmod 700 so only the owner or root can view the content. It's not really a security issue, although any plain text passwords is never a good idea... Last edited by Patrick; 05-03-2012 at 12:54 PM.
Posted by KMyers, 05-03-2012, 01:05 PM
I would not say this is a safeguard, especially for those who run processes as nobody. Plain text passwords is a bad idea, no matter how many layers of protection are in place
Posted by Patrick, 05-03-2012, 01:08 PM
People running shared servers with PHP processes running as nobody deserve what's coming to them.
Posted by KMyers, 05-03-2012, 01:09 PM
Agreed but the problem is the customers of these companies dont
Posted by Maxnet, 05-03-2012, 01:14 PM
While it is correct that only the owner can view the content, be aware that an attacker only needs to know the FILENAME to be able to hijack the session. Example: session file is called "sess_bbf5ddb8b27e9cad4d879d40ae0a003a" Put a cookie "PHPSESSID=bbf5ddb8b27e9cad4d879d40ae0a003a" in your browser's cookie jar (e.g. using one of the cookie manager Firefox extensions) Visit the site. You'll see that you are logged in as the user whose session you borrowed... So storing cookies in a world readable directory like /tmp is definitely a security problem.
Posted by KMyers, 05-03-2012, 01:16 PM
Typically most authentication systems use more then the PHPSESSID for authentication/session management. Personally I also store a token in there along with the user ID
Posted by Maxnet, 05-03-2012, 01:53 PM
That may be best practice, but doubt MOST do that. Do not see any additional token or (IP) restriction in the webmail session information at the top of the page. That would indeed have helped in this case with the pop3 password. But be aware that tokens are not enough protection for most other webapplications in which the logged in userid is recorded in the session file. Because the attacker could also simply create a brand new session file in /tmp containing the desired session variables (user he wants to be, and a token he knows), chmod 666 it and and then visit the site. PHP happily accepts session files created by other system users. A private session dir for each user is therefore still preferred.
Posted by Johnny Cache, 05-03-2012, 02:01 PM
I guess I was shocked because I'd truly never seen that before and I've been around a while. I've gone ahead and with suPHP/suEXEC as planned, on each server, to correct the issue before I start putting users on them. I thought that it was something entirely different, as if I'd missed a security update or something.