FW: [krbdev.mit.edu #6777] Segmentation fault in krb library (sn2princ.c) if realm not resolved

[Krier@krbdev.mit.edu]

Greg, 

Thanks for making the fix so quickly; your mail arrived while I was writing to you. 

I think it would be worth trying to fix the issue where krb5_get_host_realm() is not returning the default_realm in 64bit mode.
My guess is it relates to the parsing code, or somewhere close by.

Richard

-----Original Message-----
From: Krier, Richard 
Sent: Wednesday, September 15, 2010 2:20 PM
To: 'rt-comment at krbdev.mit.edu'
Cc: Adhikari, Diwas; Pinto, Kevin
Subject: RE: [krbdev.mit.edu #6777] Segmentation fault in krb library (sn2princ.c) if realm not resolved 

Hello Greg,

Thanks for the feedback. 

Recently we built the krb5-1.6.3 kerberos libraries on AIX 5.3 in 64-bit mode for use with a manufacturing application. Previously we built them in 32-bit mode for an earlier version of the application.  We use both versions at this time, as the 64-bit version is just being prepared for use in production.  

1. Adding a check in sname_to_princ() for null *ret_princ coming back from krb5_build_principal would prevent the 
   segmentation fault we experienced. Thanks for accepting that recommendation.  Can you tell me when and how we could obtain 
   the fixed version of this source file?

2. As for krb5_build_principal(), seems the code is set up to return null ret_princ if the input realm is missing, 
   think it is working as designed.

3. I think the root of our problem is related to building the code in 64-bit mode; krb5_get_host_realm() behaves
   differently in 32-bit and 64-bit mode in the case where the realm cannot be resolved from the host name:
	a. In 32-bit mode, it properly returns the default_realm value specified value specified in [libdefaults] stanza.
	b. In 64-bit mode, it only returns the zero-length string
	
4. Possibly the parsing code for krb5.conf is not correct in 64bit mode, perhaps due to the lengths of pointers. longs, 
   etc - it may be incurring some typical issues when migrating legacy C/C++ code from 32-bit to 64-bit.  
	a. I did not have a chance to investigate the parsing code. Thus far we've avoided making changes to the kerberos 
         source, trying only to build the libraries using the as-downloaded code, using the AIX xlC_r compiler in 64-bit mode.     
	b. To build in 64-bit mode, I set the following environment variables before running make:
  		export OBJECT_MODE=64
		export LDFLAGS='-brtl -L$(DB2DIR)/lib64'

5. We created a small stand-alone test program (krb5test) to simulate how our application interacts with kerberos and to 
   reproduce the problem, and to compare 32-bit and 64-bit results. I can ask for permission to send it to you if you would 
   find it useful.  

6. Also have a version of 3 or 4 kerberos source files in which we added some debug tracing to track down the crash
   problem; we only used this modified version in our development environment to identify why the segmentation fault was 
   occurring. Otherwise we've only used unmodified source. For further investigation of the parsing code issue, would extend 
   this tracing a little farther into that source file. 

Regards,
Richard

  

-----Original Message-----
From: Greg Hudson via RT [mailto:rt-comment at krbdev.mit.edu] 
Sent: Tuesday, September 14, 2010 6:07 PM
To: Krier, Richard
Subject: [krbdev.mit.edu #6777] Segmentation fault in krb library (sn2princ.c) if realm not resolved 

[Richard.Krier at globalfoundries.com - Tue Sep 14 15:10:55 2010]:
>               2. If realm unresolved, krb5_get_host_realm() returns a
> zero-length string, i.e. 1 byte containing just '\0'

This is not actually an error condition.  The empty string is returned 
here to indicate that the caller should try referrals.  So step 3 is 
actually correct.

>               3. sname_to_princ() then calls krb5_build_principal(),
> principal not created in this case, *ret_princ is NULL
> ALSO HERE:       No check is made to determine if *ret_princ is NULL
> before using it to make an assignment as point 4.

Failing to check retval here is a bug, and we'll fix it.  However, 
krb5_build_principal() should succeed in the scenario you described; I 
would be interested to know why it is failing in your use case.