CVE-2026-39113: تجاوز سعة المخزن المؤقت في الكومة في امتداد SQLAR الاختياري لـ SQLite

الملخص التنفيذي

CVE-2026-39113 هو تجاوز سعة المخزن المؤقت في الكومة في امتداد SQLAR الاختياري لـ SQLite. في تطبيق حمّل هذا الامتداد، يمكن لمهاجم يستطيع استدعاء sqlar_uncompress() مع blob مضغوط وحجم مُتحكم بهما أن يتسبب في قيام zlib بالكتابة خارج تخصيص الكومة على نظام LP64. هذا فشل في حدود أمان الذاكرة داخل العملية المضيفة؛ وهو ليس مشكلة تحليل ملف قاعدة بيانات SQLite، ولا تجاوزًا للمصادقة، ولا خللًا يمكن الوصول إليه في كل توزيع افتراضي لـ SQLite.

تم إدخال السلوك القابل للاستغلال في 2026-03-11 عبر الالتزام Git 169f68e (Fossil check-in 8bdc0d485e3ad0c7...) وتم تصحيحه في 2026-04-01 عبر الالتزام Git 34e139d (Fossil check-in 6194f3b5314ef98b...). النطاق المتأثر هو لقطات المصدر والبنيات المخصصة من 169f68e حتى الأصل (parent) لـ 34e139d. لم يتم التحقق من أن أي إصدار رسمي من SQLite كان عرضة للثغرة: SQLite 3.52.0 يسبق الإدخال، وSQLite 3.53.0 يحتوي على كل من التغيير المُدخل والإصلاح. لذلك فإن SQLite 3.53.0 هو أول إصدار رسمي يحتوي على الكود المصحح، وليس إصدارًا متأثرًا.

راجعتُ النسخة الأصلية القابلة للاستغلال بدقة، وتغييري الإدخال والإصلاح، ولقطتي الإصدارين 3.52.0 و3.53.0. كما فحصتُ المخرجات المحفوظة من تشغيل مصرح به في بيئة WSL2 مؤقتة بنظام Ubuntu 24.04. لاحظ AddressSanitizer تجاوز سعة المخزن المؤقت في الكومة متبوعًا بإنهاء العملية، مما يثبت تلف الكومة المحلي وحرمان الخدمة. لم يتم إثبات تنفيذ الكود.

الخلفية

SQLAR هو تنسيق أرشيف لـ SQLite. الامتداد الاختياري في ext/misc/sqlar.c يسجّل sqlar_compress() وsqlar_uncompress() كدالتي SQL. وهو ليس جزءًا من كل تطبيق يستخدم SQLite؛ المسار القابل للاستغلال يتطلب أن يكون الامتداد موجودًا ومحمّلًا.

بالنسبة لهذا التقرير، يتحكم مالوري في وسيطتي blob وSZ الممررتين إلى:

SELECT sqlar_uncompress(?1, ?2);

بيئة الاختبار كانت تحتوي على int بحجم 32 بت وsqlite3_int64 بحجم 64 بت وuLongf في zlib بحجم 64 بت. كان ينبغي للدالة تخصيص ذاكرة على الأقل بقدر ما يُسمح لـ zlib بكتابته. بدلًا من ذلك، يحوّل المصدر القابل للاستغلال الحجم 64-بت إلى نوع المعامل 32-بت الخاص بـ sqlite3_malloc() مع الاحتفاظ بالقيمة الكاملة لدالة uncompress().

لقطة المصدر القابلة للاستغلال طبعت Configuring SQLite version 3.53.0 أثناء التهيئة. يجب عدم الخلط بين سلسلة إصدار التطوير هذه والإصدار الرسمي SQLite 3.53.0 المؤرخ في 2026-04-09، الذي يحتوي مصدره على الإصلاح.

تفاصيل الثغرة

في النسخة التي تم تقييمها، يقرأ sqlarUncompressFunc() في ext/misc/sqlar.c الحجم المُتحكم به من المهاجم كعدد صحيح 64-بت:

sqlite3_int64 sz;

sz = sqlite3_value_int64(argv[1]);

إذا كانت sz موجبة وتختلف عن طول الـ blob المُدخل، تُستخدم القيمة نفسها بطريقتين غير متوافقتين:

