I have a program that for some time now under SUSE Linux Enterprise Server has worked fine. Recently, it was moved over to an OpenSUSE 13.2 system and a problem was encountered. The program interfaces to a 3rd party and data is received into our program where the data block consists of some header information and AES encrypted data. Using the OpenSSL libcrypto library we successfully interfaced to this system under SLES. However, under OpenSUSE we consistently see the an error where the end of the decrypted data contains garbage. I have identified where the problem happens and have a work around but in looking at the code, I don’t see why there would be a problem.
I have created a test program that simulates the problem. The test program works fine under SUSE Linux Enterprise Server 11 and on a Red Hat 7.2 Enterprise Linux but fails on OpenSUSE 13.2 using different release levels of the OpenSSL libraries. Under SLES and Red Hat, the decrypted data is cleanly returned. Under OpenSUSE, most of the data is decrypted cleanly except for some garbage that appears toward the end of the data block. The returned block of data is correct, then contains some garbage, and then ends correct. The code for my sample program is below but the line causing the problem is a memcpy() where I shift the encrypted data to the front of the data block for processing. The line in my sample program is below:
// Generates Garbage memcpy(encbuf, encbuf+100, enclen);
If I move the encrypted data to temporary buffer before moving it to the start of the encbuf, the garbage is not generated.
// This does not generate garbage memcpy(tmpbuf, encbuf+100, enclen); memcpy(encbuf, tmpbuf, enclen);
My sample program takes a defined buffer of clear text, encrypts it using a key and IV and then decrypts it back and displays the result. Condensed code is as follows:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <time.h>
#include <fcntl.h>
#include <sys/types.h>
#include <openssl/evp.h>
#define EVP_DECRYPT 0
#define EVP_ENCRYPT 1
char clrbuf[100000];
char encbuf[100000];
char tmpbuf[100000];
int clrlen;
int enclen;
char enckey[1024];
unsigned char enciv[16];
main()
{
int rc;
// Set clear text to 50 lines of text
sprintf(clrbuf,
"0001this is a test this is a test this is a test this is a testn"
"0002this is a test this is a test this is a test this is a testn"
"0003this is a test this is a test this is a test this is a testn"
// etc etc etc……………….
"0048this is a test this is a test this is a test this is a testn"
"0049this is a test this is a test this is a test this is a testn"
"0050this is a test this is a test this is a test this is a testn"
sprintf(enckey, "this is the key this is the key ");
sprintf(enciv, "1234567890123456");
// Encrypt the data and simulate a 100 byte header by returning encrypted data 100 bytes into the data block
//
memcpy(encbuf, "Some header stuff that will need to be removed", 46);
rc = evp_aes256_cbc(clrbuf, strlen(clrbuf), encbuf+100, &enclen, enckey, enciv, EVP_ENCRYPT);
// Now remove the header by shifting the encrypted data to the start of the data block and decrypt
// This is where doing the memcpy() as coded in OpenSUSE results in garbage at the end of clrbuf
// but everything is returned correctly in SLES and Red Hat
//
// This work fines on all OSes:
// memcpy(tmpbuf, encbuf+100, enclen);
// memcpy(encbuf, tmpbuf, enclen);
memcpy(encbuf, encbuf+100, enclen);
rc = evp_aes256_cbc(encbuf, enclen, clrbuf, &clrlen, enckey, enciv, EVP_DECRYPT);
printf("Decrypt: rc=%d EncLen=%d ClrLen=%dn", rc, enclen, clrlen);
printf("Data:nn<n%sn>nn", clrbuf);
}
/****************************************************************************/
evp_aes256_cbc(char *InBuf, int InLen, char *OutBuf, int OutLen, char *Key, char *IV, int EncryptFlag)
{
EVP_CIPHER_CTX ctx;
int padlen;
EVP_CIPHER_CTX_init(&ctx);
if (! EVP_CipherInit_ex(&ctx, EVP_aes_256_cbc(), NULL, Key, IV, EncryptFlag))
return(0);
if (! EVP_CipherUpdate(&ctx, OutBuf, OutLen, InBuf, InLen))
return(0);
if (! EVP_CipherFinal_ex(&ctx, OutBuf+(*OutLen), &padlen))
return(0);
*OutLen = *OutLen + padlen;
EVP_CIPHER_CTX_cleanup(&ctx);
return(1);
}
On SLES and Red Hat, final output looks like:
0046this is a test this is a test this is a test this is a test
0047this is a test this is a test this is a test this is a test
0048this is a test this is a test this is a test this is a test
0049this is a test this is a test this is a test this is a test
0050this is a test this is a test this is a test this is a test
On OpenSUSE, final output can look like:
0046this is a test this is a test this is a test this is a test
0047this is a test this is a test this is a test this is a test
0048this is a test this is a tes╧┬S_úReÅ▌
|τZk╠½çP≥ii≡w╙p▓8ª’MêÅt▒g{Y¥ΩEô¬ ⌡n}⌐*╘¿µ2└╠LS4=Qüü├;~╕Ç<╗^¿ßD0┤T.OQΣq#≈
0050this is a test this is a test this is a test this is a test
Any thoughts?
Thanks
Advertisement
Answer
// Generates Garbage memcpy(encbuf, encbuf+100, enclen);
Overlapping buffers and memcpy is undefined behavior in C/C++. Use memmove instead. It sounds like you have a version of glibc that can memcpy forwards or backwards. In your case, you are executing on a processor that passed HAS_FAST_COPY_BACKWARD.
Here’s a classic bug report for the issue: Strange sound on mp3 flash website. But nothing from Adobe should surprise you. There’s a reason they are known for the most insecure software on the planet.
Also, If you run your binary under Valgrind, the tool sometimes flags code with the issue. I recall seeing Valgrind flag it for the Crypto++ library:
size_t ArraySink::Put2(const byte *begin, size_t length, int messageEnd, bool blocking)
{
// Avoid passing NULL pointer to memcpy. Using memmove due to
// Valgrind finding on overlapping buffers.
size_t copied = 0;
if (m_buf && begin)
{
copied = STDMIN(length, SaturatingSubtract(m_size, m_total));
memmove(m_buf+m_total, begin, copied);
}
m_total += copied;
return length - copied;
}