الإصدارات التصحيحية لنظام التحكم بالمصدر الموزع Git 2.26.2، 2.25.4، 2.24.3، 2.23.3، 2.22.4، 2.21.3، 2.20.4، 2.19.5، 2.18.4 و2.17.5، في الذي القضاء عليه ()، التذكير ، تم القضاء عليه الأسبوع الماضي. تؤثر الثغرة الأمنية الجديدة أيضًا على معالجات "credential.helper" ويتم استغلالها عند تمرير عنوان URL منسق خصيصًا يحتوي على حرف سطر جديد أو مضيف فارغ أو نظام طلب غير محدد. عند معالجة عنوان URL هذا، يرسل credential.helper معلومات حول بيانات الاعتماد التي لا تتطابق مع البروتوكول المطلوب أو المضيف الذي يتم الوصول إليه.
على عكس المشكلة السابقة، عند استغلال ثغرة أمنية جديدة، لا يستطيع المهاجم التحكم مباشرة في المضيف الذي سيتم نقل بيانات اعتماد شخص آخر منه. تعتمد بيانات الاعتماد التي يتم تسريبها على كيفية التعامل مع معلمة "المضيف" المفقودة في credential.helper. جوهر المشكلة هو أن الحقول الفارغة في عنوان URL يتم تفسيرها بواسطة العديد من معالجات credential.helper كتعليمات لتطبيق أي بيانات اعتماد على الطلب الحالي. وبالتالي، يمكن لـ credential.helper إرسال بيانات الاعتماد المخزنة لخادم آخر إلى خادم المهاجم المحدد في عنوان URL.
تحدث المشكلة عند تنفيذ عمليات مثل "git clone" و"git fetch"، ولكنها تكون أكثر خطورة عند معالجة الوحدات الفرعية - عند إجراء "تحديث git submodule"، تتم معالجة عناوين URL المحددة في ملف .gitmodules من المستودع تلقائيًا. كحل بديل لمنع المشكلة لا تستخدم credential.helper عند الوصول إلى المستودعات العامة ولا تستخدم "git clone" في وضع "--recurse-submodules" مع المستودعات غير المحددة.
معروض في إصدارات Git الجديدة يمنع استدعاء credential.helper لعناوين URL التي تحتوي على (على سبيل المثال، عند تحديد ثلاث شرطات مائلة بدلاً من اثنتين - "http:///host" أو بدون نظام بروتوكول - "http::ftp.example.com/"). تؤثر المشكلة على المتجر (مساحة تخزين بيانات الاعتماد المضمنة في Git)، وذاكرة التخزين المؤقت (ذاكرة التخزين المؤقت المضمنة لبيانات الاعتماد المدخلة)، ومعالجات osxkeychain (وحدة تخزين macOS). لا يتأثر معالج Git Credential Manager (مستودع Windows).
يمكنك تتبع إصدار تحديثات الحزمة في التوزيعات على الصفحات , , , , , , , .
المصدر: opennet.ru