gdcm-security-poc

حزمة إعادة إنتاج خاصة لمعقم شامل من الطرف إلى الطرف لستة اكتشافات في GDCM

master لقطة مؤرّخة، وليس فرعًا متحرّكًا. كلتا المراجعتين متاحتان من المستودع العام، لذا يمكن لـ bootstrap.sh تجهيز أيٍّ منهما دون أي مصدر خاص.

نطاق النتائج

الأدلة التشغيلية في هذا المستودع تخصّ v3.2.6. النطاقات الأوسع أدناه مستمدّة من فحص تاريخ المصدر؛ كما تبقى الأنماط المتورّطة في لقطة master المثبّتة.

المحتويات

• fixtures/ - مدخلات DICOM الخاملة، مثبّتة بـ SHA-256 في manifest/expectations.json ويُتحقّق منها قبل كل تشغيل مُشغّل
• generators/ - مولّدات مصدرية حتمية بلا اعتماديات لكل fixture
• harnesses/ - حاضنات قراءة/ترميز/فك ترميز دنيا؛ النتيجة 2 معروضة عبر كلٍّ من واجهة gdcmconv الطرفية وواجهة تحويل الترميز المكتبية التي يستدعيها الخادم
• manifest/expectations.json - أوامر قابلة للقراءة آليًا، وإشارات حاسمة، ومعايير قبول للهدف fixed
• scripts/ - تجهيز المصدر المثبّت، وبناء sanitizer، والتنفيذ المحدود، والتنظيف
• evidence/ - نتائج موجزة لوحظت بالفعل، مع ذكر الأهداف غير المختبَرة صراحةً
• LICENSE - رخصة MIT

المتطلّبات المسبقة

بيئة بناء Linux أو macOS قابلة للتخلّص منها مع Git وPython 3 وCMake 3.20+ وNinja وسلسلة أدوات C++11 (Clang أو GCC). على Ubuntu: git python3 cmake ninja-build clang zlib1g-dev. اضبط CC/CXX لاستخدام GCC بدلًا من ذلك.

تجهيز المصدر يستنسخ عبر HTTPS ما لم يُشِر GDCM_SOURCE_REPO إلى نسخة محلية موجودة. لا يُستخدم أي مضيف SSH.

التجهيز والبناء

هذه الأوامر تجهّز المصدر ومخرجات البناء فقط؛ ولا تفتح أي fixture.

الوسيط الثالث هو الملف التعريفي (profile). debug هو -O0 -g؛ وrelease هو -O2 -g -DNDEBUG، الذي يُلغي gdcm_debug_assert() في GDCM ويطابق كيفية بناء التوزيعات للمكتبة. تشغيل المصفوفة تحت كليهما يجيب على السؤال الأول الذي يطرحه المشرف، وهو ما إذا كانت التقارير ناتجة عن بناء مُفعّل فيه التحقّقات.

GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON هو الإعداد الافتراضي لـ GDCM نفسه ويُترك كما هو. تجاوز التوازي المتحفّظ بـ JOBS=8.

كل بناء يكتب build-info.json (المراجعة، المترجم، الأعلام، المنصّة) في شجرة بناء GDCM الخاصة به، وكل ملخّص تشغيل يُضمّنه، لذا تكون الأدلة المؤرشفة واصفة لنفسها.

التشغيل

يشغّل run-matrix.sh كل حالة آلية لكل هدف، ولا يتوقّف عند أول فشل، ويكتب _runs/matrix-<stamp>.json بالإضافة إلى _runs/matrix-<stamp>.md المُصاغ. تبقى حالة f1-exploit ذات المرحلتين يدوية وتُبلَّغ على هذا النحو بدلًا من تصنيفها خطأً كحالة آلية فاشلة.

كل عملية فرعية لديها core dumps معطّلة ومهلة 15 ثانية؛ كما تحصل النتيجة 5 إضافةً على حدّ مكدّس محدود. تبقى المخرجات تحت _runs/. يطابق المصنّف فئة sanitizer والدالة المتورّطة، وليس العناوين أو PIDs أو أرقام أسطر المصدر.

بالنسبة لـ vulnerable، تنجح الحالة عندما تظهر الإشارة الحاسمة ويبقى ضابطها نظيفًا. بالنسبة لـ master، يسجّل المشغّل ملاحظة بدلًا من حكم مُعلن مسبقًا. بالنسبة لـ fixed، تنجح الحالة فقط عندما تغيب الإشارة، ولا يظهر أي sanitizer آخر أو إشارة قاتلة، وتُعيد الحاضنة نتيجة نظيفة مسموحة. هذه القواعد مؤقتة حتى يُسمّي FIXED_REV تصحيحًا فعليًا؛ ويجب مراجعتها مقابل سلوك الرفض-أو-المعالجة المقصود لذلك التصحيح.

الحالات

هناك حاضنتان إضافيتان تُعدّان بحثًا في قابلية الاستغلال بدلًا من حالات إعادة إنتاج، وتبنيان فقط في الملف التعريفي غير المُعالَج بـ sanitizer على Linux x86-64:

الأدلة المحتفظ بها

يسجّل evidence/v3.2.6-macos-arm64-debug.md مصفوفة debug المكتملة لـ v3.2.6، بما في ذلك كل ضابط وفحصَي انتشار النتيجة 3 المحدودين.

