Skip Menu |
 

Date: Mon, 24 Sep 2007 20:03:18 +0530
From: eswars <eswars@huawei.com>
Subject: RE: krb5_cc_resolve is crashing in windows XP j
To: kfw-bugs@mit.edu
CC: altman@secure-endpoints.com
Download (untitled) / with headers
text/plain 1.5KiB
Hi Jeffrey,
It is failed when cred.client is assigned to temp variable inside following
function.
krb5_copy_principal(context, creds.client, &data->princ). After this
assignment there is NULL check, but it is failing before it self.

I fixed this problem as following. Only one null check is missed.
lib/krb5/ccache/cc_mslsa.c
static krb5_error_code KRB5_CALLCONV
krb5_lcc_resolve (krb5_context context, krb5_ccache *id, const char
*residual){
...............
if (!MSCredToMITCred(msticket, msticket->DomainName, context, &creds))
retval = KRB5_FCC_INTERNAL;
LsaFreeReturnBuffer(msticket);
if(NULL == creds.client)
{
return KRB5_FCC_NOFILE;// please provide me correct
error code. What I can return.
}
...................................
}
This has been produced in windows xp sp2 /sp0 English if you logged in as
Domain administrator as per my analysis.
Please provide me why it is caused.
One request I wanted VC++ solution files for building/ debugging libraries
where can I get those.

Regards,
Eswar s

****************************************************************************
****************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
Download (untitled) / with headers
text/plain 2.4KiB
[eswars@huawei.com - Mon Sep 24 10:32:06 2007]:

Show quoted text
> Hi Jeffrey,
> It is failed when cred.client is assigned to temp variable inside
> following
> function.
> krb5_copy_principal(context, creds.client, &data->princ). After this
> assignment there is NULL check, but it is failing before it self.
>
> I fixed this problem as following. Only one null check is missed.
> lib/krb5/ccache/cc_mslsa.c
> static krb5_error_code KRB5_CALLCONV
> krb5_lcc_resolve (krb5_context context, krb5_ccache *id, const char
> *residual){
> ...............
> if (!MSCredToMITCred(msticket, msticket->DomainName, context, &creds))
> retval = KRB5_FCC_INTERNAL;
> LsaFreeReturnBuffer(msticket);
> if(NULL == creds.client)
> {
> return KRB5_FCC_NOFILE;// please provide me correct
> error code. What I can return.
> }
> ...................................
> }

This would not be the correct fix. MSCredToMITCred() should not return
success if the creds.client can not be assigned.

Show quoted text
> This has been produced in windows xp sp2 /sp0 English if you logged in
> as
> Domain administrator as per my analysis.

I logged into my XP SP2 US-English system with the Domain Administrator
account before my initial reply to you and executed this code path
successfully. Its not just that the account is the domain
administrator. There is something else.

Please try this patch:

Index: cc_mslsa.c
===================================================================
--- cc_mslsa.c (revision 19964)
+++ cc_mslsa.c (working copy)
@@ -378,8 +378,8 @@
wcscat(princbuf, L"@");
wcscat(princbuf, realm);
if (UnicodeToANSI(princbuf, aname, sizeof(aname))) {
- krb5_parse_name(context, aname, principal);
- return TRUE;
+ if (krb5_parse_name(context, aname, principal) == 0)
+ return TRUE;
}
return FALSE;
}
@@ -404,8 +404,8 @@
wcscat(princbuf, L"@");
wcscat(princbuf, realm);
if (UnicodeToANSI(princbuf, aname, sizeof(aname))) {
- krb5_parse_name(context, aname, principal);
- return TRUE;
+ if (krb5_parse_name(context, aname, principal) == 0)
+ return TRUE;
}
return FALSE;
}



Show quoted text
> Please provide me why it is caused.
> One request I wanted VC++ solution files for building/ debugging
> libraries
> where can I get those.

There are no VC++ solution files. KFW is built as described in the
release notes using command-line tools including perl and nmake. The
resulting binaries are built with symbol data that can be used for
debugging.
I would be interested in knowing why the

krb5_parse_name(context, aname, principal)

call in KerbExternalNameToMITPrinc() is failing.

What is the content of the 'aname' buffer?
Revised patch. UnicodeToANSI() could have failed and still returned
success.

Index: cc_mslsa.c
===================================================================
--- cc_mslsa.c (revision 19964)
+++ cc_mslsa.c (working copy)
@@ -312,15 +312,23 @@
{
return FALSE;
} else {
- WideCharToMultiByte(CP_ACP, 0, (LPCWSTR) lpInputString, -1,
- lpszOutputString, nOutStringLen, NULL,
NULL);
+ if (WideCharToMultiByte(CP_ACP,
+ WC_NO_BEST_FIT_CHARS |
WC_COMPOSITECHECK,
+ (LPCWSTR) lpInputString, -1,
+ lpszOutputString,
+ nOutStringLen, NULL, NULL) == 0)
+ return FALSE;
}
}
else if (((LPBYTE) lpInputString)[1] == '\0')
{
// Looks like unicode, better translate it
- WideCharToMultiByte(CP_ACP, 0, (LPCWSTR) lpInputString, -1,
- lpszOutputString, nOutStringLen, NULL, NULL);
+ if (WideCharToMultiByte(CP_ACP,
+ WC_NO_BEST_FIT_CHARS | WC_COMPOSITECHECK,
+ (LPCWSTR) lpInputString, -1,
+ lpszOutputString,
+ nOutStringLen, NULL, NULL) == 0)
+ return FALSE;
}
else
lstrcpyA(lpszOutputString, (LPSTR) lpInputString);
@@ -378,8 +386,8 @@
wcscat(princbuf, L"@");
wcscat(princbuf, realm);
if (UnicodeToANSI(princbuf, aname, sizeof(aname))) {
- krb5_parse_name(context, aname, principal);
- return TRUE;
+ if (krb5_parse_name(context, aname, principal) == 0)
+ return TRUE;
}
return FALSE;
}
@@ -404,8 +412,8 @@
wcscat(princbuf, L"@");
wcscat(princbuf, realm);
if (UnicodeToANSI(princbuf, aname, sizeof(aname))) {
- krb5_parse_name(context, aname, principal);
- return TRUE;
+ if (krb5_parse_name(context, aname, principal) == 0)
+ return TRUE;
}
return FALSE;
}
Assuming that the real issue is that the principal name contained
Unicode characters that are not represented in ISO Latin-1, then this
bug should be resolved in KFW 3.2.2 which will enter beta test this
coming week.

If you still experience the problem with KFW 3.2.2, please submit a new
bug report.