Phát hiện thiết bị Dell, HP và Lenovo sử dụng phiên bản OpenSSL lỗi thời (BTV hoàn thiện các trường)

14:00 | 15/12/2022

Một phân tích về chương trình cơ sở trên các thiết bị của Dell, HP và Lenovo đã tiết lộ sự hiện diện của các phiên bản lỗi thời của thư viện mật mã OpenSSL, qua đó nhấn mạnh rủi ro chuỗi cung ứng.

Bộ công cụ phát triển EFI, hay còn gọi là EDK , là một triển khai mã nguồn mở của Giao diện firmware mở rộng hợp nhất (UEFI), có chức năng như một giao diện giữa hệ điều hành và phần mềm được nhúng trong phần cứng của thiết bị.

Môi trường phát triển firmware, ở phiên bản thứ hai (EDK II), đi kèm với gói mã hóa riêng có tên là CryptoPkg , và đến lượt nó lại sử dụng các dịch vụ từ dự án OpenSSL.

Theo công ty bảo mật chương trình cơ sở Binarly, hình ảnh chương trình cơ sở được liên kết với các thiết bị dành cho doanh nghiệp Lenovo Thinkpad được phát hiện sử dụng ba phiên bản OpenSSL khác nhau: 0.9.8zb, 1.0.0a và 1.0.2j, phiên bản cuối cùng được phát hành vào năm 2018.

Tệ hơn nữa, một trong các mô-đun firmware có tên InfineonTpmUpdateDxe dựa trên OpenSSL phiên bản 0.9.8zb được xuất xưởng vào ngày 4 tháng 8 năm 2014.

"Mô-đun InfineonTpmUpdateDxe chịu trách nhiệm cập nhật chương trình cơ sở của Mô-đun nền tảng đáng tin cậy ( TPM ) trên chip Infineon", Binarly giải thích trong một bài viết kỹ thuật.

 

"Điều này cho thấy rõ ràng vấn đề về chuỗi cung ứng với các phần phụ thuộc của bên thứ ba khi có vẻ như các phần phụ thuộc này chưa bao giờ nhận được bản cập nhật, ngay cả đối với các vấn đề bảo mật quan trọng."

Bỏ qua sự đa dạng của các phiên bản OpenSSL, một số gói chương trình cơ sở của Lenovo và Dell đã sử dụng phiên bản thậm chí còn cũ hơn (0.9.8l), ra mắt vào ngày 5 tháng 11 năm 2009. Tương tự, mã chương trình cơ sở của HP cũng sử dụng phiên bản 10 năm tuổi của thư viện (0.9.8w).

Việc chương trình cơ sở của thiết bị sử dụng nhiều phiên bản OpenSSL trong cùng một gói nhị phân làm nổi bật thực tế là sự phụ thuộc mã của bên thứ ba có thể gây ra những điều phức tạp hơn trong hệ sinh thái chuỗi cung ứng.

Binarly tiếp tục chỉ ra những điểm yếu trong cái được gọi là Hóa đơn vật liệu phần mềm (SBOM) phát sinh do tích hợp các mô-đun nhị phân đã biên dịch (còn gọi là nguồn đóng) trong firmware.

Công ty cho biết: “Chúng tôi nhận thấy nhu cầu cấp thiết về một lớp Xác thực SBOM bổ sung khi nói đến mã được biên dịch để xác thực ở cấp độ nhị phân, danh sách thông tin phụ thuộc của bên thứ ba khớp với SBOM thực tế do nhà cung cấp cung cấp”.

"Cách tiếp cận 'tin cậy nhưng xác minh lại' là cách tốt nhất để đối phó với các lỗi SBOM và giảm rủi ro chuỗi cung ứng."

https://thehackernews.com/2022/11/dell-hp-and-lenovo-devices-found-using.html