OpenSSL 1.0.2: BIO_read + *_WRAP ciphers copy to uninitialized pointer
guidovranken opened this issue · comments
Tested on https://www.openssl.org/source/openssl-1.0.2r.tar.gz
The internal iv pointer is never initialized and memory is copied to this pointer.
I can construct PoC code if desired. Is is very similar to OpenSSL::OpSymmetricEncrypt_BIO except that the return value of BIO_set_cipher
is not checked.
I assume this can happen because in OpenSSL 1.0.2, BIO_set_cipher
does not return a value and therefore cannot indicate failure.
I've observed it with AES_128_WRAP
in encryption mode, but may also apply to other _WRAP ciphers and decryption mode.
This is just a heads-up. I'm aware 1.0.2 is a security-fix-only branch and that using a _WRAP cipher with BIO_f_cipher()
is sufficiently rare that it does not prompt a new release, so you may close the issue once you've seen it.
=================================================================
==5479==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000674361 bp 0xbebebebebebebebe sp 0x7ffe714caef0 T0)
==5479==The signal is caused by a READ memory access.
==5479==Hint: address points to the zero page.
#0 0x674360 in CRYPTO_128_wrap /home/jhg/cf/openssl/crypto/modes/wrap128.c:83:5
#1 0x638f6a in aes_wrap_cipher /home/jhg/cf/openssl/crypto/evp/e_aes.c:1981:14
#2 0x63c73b in evp_EncryptDecryptUpdate /home/jhg/cf/openssl/crypto/evp/evp_enc.c:327:13
#3 0x634a2c in enc_read /home/jhg/cf/openssl/crypto/evp/bio_enc.c:204:18
#4 0x6465b1 in BIO_read /home/jhg/cf/openssl/crypto/bio/bio_lib.c:210:9
So, in 1.1.0+, BIO_set_cipher
just always returns a failure if you attempt this with a WRAP cipher?
I'm going to check what happens exactly, but certainly no memory violation occurs in git master.
Yeah, compiled against git master, BIO_set_cipher returns 0.
140324479227776:error:0607B0AA:digital envelope routines:EVP_CipherInit_ex:wrap mode not allowed:crypto/evp/evp_enc.c:161:
The same check exists in 1.0.2, so, yes, this looks to be because BIO_set_cipher is declared void in 1.0.2. If 1.0.2 was in bug fix mode I think I would probably recommend handling this with a documentation change. Since 1.0.2 is security-fix only, and that wouldn't be a security fix, I think probably we just close this.