Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Crash while freeing data.

15 views
Skip to first unread message

sasikumar bodathula

unread,
May 21, 2013, 11:00:52 PM5/21/13
to kerb...@mit.edu
Hi,
  I am using kerberos 1.11.2 version for development while using the pkinit option for certificate implementation observed a crash.

Steps followed:-

Set pkinit details using
krb5_get_init_creds_opt_set_pa -- set anchor and identity options.

 krb5_get_init_creds_password - with password as empty since in certificate password will not be supplied and password promter as NULL and other details as mentioned in the documentation.

Is this related to the data present in the certificates?

Certificates were generated with the steps mentioned in MIT site.


Crash point

 #0  0x00007f2f8c55129b in raise () from /lib64/libc.so.6
#1  0x00007f2f8c5527f3 in abort () from /lib64/libc.so.6
#2  0x00007f2f8c58dc28 in __libc_message () from /lib64/libc.so.6
#3  0x00007f2f8c5931b8 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f2f8c594d76 in free () from /lib64/libc.so.6
#5  0x00007f2f832b39aa in cms_signeddata_create (context=0x56a2400, plg_cryptoctx=0x56a4840, req_cryptoctx=0x56a4ca0, id_cryptoctx=0x56a4e50, cms_msg_type=0,
    include_certchain=1,
    data=0x56a56a0 "0|�<0:�\005\002\003\004�\205�\021\030\01720130521130048Z�\006\002\004T�\230\224�\026\004\024�\230EO\233�\025�Xi\207\231\n�2[�>T\225�\0160\f0\n\006\b*\206H\206�\r\003\a�,0*0\f�\n\006\b+\006\001\005\002\003\006\0020\f�\n\006\b+\006\001\005\002\003\006\0010\f�\n\006\b+\006\001\005\002\003\006\003", data_len=126,
    signed_data=0x56a52b8, signed_data_len=0x56a52b4) at pkinit_crypto_openssl.c:1190
#6  0x00007f2f832ac79c in pkinit_as_req_create (context=0x56a2400, plgctx=0x56a47f0, reqctx=0x56a4de0, ctsec=1369141248, cusec=315781, nonce=1420859540,
    cksum=0x5492900, client=0x56a4420, server=0x56a5160, as_req=0x5492928) at pkinit_clnt.c:374
#7  0x00007f2f832abfdd in pa_pkinit_gen_req (context=0x56a2400, plgctx=0x56a47f0, reqctx=0x56a4de0, request=0x56a4b80, pa_type=16, out_padata=0x5492a80,
    prompter=0x409ab0 <krb5_prompter_posix@plt>, prompter_data=0x0, gic_opt=0x56a3170) at pkinit_clnt.c:157
#8  0x00007f2f832ade77 in pkinit_client_process (context=0x56a2400, moddata=0x56a47f0, modreq=0x56a4de0, gic_opt=0x56a3170, cb=0x7f2f8b1c2620, rock=0x56a4b08,
    request=0x56a4b80, encoded_request_body=0x56a53a0, encoded_previous_request=0x0, in_padata=0x56a5110, prompter=0x409ab0 <krb5_prompter_posix@plt>,
    prompter_data=0x0, out_padata=0x5492a80) at pkinit_clnt.c:1082
#9  0x00007f2f8af4587b in run_preauth_plugins (kcontext=0x56a2400, module_required_flags=1, request=0x56a4b80, encoded_request_body=0x56a53a0,
    encoded_previous_request=0x0, in_padata=0x56a5110, prompter=0x409ab0 <krb5_prompter_posix@plt>, prompter_data=0x0, preauth_rock=0x56a4b08, out_pa_list=0x5492b50,
    out_pa_list_size=0x5492b60, module_ret=0x5492b34, module_flags=0x5492b30, opte=0x56a3170) at preauth2.c:501

Best Regards,

B.Sasikumar.

Greg Hudson

unread,
May 22, 2013, 12:39:57 AM5/22/13
to sasikumar bodathula, kerb...@mit.edu
On 05/21/2013 11:00 PM, sasikumar bodathula wrote:
> Hi,
>   I am using kerberos 1.11.2 version for development while using the pkinit option for certificate implementation observed a crash.

I don't suppose you can run this through valgrind? Crashing in free()
implies a previous memory error (which might have been in OpenSSL,
libkrb5, or the application), and it's much easier to debug if you can
find the original error.


sasikumar bodathula

unread,
May 22, 2013, 2:00:01 AM5/22/13
to Greg Hudson, kerberos
Hi,
  I was using gdb to get the backtrace of the crash.  One more quick question I am using following options while compiling the kerberos

--enable-pkinit=yes and --with-pkinit-crypto-impl=openssl for pkinit do i need both these options for pkinit support or if they are removed from compile options pkinit still works?

