تم التعرف على ثغرة أمنية (CVE-2023-38545) في الأداة المساعدة لتلقي وإرسال البيانات عبر شبكة curl ومكتبة libcurl، والتي يتم تطويرها بالتوازي، والتي يمكن أن تؤدي إلى تجاوز سعة المخزن المؤقت واحتمال تنفيذ تعليمات برمجية للمهاجم على جانب العميل عند الوصول إليه باستخدام الأداة المساعدة curl أو تطبيق يستخدم libcurl، إلى خادم HTTPS يتحكم فيه المهاجم. تظهر المشكلة فقط إذا تم تمكين الوصول عبر وكيل SOCKS5 في حليقة. عند الدخول مباشرة بدون وكيل، لا تظهر الثغرة الأمنية. تم إصلاح الثغرة الأمنية في الإصدار 8.4.0 من حليقة. حصل الباحث الأمني الذي اكتشف الثغرة على مكافأة قدرها 4660 دولارًا كجزء من مبادرة Hackerone's Internet Bug Bounty.
سبب الثغرة الأمنية هو خطأ في رمز تحليل اسم المضيف قبل الوصول إلى وكيل SOCKS5. إذا كان اسم المضيف يصل إلى 256 حرفًا، يقوم curly بتمرير الاسم على الفور إلى وكيل SOCKS5 للحل من جانبه، وإذا كان الاسم أكثر من 255 حرفًا، فإنه يتحول إلى المحلل المحلي ويمرر العنوان المحدد بالفعل إلى SOCKS5 . بسبب خطأ في الكود، يمكن ضبط العلامة التي تشير إلى الحاجة إلى الحل المحلي على قيمة خاطئة أثناء التفاوض البطيء للاتصال عبر SOCKS5، مما أدى إلى تسجيل اسم مضيف طويل في المخزن المؤقت المخصص مع التوقع تخزين عنوان IP أو الاسم بما لا يتجاوز 255 حرفًا.
يمكن لمالك الموقع الذي يتم الوصول إليه عن طريق الضفيرة من خلال وكيل SOCKS5 تشغيل تجاوز سعة المخزن المؤقت من جانب العميل عن طريق إرجاع رمز إعادة توجيه الطلب (HTTP 30x) وتعيين رأس "الموقع:" إلى عنوان URL باسم مضيف في نطاق 16 فما فوق. إلى 64 كيلو بايت (16 كيلو بايت هو الحد الأدنى للحجم المطلوب لتجاوز سعة المخزن المؤقت المخصص، و65 كيلو بايت هو الحد الأقصى لطول اسم المضيف المسموح به في عنوان URL). إذا تم تمكين إعادة توجيه الطلب في إعدادات libcurl وكان وكيل SOCKS5 المستخدم بطيئًا بدرجة كافية، فسيتم كتابة اسم المضيف الطويل في مخزن مؤقت صغير، ومن الواضح أنه أصغر حجمًا.
تؤثر الثغرة الأمنية بشكل أساسي على التطبيقات المستندة إلى libcurl وتظهر في الأداة المساعدة curl فقط عند استخدام خيار "--limit-rate" بقيمة أقل من 65541 - يخصص libcurl بشكل افتراضي مخزنًا مؤقتًا بحجم 16 كيلو بايت، وفي الأداة المساعدة curl يبلغ حجمه 100 كيلو بايت، ولكن يتغير الحجم اعتمادًا على قيمة المعلمة "-limit-rate".
وذكر دانييل ستينبرج، مؤلف المشروع، أن الثغرة الأمنية ظلت غير مكتشفة لمدة 1315 يومًا. وتقول أيضًا أنه كان من الممكن تجنب 41% من الثغرات التي تم تحديدها مسبقًا في لغة Curl إذا تمت كتابة لغة Curl بلغة آمنة للذاكرة، ولكن لا توجد خطط لإعادة كتابة لغة Curl إلى لغة أخرى في المستقبل المنظور. كإجراءات لتحسين أمان قاعدة التعليمات البرمجية، يُقترح توسيع أدوات اختبار التعليمات البرمجية واستخدام التبعيات المكتوبة بلغات البرمجة التي تضمن التشغيل الآمن للذاكرة بشكل أكثر نشاطًا. كما أنها تدرس إمكانية استبدال أجزاء من الضفيرة تدريجيًا بخيارات مكتوبة بلغات آمنة، مثل الواجهة الخلفية التجريبية Hyper HTTP المطبقة في Rust.
المصدر: opennet.ru