في 24 يوليو، نشر باحثو الأمن كود استغلال لثغرة في GitLab، مما يسمح للمستخدمين المصرح لهم بتنفيذ أوامر كحساب git. في هذا المقال، نستعرض تفاصيل هذه الثغرة والإجراءات الموصى بها.
باحث ينشر إثبات مفهوم (PoC) لثغرة تنفيذ أوامر عن بُعد في GitLab
نشر باحثو الأمن في depthfirst كود استغلال يعمل في 24 يوليو لثغرة في GitLab التي تم تصحيحها قبل ستة أسابيع، في 10 يونيو. يعمل هذا الكود على تنفيذ الأوامر كحساب git على أي خادم مُدار ذاتيًا بإصدار 18.11.3 لم يأخذ التحديث.
يمكن لأي مستخدم مصرح له يمكنه الدفع لمشروع تشغيله. يقوم المهاجم بارتكاب دفتر ملاحظات Jupyter مُعد مسبقًا ويفتح الفرق بين التزاماته، مما يكشف عن مؤشر كومة. بما يكفي من تلك المؤشرات، يمكن لمسبار آلي تحديد المكتبات في الذاكرة. ثم يتم إطلاق حمولة من دفترين آخرين. لا حاجة لحقوق المسؤول، ولا وصول إلى CI أو runner، ولا تفاعل مع الضحية، ولا وصول إلى مشروع أي شخص آخر.
لم تقم GitLab بتصنيف الإصلاح كإصلاح أمني. وجدت مراجعة من The Hacker News أن التحديث إلى Oj 3.17.3 تم إدراجه تحت إصلاحات الأخطاء في إصدار التصحيح في 10 يونيو، وليس في جدول إصلاحات الأمان. لا يوجد CVE، ولا درجة CVSS، ولا ذكر لسلسلة الفرق بين دفاتر الملاحظات. لم يكن لدى المشغلين الذين قاموا بتقييم ذلك الإصدار ضد جدول الأمان سبب للتعامل معه كأمر عاجل.
ثغرات فساد الذاكرة
تعمل ثغرتان في Oj، وهو محلل JSON مكتوب بلغة Ruby يتم تنفيذه بشكل كبير في C الأصلي، على جعل السلسلة تعمل. تقول depthfirst إن نظامها قد علمهما بشكل ذاتي، وقام الباحثون بسلسلة تلك الثغرات يدويًا.
يمرر مُعالج دفاتر الملاحظات في GitLab، وهو جوهرة داخلية تُدعى ipynbdiff، .ipynb JSON التي يتحكم فيها المستودع إلى Oj::Parser.usual.parse داخل عامل Puma طويل الأمد، مما يسمح لوحدات التحكم التي يتحكم بها المهاجم بالوصول إلى الذاكرة المُدارة يدويًا في عملية التطبيق.
تكتب إحدى الثغرات بعد كومة ثابتة من 1,024 بايت حتى تتحكم في رد الاتصال الخاص بالمحلل. بينما تقوم الأخرى بتقليص مفتاح كائن بحجم 65,565 بايت إلى 29 في حقل 16 بت مُوقع وتعيد مؤشر كومة حي، والذي تقوم GitLab بعرضه في الفرق. يكشف التسرب عن libc، ويشير الكتابة إلى رد الاتصال في system().
التأثير والتحديثات
جميع الفئات متأثرة، CE و EE، من المجانية إلى النهائية. بينما لا تتأثر Ruby نفسها. حملت Oj 3.17.2 إصلاحات أخرى من نفس المراجعة ولكن ليس هذين الثغرتين.
يجب التحديث إلى 18.10.8، 18.11.5، أو 19.0.2. لا تقدم GitLab أو depthfirst حلاً لمن لا يمكنهم التحديث. أخبر الباحث Yuhang Wu من depthfirst The Hacker News أنه ليس على علم بخيار موثق من GitLab يعطل تمامًا مسار الفرق المعرض للخطر، وأن depthfirst لم تتحقق من حل يعتمد فقط على التكوين يمكن أن توصي به. قال إن إبقاء المستخدمين غير الموثوقين بعيدًا عن عرض الفرق في دفاتر الملاحظات من شأنه أن يزيل هذه النقطة الضعيفة من حيث المبدأ، ولكن يجب على المشغلين الذين لا يمكنهم التحديث طلب إرشادات من GitLab تتعلق بنشرهم المحدد.
نقاط الضعف والاعتبارات الأمنية
الفخ هو Helm وOperator: تحقق من إصدار GitLab داخل صورة Webservice التي تعمل على Puma، وليس إصدار المخطط أو الإصدار. أي شيء على 15.2 إلى 18.9 لا يحصل على تحديثات، لأن هذه الخطوط تقع خارج مسارات التصحيح المدارة أمنيًا من GitLab، لذا يجب على تلك التثبيتات الانتقال إلى إصدار مدعوم بدلاً من ذلك.
تعمل الأوامر كحساب git، الحساب وراء Puma. يعتمد مدى ذلك على كيفية عزل التثبيت. في متناول اليد: كود المصدر، أسرار Rails، بيانات اعتماد الخدمة، بيانات CI/CD، والخدمات الداخلية التي يمكن للتطبيق التحدث إليها.
تم بناء الاستغلال العام لـ GitLab 18.11.3 على x86-64. جاءت إزاحات الأدوات، وحالة السجل، وسلوك jemalloc جميعها من تلك الصورة، ويحتفظ مكتبة مستعادة فقط حتى يتم إعادة تشغيل خادم Puma الرئيسي، لذا فإن هذا ليس قابلاً للاستخدام ضد هدف عشوائي.
الثغرات في Oj عامة، والسلسلة تسافر أبعد مما تشير إليه تلك الصورة الواحدة. قال Wu إن مسار الاستغلال ليس محددًا لـ 18.11.3، وأن إعادة استهداف إصدار GitLab آخر على نفس البنية ستحتاج عمومًا فقط إلى تعديلات طفيفة، معظمها تحديثات لإزاحات الأدوات أو الرموز. غالبًا ما لا تتغير تلك الإزاحات على الإطلاق عبر الإصدارات القريبة، لأن الأدوات تأتي من Ruby والمكتبات النظامية بدلاً من كود GitLab الخاص. البنية هي العقبة الحقيقية. الانتقال إلى ARM64 يعني أن هناك تقاليد استدعاء مختلفة، وأدوات، واستخدام سجلات، وربما سلوك كومة مختلف، وتؤثر بناء Ruby، libc، والمخصصات، وبيئة التجميع أكثر من إصدار GitLab. قيست depthfirst خمس إلى عشر دقائق للبحث في الذاكرة على تثبيت جديد ذي عاملين وتوقعت ساعة إلى ساعتين على التثبيتات الأطول. تحتوي كتابتها على السلسلة الكاملة.
أبلغت depthfirst عن ثغرات Oj في 21 مايو، وتم دمج الإصلاحات من قبل المسؤول في 27 مايو، وتم إصدار Oj 3.17.3 في 4 يونيو. تم إرسال سلسلة GitLab إلى GitLab في 5 يونيو، وتم تأكيدها في 8 يونيو، وتم تصحيحها في 10 يونيو. قال Wu إن depthfirst لم تطلب معرفات CVE لأي من المشكلتين. مرت سلسلة GitLab عبر برنامج HackerOne الخاص بـ GitLab، الذي لم يعين depthfirst معرفًا منفصلًا لها، وذهبت ثغرتا Oj مباشرة إلى المسؤول دون طلب CVE ولم يتم تعيين أي منها حسب علم depthfirst. غيابها، كما قال، يعكس كيفية تنسيق الإفصاحات بدلاً من أي شيء يتعلق بالخطورة.
تقول depthfirst إنها ليست على علم باستغلالات في البرية، وأن GitLab أعادت إنتاج RCE بشكل مستقل. قال Wu إن ذلك يعتمد على غياب التقارير وعلى عدم رؤية depthfirst لأي شيء خارج بيئة بحثها الخاصة، وليس على القياسات. لا تملك الشركة وصولاً إلى بيانات GitLab الداخلية أو بيئات العملاء، كما قال، وGitLab هو المصدر الصحيح لأي استنتاج يتم استخلاصه من تلك البيانات. أنتجت مراجعة Oj الأوسع تسعة إعلانات CVE أخرى، ولم يكن أي منها يتعلق بهذه السلسلة.
لم تستجب GitLab لأسئلة من The Hacker News حول سبب عدم تصنيف الإصلاح كمسألة أمنية وما إذا كان سيتم تعيين CVE. سيتم تحديث هذه القصة إذا حدث ذلك.
تم تصحيحه في 26 يوليو 2026: قالت نسخة سابقة إن نقل الاستغلال هو عمل حقيقي. تقول depthfirst إن إعادة استهداف إصدار GitLab آخر على نفس البنية تتطلب عمومًا فقط تحديثات طفيفة للإزاحات؛ العمل الكبير هو الانتقال إلى بنية مختلفة.
تأكد من تحديث نظام GitLab الخاص بك لحماية بياناتك. لمزيد من المعلومات حول الأمان، تابعنا على منصاتنا.
