From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Red Hat/1.0.1-1.4.3 Description of problem: In the cyrus-sasl-2 source, in plugins/digestmd5.c at around line 2229 it says: /* Sanity check the parameters */ if (strcmp(realm, text->realm) != 0) { ... The trouble is, there is no check to make sure that the realm was passed as part of the response from the client at all. The Java SASL implementation doesn't actually require the realm to be set, so when I was testing SASL authentication using Java my server program crashed here. I don't know if the realm is mandatory (you'd have to double check the RFC to find out), but crashing when it's not there is not a good way to work. Version-Release number of selected component (if applicable): cyrus-sasl-2.1.19-5.EL4 How reproducible: Always Steps to Reproduce: 1. Find a service that uses cyrus-sasl-2 and digest-md5 for login and capture a successful login to it. 2. telnet to the service's port and start a digest-md5 authentication. 3. Take the first response from the successful login, base-64 decode it, remove the "realm=..." section, base64 encode it and paste it back into the telnet session. The server you're connecting to will crash gracelessly on the line above. Alternatively, use Java SASL and don't bother to set the realm in the callbacks. For example: here is a good authentication sequence against an IMAP server that uses cyrus-sasl: 0 AUTHENTICATE DIGEST-MD5 + bm9uY2U9IkJlK3R6TDhJSEhtc0dyTk5KZ0YyWitlTGM4cHVrR3RRMjF6QzNQVWovczg9IixyZWFsbT0ic2hlZXAudWsuc2NhbGl4LmNvbSIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw== dXNlcm5hbWU9ImpjaCIscmVhbG09InNoZWVwLnVrLnNjYWxpeC5jb20iLG5vbmNlPSJCZSt0ekw4SUhIbXNHck5OSmdGMlorZUxjOHB1a0d0UTIxekMzUFVqL3M4PSIsY25vbmNlPSJZdFE0clZHMStJNDdDSTkxZTByYktVeFAveXlNWE5iWDMybmdUTHZ4UTBFPSIsbmM9MDAwMDAwMDEscW9wPWF1dGgsZGlnZXN0LXVyaT0iaW1hcC9zaGVlcC51ay5zY2FsaXguY29tIixyZXNwb25zZT1jYjUyM2Q1MGJlOGY5YjNmOWFkYjFmMGQ2ZDY3OTUyOQ== + cnNwYXV0aD0zZGJkYTAzOTc2N2EwOWNkNGZlNjk5YTc1ZmFjNDUxNw== 0 OK AUTHENTICATE completed, now connected to sheep.uk.scalix.com The response (that starts dxNlcm5...) can be decoded to username="jch",realm="sheep.uk.scalix.com",nonce="Be... If you remove the realm="sheep.uk.scaloix.com" section and base64 encode the result you'll get dXNlcm5hbWU9ImpjaCIsbm9uY2U9IkJlK3R6TDhJSEhtc0dyTk5KZ0YyWitlTGM4cHVrR3RRMjF6QzNQVWovczg9Iixjbm9uY2U9Ill0UTRyVkcxK0k0N0NJOTFlMHJiS1V4UC95eU1YTmJYMzJuZ1RMdnhRMEU9IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJpbWFwL3NoZWVwLnVrLnNjYWxpeC5jb20iLHJlc3BvbnNlPWNiNTIzZDUwYmU4ZjliM2Y5YWRiMWYwZDZkNjc5NTI5 If you now use this in a telnet session to the IMAP server (it doesn't matter that the checksum and whatnot in this are wrong, the code doesn't get as far as checking) you'll get a crash with this backtrace: #0 0x00aae3d8 in strcmp () from /lib/tls/libc.so.6 #1 0x00821748 in digestmd5_server_mech_step2 (stext=0x8eb3b58, sparams=0x8eb3810, clientin=0x8ebb688 "sheep.uk.scalix.com", clientinlen=149665960, serverout=0x0, serveroutlen=0x0, oparams=0x8eb3538) at ../../plugins/digestmd5.c:2229 #2 0x00822dba in digestmd5_server_mech_step (conn_context=0x8eb3b58, sparams=0x8eb3810, clientin=0x8ebb6a0 "username=\"jch\",nonce=\"ZqWf9E64hczzzCdJPXyGe+s6j3K/j2gSb7096JeI91M=\",cnonce=\"U97i+OQymR3CErVi+Ff2lsO9XVzDZvKYzEv5wgNb0Qk=\",nc=00000001,qop=auth,digest-uri=\"imap/sheep.uk.scalix.com\",response=a84df11184"..., clientinlen=0, serverout=0xbfe3fe30, serveroutlen=0xbfe3fe34, oparams=0x8eb3538) at ../../plugins/digestmd5.c:2650 #3 0x00862094 in sasl_server_step (conn=0x8eb2cd8, clientin=0x8ebb6a0 "username=\"jch\",nonce=\"ZqWf9E64hczzzCdJPXyGe+s6j3K/j2gSb7096JeI91M=\",cnonce=\"U97i+OQymR3CErVi+Ff2lsO9XVzDZvKYzEv5wgNb0Qk=\",nc=00000001,qop=auth,digest-uri=\"imap/sheep.uk.scalix.com\",response=a84df11184"..., clientinlen=222, serverout=0xbfe3fe30, serveroutlen=0x0) at ../../lib/server.c:1408 Obviously, with some servers this will be a denial of service attack. (For this particular IMAP server, it only kills off the process we're talking to; for an SMTP server that has similar authentication code, it kills off the entire server as it handles multiple concurrent connections.) Actual Results: Core dumps, crashes, denial of service, etc. Fortunately, as this is "merely" a null-pointer dereference it can't be used for anything worse than denial of service. Expected Results: The digestmd5 cyrus-sasl plug-in needs to be made more forgiving of a response that doesn't contain all the elements it expects. Additional info:
Using the same technique as described above, this is a good way of causing a segmentation violation in a sendmail process. This is restricted to the child process handling the connection.
(In reply to comment #1) > Using the same technique as described above, this is a good way of causing a > segmentation violation in a sendmail process. This is restricted to the child > process handling the connection. I have a problem, this must be cyrus-sasl bug. I try to work postfix and cyrus-imap, cyrus-sasl. But when I wrote "cyradm --user cyrus --server localhost" from konsole, I get same error messages: IMAP Password: at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Cyrus/IMAP/Admin.pm line 118 cyradm: cannot authenticate to server with as cyrus What am I do? I can add user with saslpasswd, but cyradm not add. Have you any proper document or test guide, can you send me by mail. Did you make test cyrus-sasl, cyrus-imap and postfix. I have read a lot of document from web site, and from web forum, but anything did not solve my problem. please tell me what must I do?
This problem is know as CVE-2006-1721.
Created attachment 149326 [details] Patch to fix CVE-2006-1721 vulnerability https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/sasl/plugins/digestmd5.c.diff?r2=1.175&r1=1.173&f=u
*** This bug has been marked as a duplicate of 189814 ***