تجزیه‌وتحلیل image های firmware در تمامی دستگاه‌های Dell، HP و Lenovo وجود نسخه‌های قدیمی کتابخانه رمزنگاری OpenSSL[1] را نشان می‌دهد که بر ریسک زنجیره تأمین تأکید می‌کند.
کیت توسعه EFI، با نام مستعار [۲]EDK، یک پیاده‌سازی منبع باز از رابط firmware توسعه‌پذیر یکپارچه[۳] (UEFI) است که به‌عنوان رابط بین سیستم‌عامل و firmware تعبیه‌شده در سخت‌افزار دستگاه عمل می‌کند.
این محیط توسعه firmware، که در دومین iteration خود (EDK II) است، با بسته رمزنگاری خاص خود به نام [۴]CryptoPkg ارائه می‌شود که به‌نوبه خود از خدمات پروژه OpenSSL استفاده می‌کند.
بر اساس شرکت امنیتی Binarly، تصویر firmware مرتبط با دستگاه‌های شرکتی Lenovo Thinkpad از سه نسخه مختلف OpenSSL استفاده می‌کند: ۰٫۹٫۸zb، ۱٫۰٫۰a و ۱٫۰٫۲j که آخرین آن در سال ۲۰۱۸ منتشر شد.
علاوه بر این، یکی از ماژول‌های firmware به نام InfineonTpmUpdateDxe بر OpenSSL نسخه ۰٫۹٫۸zb متکی بود که در ۴ اوت ۲۰۱۴ منتشر شده است.
Binarly در یک گزارش فنی در هفته گذشته دراین‌باره توضیح داد[۵]: “ماژول InfineonTpmUpdateDxe مسئول به‌روزرسانی firmware ماژول پلتفرم قابل‌اعتماد ([۶]TPM) در تراشه Infineon است.”
“این به‌وضوح نشان‌دهنده مشکل زنجیره تأمین با وابستگی‌های شخص ثالث است، زمانی که به نظر می‌رسد این وابستگی‌ها حتی برای مسائل امنیتی حیاتی هرگز به‌روزرسانی دریافت نکرده‌اند.”
حتی اگر تنوع نسخه‌های OpenSSL را کنار بگذاریم، برخی از بسته‌های میان‌افزار Lenovo و Dell از نسخه قدیمی‌تر (۰٫۹٫۸l) استفاده می‌کردند که در ۵ نوامبر ۲۰۰۹ منتشر شده است. کد firmware دستگاه‌های HP نیز از یک نسخه ۱۰ سال پیش کتابخانه (۰٫۹٫۸w) استفاده می‌کرد.
این واقعیت که firmware دستگاه از چندین نسخه OpenSSL در یک بسته باینری استفاده می‌کند، نشان می‌دهد که چگونه وابستگی‌های کد شخص ثالث می‌تواند پیچیدگی‌های بیشتری را در اکوسیستم زنجیره تأمین ایجاد کند.
Binarly در ادامه به نقاط ضعف آنچه Software Bill of Materials یا [۷]SBOM نامیده می‌شود اشاره کرد که درنتیجه ادغام ماژول‌های باینری کامپایل شده (معروف به منبع بسته) در سیستم‌عامل ایجاد می‌شود.
این شرکت دراین‌باره گفت: «زمانی که نوبت به کدهای کامپایل شده برای اعتبارسنجی در سطح باینری می‌رسد، نیاز فوری به یک لایه اضافی از اعتبارسنجی SBOM می‌بینیم، در حقیقت فهرستی از اطلاعات وابستگی شخص ثالث که با SBOM واقعی ارائه‌شده توسط فروشنده، مطابقت دارد.»
رویکرد trust-but-verify یا همان «اعتماد اما تأیید» بهترین راه برای مقابله با خرابی‌های SBOM و کاهش خطرات زنجیره تأمین است.
منابع
[۱] https://apa.aut.ac.ir/?p=9302
[۳] https://en.wikipedia.org/wiki/UEFI
[۴] https://github.com/tianocore/edk2/tree/master/CryptoPkg
[۵] https://www.binarly.io/posts/OpenSSL_Usage_in_UEFI_Firmware_Exposes_Weakness_in_SBOMs
[۶] https://learn.microsoft.com/en-us/windows/security/information-protection/tpm/trusted-platform-module-overview
[۸] https://thehackernews.com/2022/11/dell-hp-and-lenovo-devices-found-using.html
ثبت ديدگاه