Strange segmentation fault in libkrb5.so.3.3 (1.6.4-beta1)

[Dan Searle]

Hi,

Ok I have more information that might highlight a bug in krb5 libs, the 
seg faults keep happening (with top of stack in ld-linux as below). 
However I've worked out an interesting pattern to them.

These seg faults (example stack trace below) only and always happen when 
users who have expired passwords try to authenticate against an active 
directory KDC.

(gdb) bt
#0  0xb7f6d38b in ?? () from /lib/ld-linux.so.2
#1  0xb7f72c80 in ?? () from /lib/ld-linux.so.2
#2  0xb776d84a in krb5_get_init_creds_password (context=0x9d01538,
   creds=0x82bb6b0, client=0x8361cd8, password=0x82bb750 "******",
   prompter=0xb5c3ced0, data=0x9dbcf90, start_time=0, in_tkt_service=0x0,
   options=0x82bb708) at gic_pwd.c:398
#3  0xb5c3a326 in ?? () from /lib/security/pam_krb5.so
#4  0xb5c380be in pam_sm_authenticate () from /lib/security/pam_krb5.so
#5  0xb7dcd1c8 in ?? () from /lib/libpam.so.0
#6  0xb7dcca8d in pam_authenticate () from /lib/libpam.so.0

------------------------[snip]----------------------------------------------- 


What is different about the code path in libkrb5 when a user 
authenticates who's password has expired? Rather than trying to fix the 
bug, can I not simply reconfigure libkrb5 to not authenticate them and 
not use the code path which causes the segfault?

Regards, Dan...

Russ Allbery wrote:
> Dan Searle <dan.searle at censornet.com> writes:
>
>   
>> If memory clobbering is causing an invalid call to free() then why is 
>> the top of the stack trace showing to calls within ld-linux? and why is 
>> there no call to free()?
>>     
>
> It's unfortunately very common for gdb to get completely confused by
> memory overruns.  It's more common if the stack got smashed, but I would
> not be horribly surprised to see this sort of backtrace for a heap
> clobber.
>
>   
>> There are enough debug symbols in libc for that. Also it's not proacicle
>> to run the application in valgrind because this error only happens once
>> every couple of days or so in a production environment and the
>> applicationw would run too slowly to be useful and also the memory
>> requirements would be too large.
>>     
>
> Well, one of the nice things about valgrind is that it will actually catch
> the memory clobber, if there is one, even if it doesn't cause a problem
> that particular time.  So you can catch problems that will only cause
> crashes if all the bits line up unluckily.  So I would still start by
> trying valgrind.
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.730 / Virus Database: 271.1.1/2643 - Release Date: 01/24/10 19:33:00
>
>   


-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.