【技術分享】SM2國密算法應用的高危漏洞——CVE-2021-3711
openssl在8月24日發布了openssl 1.1.1l的穩定版,其中修復了一個高危漏洞:CVE-2021-3711。該漏洞會影響openssl 1.1.1l 之前的所有包含SM2商密算法版本,其中也包括基于openssl改造過的版本:阿里巴巴的babassl。
漏洞產生的原因,是解密 SM2公鑰加密后的數據時,有可能分配了一個過小的內存,導致解密后的明文長度,大于該內存長度,造成內存越界,從而導致整個應用程序崩潰。而這個漏洞,對基于openssl搭建的國密網關服務、WEB服務,有一定概率導致服務崩潰,從而產生嚴重影響。目前,市面上比較通用的國密密碼套件是使用SM2_SM4_SM3(0xE013),也就是說,該密碼套件是采用SM2加解密的方式進行密鑰協商,因此,這就很有可能觸發該漏洞,導致程序崩潰。
漏洞分析
解密 SM2公鑰加密后的數據時,應用程序會調用函數EVP_PKEY_decrypt(),該函數定義如下:
int EVP_PKEY_decrypt(EVP_PKEY_CTX *ctx, unsigned char *out, size_t *outlen, const unsigned char *in, size_t inlen);
通常應用程序會調用兩次這個函數:第一次,在進入時,“out”參數傳 NULL,在函數返回時,“outlen”參數會返回”out”所需的緩沖區大小。然后應用程序分配足夠的緩沖區,并再次調用 EVP_PKEY_decrypt(),但這次”out”傳遞的是非NULL。整個流程如下圖所示:
static int pkcs7_decrypt_rinfo(unsigned char **pek, int *peklen, PKCS7_RECIP_INFO *ri, EVP_PKEY *pkey, size_t fixlen){ EVP_PKEY_CTX *pctx = NULL; unsigned char *ek = NULL; size_t eklen;
int ret = -1;
pctx = EVP_PKEY_CTX_new(pkey, NULL); if (!pctx) return -1;
if (EVP_PKEY_decrypt_init(pctx) <= 0) goto err;
if (EVP_PKEY_CTX_ctrl(pctx, -1, EVP_PKEY_OP_DECRYPT, EVP_PKEY_CTRL_PKCS7_DECRYPT, 0, ri) <= 0) { PKCS7err(PKCS7_F_PKCS7_DECRYPT_RINFO, PKCS7_R_CTRL_ERROR); goto err; }
if (EVP_PKEY_decrypt(pctx, NULL, &eklen, ri->enc_key->data, ri->enc_key->length) <= 0) goto err;
ek = OPENSSL_malloc(eklen);
if (ek == NULL) { PKCS7err(PKCS7_F_PKCS7_DECRYPT_RINFO, ERR_R_MALLOC_FAILURE); goto err; }
if (EVP_PKEY_decrypt(pctx, ek, &eklen, ri->enc_key->data, ri->enc_key->length) <= 0 || eklen == 0 || (fixlen != 0 && eklen != fixlen)) { ret = 0; PKCS7err(PKCS7_F_PKCS7_DECRYPT_RINFO, ERR_R_EVP_LIB); goto err; }
ret = 1;
OPENSSL_clear_free(*pek, *peklen); *pek = ek; *peklen = eklen;
err: EVP_PKEY_CTX_free(pctx); if (!ret) OPENSSL_free(ek);
return ret;}
我們再來看使用SM2算法時,EVP_PKEY_decrypt內部實現:通過函數指針的方式,會調用到pkey_sm2_decrypt函數,從下圖可以看到,當”out”為NULL時,會調用sm2_plaintext_size函數,其中“outlen”參數會返回”out”所需的緩沖區大小。
static int pkey_sm2_decrypt(EVP_PKEY_CTX *ctx, unsigned char *out, size_t *outlen, const unsigned char *in, size_t inlen){ EC_KEY *ec = ctx->pkey->pkey.ec; SM2_PKEY_CTX *dctx = ctx->data; const EVP_MD *md = (dctx->md == NULL) ? EVP_sm3() : dctx->md;
if (out == NULL) { if (!sm2_plaintext_size(ec, md, inlen, outlen)) return -1; else return 1; }
return sm2_decrypt(ec, md, in, inlen, out, outlen);}
問題就出在sm2_plaintext_size函數里。首先我們先需要了解一下SM2公鑰加密后的ASN.1數據結構(ASN.1抽象語法標記,是一種數據格式),下圖引用于《GB/T 35276-2017 信息安全技術 SM2密碼算法使用規范》

通常情況SM2算法中xy分量的長度是32,但是也有可能小于32,問題就來了,sm2_plaintext_size函數的作用是獲取CipherText密文的長度,計算方式簡單粗暴:
overhead = 10 + 2 * field_size + (size_t)md_size;
overhead:整個加密后的數據中,不含密文后的長度
10:ASN.1格式中,所有標記的長度
2 * field_size:xy分量的長度,field_size是SM2密鑰中的一個值(這個值是固定的32),而x/y分量的實際長度是有可能小于32的!
md_size:雜湊值的長度
*pt_size = msg_len - overhead;
pt_size:計算出的密文長度
msg_len:整個加密后的數據長度
所以計算出的pt_size有可能偏小,結合上面提到的EVP_PKEY_decrypt()調用方式,就可能分配一個偏小的緩沖區,從而造成內存越界,程序崩潰。
int sm2_plaintext_size(const EC_KEY *key, const EVP_MD *digest, size_t msg_len, size_t *pt_size){ const size_t field_size = ec_field_size(EC_KEY_get0_group(key)); const int md_size = EVP_MD_size(digest); size_t overhead;
if (md_size < 0) { SM2err(SM2_F_SM2_PLAINTEXT_SIZE, SM2_R_INVALID_DIGEST); return 0; } if (field_size == 0) { SM2err(SM2_F_SM2_PLAINTEXT_SIZE, SM2_R_INVALID_FIELD); return 0; }
overhead = 10 + 2 * field_size + (size_t)md_size; if (msg_len <= overhead) { SM2err(SM2_F_SM2_PLAINTEXT_SIZE, SM2_R_INVALID_ENCODING); return 0; }
*pt_size = msg_len - overhead; return 1;}
這個漏洞有可能被惡意攻擊者利用,攻擊者在國密SSL握手時,生成一個x/y分量長度小于32的加密數據,就可以導致服務端程序崩潰。
漏洞修復
目前openssl已經出了1.1.1l了,已修復這個高危漏洞。
https://github.com/openssl/openssl/commit/36cf45ef3ba71e44a8be06ee81cb31aa02cb0010?branch=36cf45ef3ba71e44a8be06ee81cb31aa02cb0010&diff=unified
https://github.com/openssl/openssl/commit/ad1ca777f9702f355a2f74dc5eed713476825f23?branch=ad1ca777f9702f355a2f74dc5eed713476825f23&diff=split
漏洞溯源
這個漏洞非常的隱蔽,并且發生的概率并不高,所以很難被發現,但是一旦被利用,將會造成嚴重影響。
從openssl的提交記錄中可以看到,在2018年openssl支持SM2算法時,這個漏洞就一直存在了(下圖),同樣的,基于openssl改造的babassl也存在這個漏洞。


希望大家盡快更新openssl的版本,或修改相關代碼以修復漏洞。
CVE-2021-3711漏洞鏈接:
https://www.openssl.org/news/vulnerabilities.html#CVE-2021-3711
能為國密應用的發展貢獻自己的一份力量,這個還是挺高興的!
