إثبات المفهوم لـ CVE-2025-40019

CVE-2025-40019 هي آلية متجه التهيئة للملح-قطاع المشفر (crypto/essiv.c) والتي تحتوي على تحقق غير كافٍ من طول بيانات المصادقة المرتبطة (AAD) بالنسبة لحجم متجه التهيئة (IV)، مما يؤدي إلى وصول للذاكرة خارج الحدود. الكود المقدم في هذا المستودع هو مجرد مشغل للخلل ولكن هذا الخلل قابل للاستغلال بسهولة.

مشاركة KernelCTF

صادفت هذا الخلل في جدول بيانات kernelctf هنا. نظرًا لعدم وجود منشور مدونة أو إثبات مفهوم مرتبط بهذا الخلل، قررت استكشاف النظام الفرعي للتشفير في نواة لينكس لاستكشاف سبب المشكلة.

الخلفية: نظرية تشفير القرص و ESSIV

لفهم ضرورة ESSIV، يجب أن ننظر إلى كيفية تخزين البيانات على القرص. يعمل تشفير القرص (مثل LUKS أو dm-crypt) عادةً على القطاعات. يجب تشفير كل قطاع بشكل مستقل بحيث لا تتطلب قراءة قطاع واحد قراءة القرص بأكمله.

هجوم العلامة المائية

في وضع CBC القياسي (تسلسل كتل التشفير)، يلزم وجود متجه تهيئة (IV) لكل عملية تشفير. استخدمت تطبيقات تشفير القرص المبكرة رقم القطاع كمتجه تهيئة. ومع ذلك، نظرًا لأن أرقام القطاعات قابلة للتنبؤ، يمكن للمهاجم تنفيذ "هجوم العلامة المائية". من خلال كتابة بيانات مصممة خصيصًا إلى قطاع معروف، يمكن للمهاجم ملاحظة أنماط في النص المشفر تكشف عن وجود ملفات محددة، متجاوزًا بذلك سرية التشفير.

حل ESSIV

تم تصميم ESSIV (متجه التهيئة للملح-قطاع المشفر) لجعل متجه التهيئة غير قابل للتنبؤ. يعمل عن طريق:

1. تجزئة مفتاح التشفير السري ($K$) لاشتقاق "ملح" ($S = H(K)$).
2. تشفير رقم القطاع ($SN$) باستخدام تشفير منفصل مع الملح كمفتاح ($IV = E_S(SN)$).
3. يتم بعد ذلك استخدام $IV$ الناتج لتشفير البيانات الفعلية لذلك القطاع.

يضمن هذا أنه حتى إذا عرف المهاجم رقم القطاع، فلا يمكنه التنبؤ بـ IV دون معرفة المفتاح السري.

---

كل خوارزمية، سواء كانت تشفيرًا أساسيًا مثل AES أو غلافًا مثل ESSIV، تنفذ بنية تستخدمها النواة لتوجيه الاستدعاءات:

struct skcipher_alg {
    int (*setkey)(struct crypto_skcipher *tfm, const u8 *key, unsigned int keylen);
    int (*encrypt)(struct skcipher_request *req);
    int (*decrypt)(struct skcipher_request *req);
    // ...
    struct skcipher_alg_common co; // Contains ivsize, chunksize, etc.
};

السبب الجذري

الثغرة هي حالة كلاسيكية من افتراض أن البيانات الوصفية المقدمة من المستخدم (طول AAD) ستلبي دائمًا المتطلبات الداخلية للتحول التشفيري. في مسار "في المكان" أو فك التشفير (!enc)، يحسب الكود إزاحة: req->assoclen - crypto_aead_ivsize(tfm). لكنه لا يتحقق أبدًا مما إذا كان req->assoclen < ivsize. مما يعني أن هذه الإزاحة يمكن أن تكون سالبة.

