Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 150091 - digest-md5 causes program crash on poor input
digest-md5 causes program crash on poor input
Status: CLOSED DUPLICATE of bug 189814
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: cyrus-sasl (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Steve Conklin
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-02 09:41 EST by John Haxby
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-10 17:14:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to fix CVE-2006-1721 vulnerability (476 bytes, patch)
2007-03-06 03:28 EST, Tuomo Soini
no flags Details | Diff

  None (edit)
Description John Haxby 2005-03-02 09:41:40 EST
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):

How reproducible:

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:

+ bm9uY2U9IkJlK3R6TDhJSEhtc0dyTk5KZ0YyWitlTGM4cHVrR3RRMjF6QzNQVWovczg9IixyZWFsbT0ic2hlZXAudWsuc2NhbGl4LmNvbSIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==

0 OK AUTHENTICATE completed, now connected to sheep.uk.scalix.com

The response (that starts dxNlcm5...) can be decoded to


If you remove the realm="sheep.uk.scaloix.com" section and base64 encode the result you'll get


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:
Comment 1 Dave Kelly 2005-03-02 09:59:37 EST
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.
Comment 3 sibel 2005-04-25 09:05:30 EDT
(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:
/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?

Comment 4 Tuomo Soini 2007-03-06 03:15:12 EST
This problem is know as CVE-2006-1721.
Comment 6 Steve Conklin 2007-07-10 17:14:38 EDT

*** This bug has been marked as a duplicate of 189814 ***

Note You need to log in before you can comment on or make changes to this bug.