Bug 150091 - digest-md5 causes program crash on poor input
Summary: digest-md5 causes program crash on poor input
Status: CLOSED DUPLICATE of bug 189814
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: cyrus-sasl (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Steve Conklin
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-02 14:41 UTC by John Haxby
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-10 21:14:38 UTC
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 08:28 UTC, Tuomo Soini
no flags Details | Diff

Description John Haxby 2005-03-02 14:41:40 UTC
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 14:59:37 UTC
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 13:05:30 UTC
(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 08:15:12 UTC
This problem is know as CVE-2006-1721.

Comment 6 Steve Conklin 2007-07-10 21:14:38 UTC

*** 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.