uLongf szf = sz;
const Bytef *pData = sqlite3_value_blob(argv[0]);
Bytef *pOut = sqlite3_malloc(sz);

if( pOut==0 ){
  sqlite3_result_error_nomem(context);
}else if( Z_OK!=uncompress(pOut, &szf, pData, nData) ){
  sqlite3_result_error(context, "error in uncompress()", -1);
}

في هذه النسخة، يصرّح SQLite عن sqlite3_malloc(int). على بناء LP64 المختبر، أصبحت قيمة الإثبات 4294967328 (0x100000020) هي 32 عند تمريرها إلى تلك الواجهة البرمجية، بينما احتفظت szf بالقيمة الكاملة 64-بت. لذلك قام SQLite بتخصيص صغير، لكن zlib أُخبر أن المخزن المؤقت للإخراج يمكن أن يتسع لأكثر من 4 جيبيبايت. ونتيجة لذلك، فإن فك ضغط blob بحجم 42 بايت يمثل 4096 بايت من البيانات تجاوز حد التخصيص.

دخل عدم التطابق إلى المشروع عندما استبدل تغيير 2026-03-11 دالة sqlite3_value_int() بـ sqlite3_value_int64() دون تغيير واجهة التخصيص. مراجعة مصدر SQLite 3.52.0 تُظهر القراءة السابقة 32-بت، لذا لم يكن عدم التطابق بين العرض الكامل والتخصيص القصير موجودًا هناك. إصلاح 2026-04-01 غيّر التخصيص إلى sqlite3_malloc64(sz). مراجعة مصدر الإصدار الرسمي 3.53.0 تؤكد هذا الاستدعاء المصحح.

تحليل قابلية الاستغلال

البدائية المُثبتة هي كتابة خارج الحدود في الكومة داخل العملية التي تستضيف SQLite. التشغيل المحفوظ يُظهر AddressSanitizer وهو يكتشف أول كتابة غير صالحة بحجم بايت واحد مباشرة بعد منطقة كومة بحجم 40 بايت خُصصت عبر sqlite3_malloc()، يتبعها إحباط. هذا يدعم مباشرة انهيار العملية وحرمان الخدمة.

يتطلب الاستغلال جميع ما يلي:

• امتداد SQLAR الاختياري مُحمَّل؛
• يمكن لمالوري استدعاء sqlar_uncompress() مع blob مُتحكم به وقيمة SZ؛
• int بحجم 32 بت بينما sqlite3_int64 وuLongf في zlib بحجم 64 بت؛ و
• نجاح التخصيص المُضيّق، مما يسمح لـ zlib ببدء فك الضغط.

إن الإثبات يتحكم في البايتات التي تم فك ضغطها، وهو أمر ذو صلة بخطورة تلف الكومة المحلي. ومع ذلك، فإن تحويل هذه البدائية إلى تنفيذ كود سيعتمد على تخطيط المُخصِّص، وحالة العملية المحيطة، والإجراءات التخفيفية، ومسار مناسب على مستوى التطبيق. لم يتم اختبار أو إثبات أي سلسلة من هذا القبيل، لذلك لا يدّعي هذا التقرير تنفيذ الكود.

التشغيل المحفوظ لم يتضمن تحكمًا سلبيًا في وقت التشغيل ضد النسخة المُصلحة. ضابطان على مستوى المصدر يضيقان نطاق التفسير: SQLite 3.52.0 يقرأ الحجم باستخدام الواجهة 32-بت، ومصدر 3.53.0 الرسمي يخصص باستخدام sqlite3_malloc64(). هذه الفحوصات تدعم الإدخال والإصلاح المُحددين، لكنها لا تُقدَّم كاختبارات منفذة ضد الهدف المُصلح. مدى انتشار تطبيقات تحمّل هذا الامتداد الاختياري غير معروف.

إثبات المفهوم

يحتوي المستودع على:

