Bug 140857 - saslauthd segfaults (size read failed) when the encrypted password is invalid
saslauthd segfaults (size read failed) when the encrypted password is invalid
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: cyrus-sasl (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-25 12:45 EST by Hann-Huei Chiou
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-31 15:33:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hann-Huei Chiou 2004-11-25 12:45:03 EST
Description of problem:
One of my user can't use ESMTP AUTH. Every time he tries, saslauthd 
segfaults and returns "size read failed). After a few experiments, we 
found that a password changing (and back to the original one) solves 
the problem. Since the shadow file is copied and pasted from a old 
slackware 7.1 box, we thought that there might be some problem with 
his encrypted password. So I use disabled accounts (ie. system 
accounts) to verify via testsaslauthd.

# /usr/sbin/testsaslauthd -u ldap -p ""
0: NO "authentication failed"

# /usr/sbin/testsaslauthd -u ldap -p any
size read failed
0:

And dmesg shows
saslauthd[21031]: segfault at 0000000002533180 rip 0000003efb46f200 
rsp 0000007fbffff498 error 4

Repeat the operation, and saslauthd will eventually crash

# /usr/sbin/testsaslauthd -u ldap -p any
connect() : Connection refused

Version-Release number of selected component (if applicable):
cyrus-sasl-2.1.19-3

How reproducible:
Every time

Steps to Reproduce:
1. run "/usr/sbin/testsaslauthd -u ldap -p any" as normal user
2. (any disabled account and any string except "")
3. repeat the operation
  
Actual results:
# /usr/sbin/testsaslauthd -u ldap -p any
size read failed
0:

And finally,
# /usr/sbin/testsaslauthd -u ldap -p any
connect() : Connection refused

Expected results:
# /usr/sbin/testsaslauthd -u ldap -p any
0: NO "authentication failed"

Additional info:
1st host (this one): x86_64, no SELinux, vulnerable
2nd host: x86_64, permissive/targeted, vulnerable
3rd/4th host: i386, permissive/targeted, invulnerable
Comment 1 Krzysztof 2005-11-29 23:51:09 EST
I got the same problem first with SUSE10 x86_64 and next, with Fedora4 x86_64.
IBM 2xXeon 64bit

http://groups.google.pl/group/pl.comp.os.linux.sieci/browse_frm/thread/5f65d765
4c372780/208744f07eb0867a?
lnk=st&q=SUSE+krzysztof+SASL&rnum=2&hl=pl#208744f07eb0867a

http://groups.google.pl/group/alt.os.linux.suse/browse_frm/thread/e2b31e2f1cd35
db6/744a27f2afd0ad61?lnk=st&q=SUSE+krzysztof+SASL&rnum=1&hl=pl#744a27f2afd0ad61

First I run saslauthd and I try testsaslauthd. 
When account name was shorter than 16 chars it success, when was longer than 
16 every probe was kiiling child of saslauthd. 
Nov 29 14:43:35 telmor kernel: saslauthd[5879]: segfault at 000000007be33180 
rip 0000003e7a772000 rsp 00007fffff853308 error 4 

All saslauthd were killed and authantication failed.

I try to resolve problem compiling myself from sources 
cyrus-sasl-2.1.20 with 
http://directory.fedora.redhat.com/sources/cyrus-sasl-2.1.20-gcc4.patch 
- not resolved my problem

and newest, cyrus-sasl-2.1.21 with patch and some work with misslinked files 
inside.

I thinking, that is something wrong with passing parameters via socket.
Comment 2 Matthew Miller 2006-07-10 19:02:15 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 3 John Thacker 2006-10-31 15:33:49 EST
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

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