نشر الباحث الأمني Yuhang Wu في العمق أولاً ثغرة فعالة لإثبات المفهوم (PoC) تنفذ الأوامر كما هي git على GitLab غير المُدار ذاتيًا 18.11.3 الخادم.
يقوم مستخدم عادي مصادق بتشغيله من خلال إنشاء دفتري ملاحظات Jupyter وطلب الفرق بينهما. لا تحتاج السلسلة إلى حقوق المسؤول، أو الوصول إلى مشغل التكامل المستمر (CI)، أو تفاعل الضحية، أو الوصول إلى مشروع مستخدم آخر.
الاستغلال العام خاص ببناء GitLab 18.11.3 على x86-64؛ تؤثر أخطاء Oj الأساسية على الإصدارات الأوسع. النطاقات المتأثرة هي GitLab Community Edition (CE) وEnterprise Edition (EE) 15.2.0 خلال 18.10.7, 18.11.0 خلال 18.11.4، و 19.0.0 خلال 19.0.1.
الإصدارات الثابتة الأولى هي 18.10.8, 18.11.5، و 19.0.2. Oj هو محلل JSON عالي الأداء لـ Ruby مع رمز C أصلي كبير.
الجواهر المنشورة 3.13.0 خلال 3.17.1 معرضون للخطر؛ 3.17.3 هو أول إصدار منشور يحتوي على كلا الإصلاحين. تؤثر العيوب على Free وPremium وUltimate. روبي نفسها لا تتأثر.
الاستغلال الناجح يعمل كما git. ويعتمد وصوله الفعال على عزل النشر، ولكنه قد يشمل كود المصدر، وأسرار Rails، وبيانات اعتماد الخدمة، وبيانات CI/CD، والخدمات الداخلية التي يمكن الوصول إليها من التطبيق. تم تصحيح GitLab.com بحلول 10 يونيو.
العملاء المتفانون لا يحتاجون إلى أي إجراء. يجب أن ينتقل المشغلون المُدارون ذاتيًا إلى إصدار مدعوم يحتوي على الإصلاح. يحتاج مستخدمو Helm وOperator إلى التحقق من إصدار GitLab داخل صورة خدمة الويب، وليس فقط المخطط أو إصدار المشغل. قالت شركة Deepfirst إنها لم تكن على علم بالاستغلال في البرية اعتبارًا من 24 يوليو.
لم يقم الكشف عن العمق الأول ولا ملاحظات إصدار GitLab في 10 يونيو بإدراج معرفات CVE أو نتائج CVSS للخللين المتسلسلين. ولا يوفر أي منهما حلاً مؤقتًا؛ يقوم كلاهما بتوجيه المشغلين المُدارين ذاتيًا للترقية.
سألت Hacker News GitLab عن حالة مكافحة التطرف العنيف وتصنيفها وأدلة الاستغلال. كما تساءلت أيضًا عن العمق أولاً حول قابلية نقل الاستغلال وما إذا كان هناك تخفيف مؤقت مدعوم. الردود في انتظار. يسرد Deepfirst تسعة CVEs لعيوب Oj الأخرى الموجودة في نفس المراجعة.
يمر عارض دفتر الملاحظات الخاص بـ GitLab بالتحكم في المستودع .ipynb جيسون ل Oj::Parser.usual.parse داخل عامل بوما طويل العمر. يؤدي ذلك إلى إرسال بيانات دفتر الملاحظات التي يتحكم فيها المهاجم إلى حالة المحلل اللغوي الأصلي لـ Oj داخل عملية تطبيق GitLab.
يُظهر التحليل الفني لـdeepfirst كيف يتحكم أحد الأخطاء في مؤشر رد الاتصال، بينما يقوم الخطأ الآخر بتسريب عنوان الكومة اللازم لتضييق نطاق البحث العشوائي لتخطيط مساحة العنوان (ASLR).
يقوم Oj بتخزين حالة التداخل في مكدس ثابت يبلغ 1024 بايت ولكنه لا يتحقق أبدًا مما إذا كان العمق يتجاوز ذلك أم لا. وبالتالي يمكن للمصفوفات المتداخلة بعمق الكتابة 0x01 بايت في حالة المحلل اللغوي المجاورة. استغلال يفسد buf.head، مما يتسبب في قيام Oj بتمرير مؤشر داخلي مزور إلى realloc(). يستعيد تخصيص Ruby Array اللاحق نفس منطقة jemalloc ذات 3584 بايت ويستبدلها p->start.
يخصص Oj مفتاح كائن بحجم 65.565 بايت، ويقتطع طوله إلى 29 في حقل 16 بت موقّع، ويعيد 29 بايت تحتوي على مؤشر تخصيص المفتاح المباشر. يحمل GitLab هذا المؤشر في دفتر الملاحظات المعروض، مما يمنح الاستغلال تسرب العنوان اللازم لتضييق نطاق بحث ASLR. على GitLab لمحة عن اثنين من العاملين 18.11.3 التثبيت، وعادة ما يستغرق البحث خمس إلى عشر دقائق. وتوقع الباحثون ساعة إلى ساعتين عبر أوسع مجموعة من العمال الناضجين.
ملفان دفتريان مرتبان بشكل معجمي في ملف واحد diffs_stream يطلب الاحتفاظ بالمرحلتين داخل عامل Puma نفسه، والذي يعيد استخدام محلل Oj العالمي للعملية. يفسد الملف الأول رد الاتصال ويثير خطأ اكتشفه GitLab قبل مواصلة الاختلاف. يستدعي التحليل التالي المؤشر المكتوب ويصل system() من خلال تسلسل أداة خاص بالبناء.
يقوم العرض التوضيحي العام بتجميع السلسلة في GitLab محلي 18.11.3 x86-64 lab ويجعل عامل Puma يتصل مرة أخرى كـ git.
أبلغ Deepfirst عن أخطاء Oj في 21 مايو، وقام المشرف بدمج الإصلاحات في 27 مايو. 3.17.3 تم شحنها في 4 يونيو. أبلغ الباحثون عن سلسلة GitLab في 5 يونيو؛ وقال Deepfirst إن GitLab أكد ذلك في 8 يونيو.
أصدر GitLab الإصدارات الثابتة في 10 يونيو وحل التقرير في 17 يوليو، وفقًا لما ذكره موقع Deepfirst. وجدت مراجعة أجرتها The Hacker News أن GitLab أدرج ملف Oj 3.17.3 عثرة تحت إصلاحات الأخطاء وليس في جدول إصلاح الأمان ولم تصف سلسلة RCE الخاصة بالكمبيوتر الدفتري.
