إذا تم استغلالها ، يمكن أن تسمح هذه العيوب للمهاجمين بالوصول غير المصرح به إلى المعلومات الحساسة أو التسبب بشكل عام في حدوث مشكلات
مؤخرا سيسكو تالوس (قسم أبحاث وتطوير الأمن السيبراني في Cisco Systems) كشف النقاب، من خلال مشاركة مدونة، معلومات حول اكتشاف عدد من نقاط الضعف في نظام البناء Buildroot.
سيسكو تالوس وأذكر اكتشاف ست نقاط ضعف في بيلدروت الذي يسمح، أثناء اعتراض حركة المرور العابرة (MITM)، إجراء تغييرات على صور النظام التي تم إنشاؤها أو ترتيب تنفيذ التعليمات البرمجية في نظام البناء.
نقاط الضعف الخمس الأولى مفهرسة تحت تالوس-2023-1844 (CVE-2023-45841, CVE-2023-45842, CVE-2023-45838, CVE-2023-45839, CVE-2023-45840) تؤثر على الكود للتحقق من سلامة الحزم باستخدام التجزئة.
المشاكل إنها تتلخص في القدرة على استخدام HTTP لتنزيل الملفات وعدم وجود تجزئات للتحقق من الملف بالنسبة لبعض الحزم، مما يسمح باستبدال محتوى هذه الحزم، مع إتاحة الفرصة للتدخل في حركة مرور خادم البناء (على سبيل المثال، عندما يتصل المستخدم عبر شبكة لاسلكية يتحكم فيها مهاجم).
نظرًا لأن الحزم يمكن أن تتضمن ملفات تصحيح أو ملفات Makefiles، فمن خلال توفير حزمة مصدر مخترقة، يمكن للمهاجم تنفيذ أوامر عشوائية في المحول البرمجي. وكنتيجة مباشرة، يمكن للمهاجم أيضًا تغيير أي ملفات تم إنشاؤها لأهداف Buildroot والمضيفين.
على وجه الخصوص، تم تحميل حزم aufs وaufs-util عبر HTTP ولم تتم مقارنتها بالتجزئات. هناك أيضًا تجزئات مفقودة لحزم riscv64-elf-toolchain، وversal-firmware، وmxsldr، والتي تم تحميلها عبر HTTPS افتراضيًا، ولكنها عادت إلى التنزيلات غير المشفرة في حالة حدوث مشكلات. إذا لم تكن هناك ملفات ".hash"، اعتبرت أداة Buildroot أن عملية التحقق ناجحة وقامت بمعالجة الحزم التي تم تنزيلها، بما في ذلك تطبيق أي تصحيحات مضمنة في الحزم وتشغيل البرامج النصية للإنشاء.
ومن خلال القدرة على انتحال الحزم التي تم تنزيلها، يمكن للمهاجم إضافة تصحيحاته الخاصة أو ملفات Makefiles إليها، مما يسمح بإجراء تغييرات على الصورة الناتجة أو إنشاء برامج نصية للنظام وتنفيذ التعليمات البرمجية الخاصة بها.
من جانب الضعف السادس الذي تم تصنيفه تحت تالوس-2023-1845 (CVE-2023-43608) يحدث بسبب خطأ في تنفيذ الوظيفة BR_NO_CHECK_HASH_FOR, مما يسمح لك بتعطيل الشيكات سلامة التجزئة للحزم المحددة.
يذكر أن الفقرة:
يُطلق على كل سطر تجزئة في ملف .hash اسم check_one_hash. إذا لم تكن التجزئة متطابقة، فسيتم الخروج من check_one_hash مع رمز خطأ. وبخلاف ذلك، تتم زيادة nb_checks للإشارة إلى نجاح الفحص. إذا لم يكن هناك إدخال في ملف .hash للتحقق من ملف الإدخال المحدد، فإن التحقق في حالة IF سيرجع خطأ ما لم يحتوي BR_NO_CHECK_HASH_FOR[9] على هذا الملف المحدد، مما يعني أن الملف مستبعد من عمليات التحقق من التجزئة.
EN المجموع، هناك 3 طرق للتحقق من إرجاع التجزئة القيمة 0:
- .hash لا يوجد ملف للحزمة
- يتطابق تجزئة ملف $ مع تعريف ملف .hash
- $file غير موجود في ملف .hash ويحتوي BR_NO_CHECK_HASH_FOR على الاسم الأساسي للحزمة (تجاوز عمليات التحقق بشكل صريح)
لمفهوم مظاهرة الضعف، و ركز المطورون على الخيار 3، حيث يبدو أن هذا يُستخدم بشكل شائع لتجاوز عمليات التحقق من سلامة الموارد التي لا يمكن تجزئتها بسهولة (مثل موارد التطوير التي تتغير بشكل متكرر). يتم استخدامه أيضًا عند إنشاء إصدارات محددة من الحزمة، والتي قد لا تكون تجزئاتها متاحة في مصادر Buildroot.
سمحت بعض الحزم، مثل Linux kernel وU-Boot والبرامج الثابتة العكسية، بتحميل أحدث الإصدارات التي لم يتم إنشاء تجزئات التحقق لها بعد. بالنسبة لهذه الإصدارات، تم استخدام خيار BR_NO_CHECK_HASH_FOR، والذي يعمل على تعطيل التحقق من التجزئة.
تم تنزيل البيانات عبر HTTPS، ولكن افتراضيًا، إذا فشل التنزيل، تم استخدام بديل للوصول إلى الموقع دون تشفير باستخدام بروتوكول http://. أثناء هجوم MITM، يمكن للمهاجم حظر الاتصال بخادم HTTPS ومن ثم يتم التراجع عن التنزيل.
أخيرًا ، يجب ذكر ذلك تم حل نقاط الضعف في أحدث إصدارات Buildroot وإذا كنت مهتمًا بأن تكون قادرًا على معرفة المزيد عنها ، يمكنك الرجوع إلى التفاصيل في الرابط التالي.