Анализът на фърмуера на устройства от Dell, HP и Lenovo разкри наличието на остарели версии на криптографската библиотека OpenSSL, което подчертава риска във веригата за доставки.
EFI Development Kit, известен още като EDK, е реализация с отворен код на Unified Extensible Firmware Interface (UEFI), който функционира като интерфейс между операционната система и фърмуера, вграден в хардуера на устройството.
Средата за разработване на фърмуер, която е във втората си итерация (EDK II), се предлага със собствен криптографски пакет, наречен CryptoPkg, който на свой ред използва услуги от проекта OpenSSL.
Според компанията за сигурност на фърмуера Binarly е установено, че образът на фърмуера, свързан с корпоративните устройства Lenovo Thinkpad, използва три различни версии на OpenSSL: 0.9.8zb, 1.0.0a и 1.0.2j, последната от които е пусната през 2018г.
Нещо повече, един от модулите на фърмуера, наречен InfineonTpmUpdateDxe, разчиташе на OpenSSL версия 0.9.8zb, която беше доставена на 4 август 2014г.
„Модулът InfineonTpmUpdateDxe отговаря за актуализирането на фърмуера на Trusted Platform Module (TPM) на чипа Infineon“, обясни Бинарли в техническо описание миналата седмица.
„Това ясно показва проблема с веригата за доставки със зависимостите от трети страни, когато изглежда, че тези зависимости никога не са получавали актуализация, дори за критични проблеми със сигурността.“
Като оставим настрана разнообразието от версии на OpenSSL, някои от пакетите с фърмуер от Lenovo и Dell използват още по-стара версия (0.9.8l), която е излязла на 5 ноември 2009г. Кодът на фърмуера на HP също така използваше 10-годишна версия на библиотеката (0.9.8w).
Фактът, че фърмуерът на устройството използва няколко версии на OpenSSL в един и същ двоичен пакет, подчертава как зависимостите от кода на трети страни могат да внесат повече сложност в екосистемата на веригата за доставки.
Бинарли посочи още слабостите в така наречения софтуерен списък на материалите (SBOM), които възникват в резултат на интегрирането на компилирани двоични модули (известни още като затворен код) във фърмуера.
„Виждаме спешна необходимост от допълнително ниво на SBOM Validation, когато става въпрос за компилиран код, за да се валидира на ниво двоичен код списъкът с информация за зависимостите от трети страни, който да съответства на действителния SBOM, предоставен от доставчика“, заявиха от компанията.
„Подходът „доверявай се, но проверявай“ е най-добрият начин за справяне с неуспехите на SBOM и за намаляване на рисковете по веригата на доставки.“