static int essiv_aead_crypt(struct aead_request *req, bool enc)
{
	struct crypto_aead *tfm = crypto_aead_reqtfm(req);
	const struct essiv_tfm_ctx *tctx = crypto_aead_ctx(tfm);
	struct essiv_aead_request_ctx *rctx = aead_request_ctx(req);
	struct aead_request *subreq = &rctx->aead_req;
	struct scatterlist *src = req->src;
	int err;

	crypto_cipher_encrypt_one(tctx->essiv_cipher, req->iv, req->iv);

	/*
	 * dm-crypt embeds the sector number and the IV in the AAD region, so
	 * we have to copy the converted IV into the right scatterlist before
	 * we pass it on.
	 */
	rctx->assoc = NULL;
	if (req->src == req->dst || !enc) {
		scatterwalk_map_and_copy(req->iv, req->dst,
					 req->assoclen - crypto_aead_ivsize(tfm),    // <------- bug !
					 crypto_aead_ivsize(tfm), 1);
	} else {
		u8 *iv = (u8 *)aead_request_ctx(req) + tctx->ivoffset;
		int ivsize = crypto_aead_ivsize(tfm);
		int ssize = req->assoclen - ivsize;
		struct scatterlist *sg;
		int nents;
        .
        .
        .

بالنظر إلى دالة scatterwalk_map_and_copy، يمكننا أن نرى أنها تقوم فقط بنسخ الذاكرة إلى scatterlist sg:

static inline void scatterwalk_map_and_copy(void *buf, struct scatterlist *sg,
					    unsigned int start,
					    unsigned int nbytes, int out)
{
	if (out)
		memcpy_to_sglist(sg, start, buf, nbytes);
	else
		memcpy_from_sglist(buf, sg, start, nbytes);
}

التصحيح

كان التصحيح لهذا الخلل بسيطًا جدًا، فهو يتحقق فقط مما إذا كان assoclen أقل من ivisize

diff --git a/crypto/essiv.c b/crypto/essiv.c
index d003b78fcd855a..a47a3eab693519 100644
--- a/crypto/essiv.c
+++ b/crypto/essiv.c
@@ -186,9 +186,14 @@ static int essiv_aead_crypt(struct aead_request *req, bool enc)
 	const struct essiv_tfm_ctx *tctx = crypto_aead_ctx(tfm);
 	struct essiv_aead_request_ctx *rctx = aead_request_ctx(req);
 	struct aead_request *subreq = &rctx->aead_req;
+	int ivsize = crypto_aead_ivsize(tfm);
+	int ssize = req->assoclen - ivsize;
 	struct scatterlist *src = req->src;
 	int err;
 
+	if (ssize < 0)
+		return -EINVAL;
+
 	crypto_cipher_encrypt_one(tctx->essiv_cipher, req->iv, req->iv);
 
 	/*
@@ -198,19 +203,12 @@ static int essiv_aead_crypt(struct aead_request *req, bool enc)
 	 */
 	rctx->assoc = NULL;
 	if (req->src == req->dst || !enc) {
-		scatterwalk_map_and_copy(req->iv, req->dst,
-					 req->assoclen - crypto_aead_ivsize(tfm),
-					 crypto_aead_ivsize(tfm), 1);
+		scatterwalk_map_and_copy(req->iv, req->dst, ssize, ivsize, 1);
 	} else {
 		u8 *iv = (u8 *)aead_request_ctx(req) + tctx->ivoffset;
-		int ivsize = crypto_aead_ivsize(tfm);
-		int ssize = req->assoclen - ivsize;
 		struct scatterlist *sg;
 		int nents;
 
-		if (ssize < 0)
-			return -EINVAL;
-
 		nents = sg_nents_for_len(req->src, ssize);
 		if (nents < 0)
 			return -EINVAL;

الانهيار

عندما نقدم assoclen < ivsize، يؤدي ذلك إلى هذا الانهيار. يمكن استغلال هذا الخلل عن طريق تهيئة الكائنات على الكومة ووضعها بجانب scatterlist.