1

I'm trying to use the OpenSSL library for AES encryption. Everything compiles and seems to work fine. However, when I use BIO_dump_fp(stdout, (char*)ciphertext, ciphertext_len) valgrind ends up reporting hundreds of errors, mostly "conditional jump of move depends on uninitialized value(s)" errors, like this one:

Conditional jump or move depends on uninitialised value(s)
    at 0x579A9C3: fwrite (iofwrite.c:49)
    by 0x4F187B0: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
    by 0x4F18AC4: BIO_dump_indent_cb (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
    by 0x401748: main (in /home/van/Desktop/aes-test/temp/test)

Can these errors be safely ignored (i.e. are these false positives)? If it matters, I'm using Ubuntu 14.04, g++ version 4.8.2, valgrind 3.10.

UPDATE: my full source code is as follows:

#include <stdio.h>

#include "QAesHelper.h"

int main(int argc, char *argv[])
{
  unsigned char iv[] = "1234567812345678";
  unsigned char key[] = "Testing Testing...";
  printf("Size of key: %d\n", (int)sizeof(key));

  unsigned char plaintext[] = "The quick brown fox jumps over the lazy dog";
  int plaintext_len = sizeof(plaintext);
  printf("Size of plaintext: %d\n", plaintext_len);
  unsigned char *ciphertext = (unsigned char*)malloc(plaintext_len + 32);
  unsigned char *decryptedtext = (unsigned char*)malloc(plaintext_len + 2);

  QAesHelper *aesHelper = new QAesHelper(key, sizeof(key));
  int ciphertext_len = aesHelper->encrypt(plaintext, plaintext_len, iv, sizeof(iv), &ciphertext);
  int decryptedtext_len = aesHelper->decrypt(ciphertext, ciphertext_len + 1, iv, sizeof(iv), &decryptedtext);
  // If I remove the following line (BIO_dump_fp...), then
  // valgrind reports no errors. With this line left in, there
  // are over 900 errors reported.
  BIO_dump_fp(stdout, (char*)ciphertext, ciphertext_len);
  delete aesHelper;

  free(ciphertext);
  free(decryptedtext);

  return 0;
}

And QAesHelper::encrypt() is:

int QAesHelper::encrypt(unsigned char *plaintext, int plaintext_len, unsigned char *iv, int iv_len, unsigned char **ciphertext)
{
  EVP_CIPHER_CTX *ctx;

  int len;
  int ciphertext_len;

  if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();

  if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
    handleErrors();

  if(1 != EVP_EncryptUpdate(ctx, *ciphertext, &len, plaintext, plaintext_len))
    handleErrors();
  ciphertext_len = len;

  if(1 != EVP_EncryptFinal_ex(ctx, *ciphertext + len, &len)) handleErrors();
  ciphertext_len += len;

  EVP_CIPHER_CTX_free(ctx);

  return ciphertext_len;
}
Vanessa Deagan
  • 417
  • 6
  • 15
  • First of all you should probably be building with debug information, so Valgrind can read the debug-info and give you source file-names and line-numbers. Secondly, please show the actual code causing the warning, if nothing else to show that it's nothing in your code that's causing it. – Some programmer dude Feb 13 '15 at 11:53
  • I'm building with the -g flag. Is there something else I need to build with to include more debug info? I'm assuming meaningful names are missing because the OpenSSL dev package I installed was not built with debug info. I will update the question to include my source code. – Vanessa Deagan Feb 13 '15 at 12:22
  • I was just expecting to see file-name/line-number information for `main` as well. You don't *strip* the debug info later? – Some programmer dude Feb 13 '15 at 12:26
  • 1
    Yes, you can ignore this errors. http://stackoverflow.com/questions/3174468/is-it-possible-to-make-valgrind-ignore-certain-libraries – Vladimir Kunschikov Feb 13 '15 at 13:58
  • Thanks @VladimirKunschikov. This problem was driving me crazy. Will close this question. – Vanessa Deagan Feb 13 '15 at 16:20
  • @VladimirKunschikov - could you change your comment in to an answer so I can select it as an answer? Not sure how to close this question without an answer. – Vanessa Deagan Feb 16 '15 at 09:46
  • 'Answered' it, and one more thing - openssl library requires multi thread setup if it is used in application with threads. Easy to google, without threading callbacks it can even segfault on accept in thread, valgrind won't help because it slow down app and wont segfault. It can became 'strange' hard to track down memory error. – Vladimir Kunschikov Feb 16 '15 at 10:14

1 Answers1

2

Its not an error. OpenSSL heavily uses uninitialized memory segments. Valgrind treats such usage as error and warns about it. Its normal behaviour which can be beautified in some extent:

  • write and use valgrind suppression file valgrind --gen-suppressions=no|yes|all
  • compile openssl with PURIFY macro enabled in cflags
  • push to valgrind --error-limit=no and ignore warnings from libssl/libcrypto
Vladimir Kunschikov
  • 1,735
  • 1
  • 16
  • 16