يسجّل evidence/v3.2.6-linux-x86_64-finding01-groom.md و evidence/v3.2.6-linux-x86_64-finding03-leak.md نتيجتَي قابلية الاستغلال أدناه. لا يُدّعى الحصول على نتائج master الحالي، ولا مصفوفة الملف التعريفي الكامل للإصدار، ولا نتائج f1-exploit حتى يُحتفظ بنصوصها.

التنظيف

يرفض التنظيف العمل دون علامة الحزمة ويزيل فقط _work و_build و_generated و_runs وذاكرات bytecode الخاصة بـ Python تحت هذا المستودع. لا تُزال الأدلة المحتفظ بها تحت evidence/.

العنصر الأولي للاستغلال (النتيجة 1)

f1-exploit خاص بـ Linux-x86_64 فقط ويُشغَّل يدويًا؛ ويحمل manifest/expectations.json تسلسل الأوامر الدقيق. تحت تخطيط التخصيص الحتمي للحاضنة، يختبر ثلاث حقائق منفصلة، لكلٍّ منها حالة سلبية مقابلة:

• الفيض يصل إلى ذاكرة منحها المخصّص بعد المخزن الهدف؛
• البايتات التي تحلّ هناك هي بالضبط البايتات التي طلبها ملف DICOM المُصمَّم. زرع قيمة مختلفة، أو استخدام fixture f1 العادي، يُبلّغ عن تلف لكن صراحةً ليس تحكّمًا في المحتوى، لذا يكون الفحص قابلًا للتكذيب؛
• مؤشّر دالة الضحية الاصطناعية ينتهي به الأمر حاملًا عنوانًا يوفّره الملف، واستدعاؤه ينقل التحكّم إلى دالة داخل الحاضنة.

حوالي نصف نوافذ الـ 8 بايت ضمن الفيض البالغ 12288 بايت تقبل قيمة عشوائية. الباقي مقترن، لأن DoYBRFull422 يكرّر بايت مصدر واحد في موضعَي إخراج؛ والإزاحة 6144 هي إحدى النوافذ الحرّة. فك ترميز الإطار 1 يجري أخيرًا، لذا فإن محتوى الإطار 1 هو الذي يستمر بعد التخصيص.

تسجّل الحاضنة ما إذا كان ImageReader::Read() يُعيد true بينما الكائن المجاور مُعدَّل. يجب الاحتفاظ بنص Linux x86-64 ناجح قبل وصف تلك النتيجة كدليل ملاحَظ.

ما يحدث دون التجهيز

يوفّر f1-exploit تخطيط ضحيته الخاص، لذا لا يمكنه الإجابة عمّا إذا كانت عملية غير معدّلة تمتلك ذلك التخطيط. يستخدم finding01_groom glibc القياسي، وPIE الافتراضي، وASLR، مع خطافات تخصيص عامة تسجّل التخصيصات لكن لا تنقلها. في الاختبارات المحتفظ بها:

• كان التخصيص التالي للمخزن البالغ 24576 بايت قطعة GDCM مؤقتة محرّرة بحجم 2049 بايت في جميع التجارب العشرين المسجّلة. لم يُلاحَظ أي كائن حيّ أو vtable؛
• إتلاف بيانات القائمة الحرّة لتلك القطعة يُفعّل فحص الاتساق الخاص بـ glibc، الذي يُجهض. تموت حاضنة finding01 العادية بالطريقة نفسها دون أي تجهيز على الإطلاق.

على بناء glibc المُختبر، تسبّبت النتيجة 1 بشكل موثوق في حجب الخدمة؛ ولم يُعثر على مسار لتنفيذ الكود. كانت الهندسة المُختبرة ثابتة، وقد تُخطّط مخصّصات أو منصّات أخرى الكومة بشكل مختلف.

finding03_leak هي النتيجة الأقوى. في البناء المُختبر، تصل القراءة خارج الحدود إلى 131070 بايت، ويدخل مؤشّر vtable من gdcm::ByteValue إلى البكسلات المفكوكة، وتستنتج الحاضنة قاعدة تحميل المكتبة باستخدام إزاحة vtable المعروفة لذلك البناء. هذه نتيجة كشف على مستوى API محلي: تتطلّب تطبيق LUT والوصول إلى مخزن البكسلات المفكوك. ولا تُظهر أن خدمة شبكية تُعيد تلك البكسلات.

لا يمكن ربط الاثنتين لتنفيذ كود هنا، وليس فقط لعدم العثور على ضحية: فهما يحتاجان قيمتَي PhotometricInterpretation مختلفتين، لذا يحتاجان ملفّين، والقاعدة المُسرَّبة مفيدة فقط ما دامت العملية المُسرِّبة حيّة.

حدود الأدلة

يُثبت تقرير sanitizer حدث أمان الذاكرة أو السلوك غير المعرّف المذكور في العملية والمراجعة المُختبرتين. يختبر f1-exploit التحكّم في البايتات وكتابة فوق مؤشّر دالة مجاور تحت مخصّص مُجهّز يوفّر التخطيط الهدف عمدًا. ولا يُثبت ذلك التخطيط في مستهلك غير معدّل. لم تلاحظ تجارب finding01_groom المحتفظ بها ذلك التخطيط للهندسة وبناء glibc المُختبرين.

لا شيء من هذا يُثبت قابلية الوصول عن بُعد في أي منتج بعينه، أو الاستمرارية، أو القابلية للتطبيق في المصبّ. حجّة قابلية الوصول لنشر معيّن ادّعاء منفصل، يُقدَّم في نصّ الإفصاح وليس بواسطة هذه الحزمة.