Bug 124086 - sendmail-8.12.11-3.3 breaks SASL Authentication for other than LOGIN & PLAIN
sendmail-8.12.11-3.3 breaks SASL Authentication for other than LOGIN & PLAIN
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sendmail (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
David Lawrence
: Security
: 125383 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-23 17:35 EDT by Jim Levie
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-03 09:34:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jim Levie 2004-05-23 17:35:30 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Gecko/20040301

Description of problem:
After updating a system that was offering CRAM-MD5, DIGEST-MD5, LOGIN,
& PLAIN for SMTP AUTH only LOGIN & PLAIN are allowed by Sendmail. The
sendmail.mc file properly requests the aforementioned methods, and
/usr/lib/sasl2/Sendmail.conf specifies a valid method (auxprop).

The original Sendmail (8.12.10-1) works as expected, but after the
update to 8.12.11-3.3 the secure methods aren't available.

Version-Release number of selected component (if applicable):
sendmail-8.12.11-3.3

How reproducible:
Always

Steps to Reproduce:
1.Set up Sendmail for SMTP AUTH and use auth info stored in sasldb2 by
using:
define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
in /etc/mail/sendmail.mc. Remove /usr/lib/sasl/Sendmail.conf, if
present and make /usr/lib/sasl2/Sendmail.conf contain:
pwcheck_method: auxprop

2.telnet to the SMTP port and check for 250-AUTH methods

Actual Results:  fe1> telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 fe1.dynetics.com ESMTP Sendmail 8.12.11/8.12.11; Sun, 23 May 2004
16:27:32 -0500
ehlo localdomain
250-fe1.domain.tld Hello localhost.localdomain [127.0.0.1], pleased to
meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP

Which clearly shows only LOGIN and PLAIN as available methods.

Expected Results:  wilowisp> telnet myrddin 25
Trying 192.168.0.2...
Connected to myrddin.
Escape character is '^]'.
220 myrddin.domain.tld ESMTP Sendmail 8.12.10/8.12.10; Sun, 23 May
2004 16:28:43 -0500
ehlo localdomain
250-myrddin.dynetics.com Hello wilowisp.dynetics.com [192.168.0.12],
pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 50000000
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP

Which is from an RHEL 3.0 system still using sendmail-8.12.10-1

Additional info:

I'm rating this as a high severity security issus since the lack of
secure authentication methods means that user authentication
information must be sent via an insecure method when doing SMTP AUTH
outside of a TLS/SSL session.
Comment 1 Thomas Woerner 2004-06-03 09:34:42 EDT
The new sendmail package is using sasl version 1. There were some
major problems with the sasl2 version.

Please use sasl1 instead.
Comment 2 Nalin Dahyabhai 2004-06-07 12:14:49 EDT
The reason for the change was that sendmail also used LDAP.  In RHEL3,
libldap uses sasl version 1, so sendmail ended up with both versions
of the library loaded at run-time (you can verify this by running
"ldd" against the sendmail binary).

Because both version 1 and 2 of the sasl library provide symbols with
the same names but which are binary-incompatible, there's no guarantee
that that combination could ever work reliably (i.e., without causing
sendmail to crash, which would actually be the most likely outcome),
so the change had to be made.
Comment 3 Thomas Woerner 2004-06-08 05:19:44 EDT
*** Bug 125383 has been marked as a duplicate of this bug. ***

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