Bug 2322 - reply_sesssetup_and_X pulling wrong length password off wire?
Summary: reply_sesssetup_and_X pulling wrong length password off wire?
Status: RESOLVED DUPLICATE of bug 2323
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.0.10
Hardware: All Linux
: P3 critical
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-02-07 11:56 UTC by Thomas Walker
Modified: 2005-02-08 06:31 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Walker 2005-02-07 11:56:03 UTC
Using samba 3.0.10 on RHEL 3 as server (using unencrypted passwords and PAM
auth) and a Win XP client machine.  On initial attempt to connect, we've been
seeing PAM auth failures that I've traced back to the server seeing password =
username despite that not being the case on the wire (password is NULL as
windows appears to be trying NULL before promtping for a password).

Breakpoint 1, reply_sesssetup_and_X (conn=0x0, inbuf=0xf63a4008 "",
    outbuf=0xf6383008 "", length=242, bufsize=131072) at smbd/sesssetup.c:756
756                             BOOL unic=SVAL(inbuf, smb_flg2) &
(gdb) print passlen1
$1 = 1
(gdb) print passlen2
$2 = 0
(gdb) print ra_type
$3 = RA_WIN2K
(gdb) n
758                             if ((ra_type == RA_WINNT) && (passlen2 == 0) &&
unic && passlen1) {
765                                             STR_TERMINATE);
767                             plaintext_password = data_blob(pass,
(gdb) print pass
$4 = "walkert\000\000", '&#65533;' <repeats 1015 times>
(gdb) n
770                     p += passlen1 + passlen2;
(gdb) print plaintext_password
$5 = {data = 0x8397a28 "walkert", length = 8,
  free = 0x81fe968 <free_data_blob>}
(gdb) n
771                     p += srvstr_pull_buf(inbuf, user, p, sizeof(user),
(gdb) print p
$6 = 0xf63a404a "w"
(gdb) n
772                     p += srvstr_pull_buf(inbuf, domain, p, sizeof(domain),
(gdb) print user
$7 = "walkert\000\000", '&#65533;' <repeats 247 times>

Note that it reads the next null terminated string off (an off by one misses the
NULL it is starting on?) but then only advances by 1, thus the next call pulls
off the username and continues on...

Since password is incorrect (Windows didn't even ask yet, entire packet log
attached) but is *not* null, pam_smb cycles through all the various caps/lower
combinations and then fails w/o Windows ever even asking for the password).

Finding user walkert
Trying _Get_Pwnam(), username as lowercase is walkert
Get_Pwnam_internals did find user [walkert]!
checking user=[walkert] pass=[walkert]
pass_check: Checking (PAM) password for user walkert (l=7)
smb_pam_start: PAM: Init user: walkert
smb_pam_start: PAM: setting rhost to:
smb_pam_start: PAM: setting tty
smb_pam_start: PAM: Init passed for user: walkert
smb_pam_auth: PAM: Authenticate User: walkert
smb_pam_auth: PAM: Athentication Error for user walkert
smb_pam_error_handler: PAM: Authentication Failure : Authentication failure
smb_pam_passcheck: PAM: smb_pam_auth failed - Rejecting User walkert !
smb_pam_end: PAM: PAM_END OK.
< ... >

If I start an ealier version of the smb server and connect once (causing windows
to cache connection info for that server) and then bring up 3.0.10 it connects
just fine (presumably windows uses the cached info from the previous connection
attempt).  smbclient from unix also appears to do the right thing.

Major problem as we're trying to upgrade to resolve some security problems...

Thanks for looking into it,

Comment 1 Gerald (Jerry) Carter (dead mail address) 2005-02-07 15:43:11 UTC

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