Bug 1795 - An integer variable "num" in mm_answer_pam_query() is not initialized before used
Summary: An integer variable "num" in mm_answer_pam_query() is not initialized before ...
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: PAM support (show other bugs)
Version: 5.5p1
Hardware: All All
: P2 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_5_6
  Show dependency treegraph
 
Reported: 2010-07-13 19:11 AEST by Bitman Zhou
Modified: 2010-08-27 10:28 AEST (History)
2 users (show)

See Also:


Attachments
openssh-init-pam-vars.patch (578 bytes, text/plain)
2010-08-03 15:43 AEST, Darren Tucker
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bitman Zhou 2010-07-13 19:11:18 AEST
An integer variable "num" in mm_answer_pam_query() is not
initialized before used if pam module has errors. This happens on HP-UX where the gcc compiler doesn't do default initialization.

------ code ------

int
mm_answer_pam_query(int sock, Buffer *m)
{
        char *name, *info, **prompts;
        u_int i, num, *echo_on;   <== num is not initialized and could be a random large number
        int ret;

        debug3("%s", __func__);
        sshpam_authok = NULL;
        ret = (sshpam_device.query)(sshpam_ctxt, &name, &info, &num, &prompts, &echo_on);   <== num may not be altered in this call
        if (ret == 0 && num == 0)
                sshpam_authok = sshpam_ctxt;
        if (num > 1 || name == NULL || info == NULL)
                ret = -1;
        buffer_clear(m);
        buffer_put_int(m, ret);
        buffer_put_cstring(m, name);
        xfree(name);
        buffer_put_cstring(m, info);
        xfree(info);
        buffer_put_int(m, num);
        for (i = 0; i < num; ++i) { 
                buffer_put_cstring(m, prompts[i]);  <== fail here!
                xfree(prompts[i]);
                buffer_put_int(m, echo_on[i]);
        }


------- sshd debug log -----------

debug3: PAM: sshpam_init_ctx entering
debug3: mm_request_send entering: type 49
debug3: mm_sshpam_query
debug3: mm_request_send entering: type 50
debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY
debug3: mm_request_receive_expect entering: type 51
debug3: mm_request_receive entering
debug3: mm_request_receive entering
debug3: monitor_read: checking request 50
debug3: mm_answer_pam_query
debug3: PAM: sshpam_query entering
debug3: ssh_msg_recv entering
buffer_put_cstring: s == NULL
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: do_cleanup
debug3: PAM: sshpam_thread_cleanup entering
Comment 1 Tomas Mraz 2010-07-14 00:33:47 AEST
I suppose the buffer_put_cstring that fails is a different one. Most probably some in the sshpam_thread_conv() function. And that some module in the PAM stack passes incorrect values to the PAM conversation function.

in the sshpam_query the only situation where num would be left uninitialized is when neither of PAM_AUTH_ERR, PAM_ACCT_EXPIRED and PAM_SUCCESS messages is received and this should not happen due to the way sshpam_thread() function is written.
Comment 2 Darren Tucker 2010-07-19 13:23:38 AEST
Could you please run this test program on your system?  It'll give us some idea of what PAM is doing under the covers.

http://www.zipworld.com.au/~dtucker/patches/pam-test-harness.c

# ./pam-test-harness -u [youruser] -s sshd
Comment 3 Darren Tucker 2010-08-03 15:43:48 AEST
Created attachment 1908 [details]
openssh-init-pam-vars.patch

Initialize to sane values.
Comment 4 Darren Tucker 2010-08-03 15:51:38 AEST
Thanks for the report, the attached patch has been applied and will be in the 5.6p1 release.
Comment 5 Darren Tucker 2010-08-27 10:28:02 AEST
With the release of OpenSSH 5.6p1 this bug is now considered closed.  If you have further problems please reopen or file a new bug as appropriate.