Best Regards,

B.Sasikumar.


From: Greg Hudson <ghu...@MIT.EDU>
Sent: Wed, 22 May 2013 10:11:01
To: sasikumar bodathula <sasik...@rediffmail.com>
Cc: "kerb...@mit.edu" <kerb...@mit.edu>
Subject: Re: Crash while freeing data.
On 05/21/2013 11:00 PM, sasikumar bodathula wrote:

> Hi,

>   I am using kerberos 1.11.2 version for development while using the pkinit option for certificate implementation observed a crash.



I don't suppose you can run this through valgrind?  Crashing in free()

Greg Hudson

unread,
May 22, 2013, 2:11:58 AM5/22/13
to sasikumar bodathula, kerberos
On 05/22/2013 02:00 AM, sasikumar bodathula wrote:
> I was using gdb to get the backtrace of the crash.

Yes, but this does not give the backtrace of the original memory access
violation which caused free() to crash later on. valgrind, if you can
use it, will tell you this.

> --enable-pkinit=yes and --with-pkinit-crypto-impl=openssl for pkinit do
> i need both these options for pkinit support or if they are removed from
> compile options pkinit still works?

You should not need either option; PKINIT will be built by default.

sasikumar bodathula

unread,
May 23, 2013, 2:46:43 AM5/23/13
to Greg Hudson, kerberos
Hi,
   Tried valgrind but was not successful since our application does not start with valgrind. Tried with GDB and found the source

Trance is :-

#0  0x00007f8f34cb529b in raise () from /lib64/libc.so.6
#1  0x00007f8f34cb67f3 in abort () from /lib64/libc.so.6
#2  0x00007f8f34cf1c28 in __libc_message () from /lib64/libc.so.6
#3  0x00007f8f34cf71b8 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f8f34cf8d76 in free () from /lib64/libc.so.6
#5  0x00007f8f2ba04e3a in cms_signeddata_create (context=0x56a23c0, plg_cryptoctx=0x56a4bb0, req_cryptoctx=0x56a5160, id_cryptoctx=0x56a5180, cms_msg_type=0,
    include_certchain=1,
    data=0x56a5bf0 "0|�<0:�\005\002\003\002�,�\021\030\01720130523063813Z�\006\002\004d�'l�\026\004\024��\235��\0316�,\034�\226xQ�\004�\022���\0160\f0\n\006\b*\206H\206�\r\003\a�,0*0\f�\n\006\b+\006\001\005\002\003\006\0020\f�\n\006\b+\006\001\005\002\003\006\0010\f�\n\006\b+\006\001\005\002\003\006\003", data_len=126,
    signed_data=0x56a5b28, signed_data_len=0x56a5b24) at pkinit_crypto_openssl.c:1195


Crash Reason:-

In the function cms_signeddata_create we have a pointer called abuf which is initialized to NULL.

FileName :- plugins/preauth/pkinit/pkinit_crypto_openssl.c Line number 1121 "ASN1_item_i2d" following function is called with abuf as one of the argument.

After this function abuf is pointer to the invalid pointer this leads to the crash in same file line number 1195 free(abuf).

Do assist me with this scenario.

Best Regards,

B.Sasikumar.


From: Greg Hudson <ghu...@MIT.EDU>
Sent: Wed, 22 May 2013 11:42:10
To: sasikumar bodathula <sasik...@rediffmail.com>
Cc: kerberos <kerb...@mit.edu>
Subject: Re: Crash while freeing data.
On 05/22/2013 02:00 AM, sasikumar bodathula wrote:

>   I was using gdb to get the backtrace of the crash.



Yes, but this does not give the backtrace of the original memory access

violation which caused free() to crash later on.  valgrind, if you can

use it, will tell you this.



> --enable-pkinit=yes and --with-pkinit-crypto-impl=openssl for pkinit do

> i need both these options for pkinit support or if they are removed from

> compile options pkinit still works?

Greg Hudson

unread,
May 23, 2013, 11:16:14 AM5/23/13
to sasikumar bodathula, kerberos
On 05/23/2013 02:46 AM, sasikumar bodathula wrote:
> In the function cms_signeddata_create we have a pointer called abuf
> which is initialized to NULL.
>
> FileName :- plugins/preauth/pkinit/pkinit_crypto_openssl.c Line number
> 1121 "ASN1_item_i2d" following function is called with abuf as one of
> the argument.
>
> After this function abuf is pointer to the invalid pointer this leads to
> the crash in same file line number 1195 free(abuf).

Looking at the OpenSSL code, ASN1_item_i2d should only fill in abuf with
a pointer returned by CRYPTO_malloc(), which is usually equivalent to
malloc(), unless something has called CRYPTO_set_mem_functions() or
similar. Unless you're doing that in your application, I don't see how
this can explain the crash.

0 new messages