RE: Fatal core dump on using Purify instrumented binary on Solaris. - Openssl

This is a discussion on RE: Fatal core dump on using Purify instrumented binary on Solaris. - Openssl ; > hi all, > We are using openssl 0.9.8g with our product and everything > worked fine till now. We are now trying to check memory leak > in our code using Purify. But unfortunately our executable core > dumped ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: RE: Fatal core dump on using Purify instrumented binary on Solaris.

  1. RE: Fatal core dump on using Purify instrumented binary on Solaris.


    > hi all,
    > We are using openssl 0.9.8g with our product and everything
    > worked fine till now. We are now trying to check memory leak
    > in our code using Purify. But unfortunately our executable core
    > dumped soon after it called PKCS12_parse(). I have attached the
    > entire purify log file. please let me know what am missing here.


    >-Thanks and Regards,
    >-Sanjith.


    It looks like purify found a bug in your code. You need to debug it. The log
    says:

    MSE: Memory segment error:
    DES_ofb64_encrypt [libcrypto.a]
    des_ede_cbc_cipher [e_des3.c]
    EVP_EncryptUpdate [libcrypto.a]
    EVP_CipherUpdate [libcrypto.a]
    PKCS12_pbe_crypt [libcrypto.a]
    PKCS12_item_decrypt_d2i [libcrypto.a]
    parse_bag [p12_kiss.c]
    parse_bags [p12_kiss.c]
    PKCS12_parse [libcrypto.a]
    testParseKeystore [zuopenssl.c:265]
    testGetLocalHostPrivateKeyFromKeystore [zuopenssl.c:398]

    So your code called PKCS12_parse which eventually called a DES function with
    a bad pointer. Most likely, this is because there is someting wrong with the
    PKCS12 structure you passed to PKCS12_parse, but there's no way for us to
    tell.

    At least, that would be the most obvious explanation. It could always be
    something weirder. We can't debug the code in zuopenssl.c without being able
    to see it.

    You have gotten the first piece of evidence that there is something wrong
    with your code. So start debugging it.

    There are a large family of bugs that are almost always harmless in release
    builds but fatal in some kinds of debug builds. For example, if you allocate
    121 bytes of memory but write 122 bytes, a release build will almost always
    wind up actually allocating at least 122 bytes, so the overwrite will be
    harmless. A debug build tries to consider any write to memory that was never
    allocated fatal -- since it's never something you're supposed to do.

    You have likely encountered a bug in that family of bugs. Almost always
    harmless in release, possibly fatal in special debug builds. Find it, and
    fix it. If it's of the "always harmless" variety, then your code will just
    be nicer. If it's of the "almost always harmless" variety, then finding and
    fixing it may well prevent rare, hard-to-debug crashes in your release code.

    It could also turn out to be a bug in OpenSSL. If you suspect this, try to
    provide a compact example program that replicates this problem, and post it
    to the list. (Or debug it yourself if you can.) But start out checking the
    code right before the call to PKCS12_parse. There's at least a 80% chance
    that's where the problem is.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: Fatal core dump on using Purify instrumented binary on Solaris.

    Thanks a lot David for the detailed explanation. I am analyzing our code
    now. our functions is shown below. pls check if you can quickly find any
    mistake there.

    int testParseKeystore
    (
    const char *keyStoreFilePath,
    const char *password,
    EVP_PKEY **priKey,
    X509 **cert,
    STACK_OF(X509) **ca
    )
    {
    FILE *fp = NULL;
    PKCS12 *p12 = NULL;

    OpenSSL_add_all_algorithms();
    loadOpenSSLCryptoErrorStrings();

    /* first read the keystore. */
    if ((fp = fopen(keyStoreFilePath, "rb")) == NULL)
    {
    printf("Failed to open key store file : %s.\n", keyStoreFilePath);
    return -1;
    }

    p12 = d2i_PKCS12_fp(fp, NULL);
    fclose(fp);

    if (p12 == NULL)
    {
    printf("Failed to get certificate file from location: %s \n
    Error:%s\n",
    keyStoreFilePath, ERR_error_string(ERR_get_error(),
    NULL));
    return -1;
    }

    /* get the private key and the certificate */
    if (!PKCS12_parse(p12, password, priKey, cert, ca))
    {
    printf("Failed parsing key store file from location: %s \n
    Error:%s\n",
    keyStoreFilePath, ERR_error_string(ERR_get_error(),
    NULL));
    return -1;
    }

    if (priKey != NULL && *priKey == NULL)
    {
    printf("Failed to extract private key from keystore location: %s \n
    Error:%s\n",
    keyStoreFilePath, ERR_error_string(ERR_get_error(),
    NULL));
    return -1;
    }

    if (cert != NULL && *cert == NULL)
    {
    printf("Failed to extract certificate from keystore: %s \n
    Error:%s\n",
    keyStoreFilePath, ERR_error_string(ERR_get_error(),
    NULL));
    return -1;
    }

    PKCS12_free(p12);
    return 0;
    }


    On a same note will functions like CRYPTO_malloc_init() and
    CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON) help me in any way to analyse the
    issue?

    -Thanks and Regards,
    -Sanjith.

    On Wed, Aug 13, 2008 at 4:38 AM, David Schwartz wrote:

    >
    > > hi all,
    > > We are using openssl 0.9.8g with our product and everything
    > > worked fine till now. We are now trying to check memory leak
    > > in our code using Purify. But unfortunately our executable core
    > > dumped soon after it called PKCS12_parse(). I have attached the
    > > entire purify log file. please let me know what am missing here.

    >
    > >-Thanks and Regards,
    > >-Sanjith.

    >
    > It looks like purify found a bug in your code. You need to debug it. The
    > log
    > says:
    >
    > MSE: Memory segment error:
    > DES_ofb64_encrypt [libcrypto.a]
    > des_ede_cbc_cipher [e_des3.c]
    > EVP_EncryptUpdate [libcrypto.a]
    > EVP_CipherUpdate [libcrypto.a]
    > PKCS12_pbe_crypt [libcrypto.a]
    > PKCS12_item_decrypt_d2i [libcrypto.a]
    > parse_bag [p12_kiss.c]
    > parse_bags [p12_kiss.c]
    > PKCS12_parse [libcrypto.a]
    > testParseKeystore [zuopenssl.c:265]
    > testGetLocalHostPrivateKeyFromKeystore [zuopenssl.c:398]
    >
    > So your code called PKCS12_parse which eventually called a DES function
    > with
    > a bad pointer. Most likely, this is because there is someting wrong with
    > the
    > PKCS12 structure you passed to PKCS12_parse, but there's no way for us to
    > tell.
    >
    > At least, that would be the most obvious explanation. It could always be
    > something weirder. We can't debug the code in zuopenssl.c without being
    > able
    > to see it.
    >
    > You have gotten the first piece of evidence that there is something wrong
    > with your code. So start debugging it.
    >
    > There are a large family of bugs that are almost always harmless in release
    > builds but fatal in some kinds of debug builds. For example, if you
    > allocate
    > 121 bytes of memory but write 122 bytes, a release build will almost always
    > wind up actually allocating at least 122 bytes, so the overwrite will be
    > harmless. A debug build tries to consider any write to memory that was
    > never
    > allocated fatal -- since it's never something you're supposed to do.
    >
    > You have likely encountered a bug in that family of bugs. Almost always
    > harmless in release, possibly fatal in special debug builds. Find it, and
    > fix it. If it's of the "always harmless" variety, then your code will just
    > be nicer. If it's of the "almost always harmless" variety, then finding and
    > fixing it may well prevent rare, hard-to-debug crashes in your release
    > code.
    >
    > It could also turn out to be a bug in OpenSSL. If you suspect this, try to
    > provide a compact example program that replicates this problem, and post it
    > to the list. (Or debug it yourself if you can.) But start out checking the
    > code right before the call to PKCS12_parse. There's at least a 80% chance
    > that's where the problem is.
    >
    > DS
    >
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



+ Reply to Thread