• poc/verify_sqlar_poc.c، الذي ينشئ حمولة بحجم 4096 بايت، ويضغطها، ويحمّل sqlar.so، ويربط SZ = 4294967328؛
• poc/reproduce.sh، الذي يستنسخ مراجعات مثبّتة من SQLite وzlib، ويبنيها باستخدام AddressSanitizer، ويُصرّم الامتداد والأداة البرمجية، ويشغّل المحفّز؛ و
• evidence/asan-summary.txt، ملخص بتطبيع المسارات للتشغيل المصرح به الذي تمت ملاحظته.

شغّل أداة إعادة الإنتاج فقط في بيئة Linux أو WSL قابلة للتخلص منها. فهي تتعمد إحداث تلف في الذاكرة وإحباط AddressSanitizer. يتطلب السكربت git وmake ومُصرّف لغة C وأدوات بناء قياسية ووصولًا إلى الشبكة:

chmod +x poc/reproduce.sh
./poc/reproduce.sh

تم تشغيل أداة إعادة الإنتاج مرة أخرى في 2026-08-21 على Ubuntu 24.04 تحت WSL2 وأنتجت نفس نتيجة AddressSanitizer. كان مخرجه ذا الصلة:

env: sizeof(int)=4 sizeof(sqlite3_int64)=8 sizeof(uLongf)=8
payload: plain=4096 compressed=42 evil_sz=4294967328 low32=32

ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 1
    #0 inflate_fast zlib/inffast.c:252
    #4 uncompress zlib/uncompr.c:100
    #5 sqlarUncompressFunc sqlite/ext/misc/sqlar.c:97

The write occurred immediately after a 40-byte heap region.
SUMMARY: AddressSanitizer: heap-buffer-overflow in inflate_fast
ABORTING
PoC exit status: 1

يُظهر هذا المخرج عروض الأنواع غير المتوافقة والحجم المُصمم، وكتابة zlib، والاستدعاء من sqlarUncompressFunc()، وانتهاك حدود التخصيص. يحذف سكربت إعادة الإنتاج دليل البناء المؤقت عند الخروج ما لم يتم تعيين KEEP_BUILD=1.

المعالجة

صحّح المنبع التخصيص القابل للاستغلال في الالتزام 34e139d:

-    Bytef *pOut = sqlite3_malloc(sz);
+    Bytef *pOut = sqlite3_malloc64(sz);

هذا يبقي عرض التخصيص متسقًا مع قيمة sz الموجبة 64-بت المحفوظة في uLongf szf والممررة إلى zlib. الكود المصحح موجود في الإصدار الرسمي SQLite 3.53.0. يجب على مستخدمي لقطات المصدر أو البنيات المخصصة التي تحتوي على الفاصل الزمني القابل للاستغلال التحديث إلى 34e139d أو أحدث. التطبيقات التي لا تتطلب SQLAR يجب أن تتجنب تحميل الامتداد، والتطبيقات التي تستخدمه يجب أن تمنع المتصلين غير الموثوقين من توفير وسائط عشوائية إلى sqlar_uncompress().

يجب أن يختبر اختبار انحدار مركّز دالة SQL مع blob مضغوط صالح وقيمة SZ أعلى من INT_MAX بحيث تكون 32 بتة السفلية لها صغيرة. يجب أن يتحقق أن البناء المُصلح لا يقوم بتخصيص مبتور، وأن يحتفظ بحالات فك الضغط الناجحة العادية وأخطاء الإدخال غير الصالح كضوابط.

الملخص

CVE-2026-39113 يؤثر فقط على لقطات مصدر SQLite والبنيات المخصصة من 169f68e حتى الأصل (parent) لـ 34e139d عندما يكون امتداد SQLAR الاختياري محمّلًا وتصل استدعاءات مُتحكم بها من المهاجم إلى sqlar_uncompress() على بناء LP64. تم تضييق حجم 64-بت بواسطة sqlite3_malloc(int) بينما احتفظ zlib بالقيمة الكاملة، مما أنتج تجاوز سعة المخزن المؤقت في الكومة مؤكدًا بواسطة AddressSanitizer وإحباط العملية. لم يتم التحقق من أن أي إصدار رسمي من SQLite كان عرضة للثغرة، ولم يتم إثبات تنفيذ الكود. التغيير المنبع إلى sqlite3_malloc64(sz) موجود في الإصدار الرسمي SQLite 3.53.0 ويزيل عدم تطابق عرض التخصيص.