Các nhà phát triển hệ điều hành di động Aurora (một nhánh của hệ điều hành Sailfish do công ty Open Mobile Platform phát triển) đã chia sẻ một câu chuyện tiết lộ về việc loại bỏ () trong Glibc, chỉ xuất hiện trên nền tảng ARMv7. Thông tin về lỗ hổng này đã được tiết lộ vào tháng XNUMX, nhưng cho đến những ngày gần đây, vẫn chưa có bản sửa lỗi nào, mặc dù thực tế là các lỗ hổng này mức độ nguy hiểm cao và có một nguyên mẫu khai thác đang hoạt động cho phép bạn tổ chức thực thi mã khi xử lý dữ liệu được định dạng theo một cách nhất định trong các hàm memcpy() và memmove(). Sửa lỗi gói cho и vẫn chưa được phát hành và lỗ hổng này vẫn chưa được sửa trong gần hai tháng kể từ thời điểm công bố rộng rãi và năm tháng kể từ thời điểm các nhà phát triển Glibc được thông báo.
Lỗ hổng này xuất hiện trong quá trình triển khai memcpy() và memmove() bằng hợp ngữ cho ARMv7 và nguyên nhân là do xử lý không chính xác các giá trị âm của tham số xác định kích thước của vùng được sao chép. Các vấn đề với việc phát triển bản vá bắt đầu khi các công ty и đã thông báo rằng nền tảng của họ không bị ảnh hưởng bởi sự cố này vì họ không xây dựng cho hệ thống ARMv32 7-bit và không tham gia tạo bản sửa lỗi. Các nhà phát triển của nhiều bản phân phối nhúng dường như đã dựa vào nhóm Glibc và cũng không tích cực tham gia vào việc chuẩn bị bản sửa lỗi.
Tùy chọn Để ngăn chặn vấn đề, Huawei gần như ngay lập tức đề xuất rằng họ sẽ cố gắng thay thế các hướng dẫn lắp ráp vận hành bằng toán hạng có dấu (bge và blt) bằng các toán hạng tương tự không dấu (blo và bhs). Các nhà bảo trì Glibc đã phát triển một bộ thử nghiệm để kiểm tra các tình trạng lỗi khác nhau, sau đó hóa ra bản vá của Huawei không phù hợp và không xử lý tất cả các kết hợp dữ liệu đầu vào có thể có.
Vì Aurora OS có bản dựng 32 bit cho ARM nên các nhà phát triển đã quyết định tự mình vá lỗ hổng này và đưa ra giải pháp cho cộng đồng. Khó khăn là cần phải viết một cách triển khai hàm hợp ngữ hiệu quả và tính đến các tùy chọn khác nhau cho các đối số đầu vào. Việc thực hiện đã được viết lại bằng cách sử dụng các hướng dẫn không dấu. Hóa ra nó nhỏ, nhưng vấn đề chính là duy trì tốc độ thực thi và tránh suy giảm hiệu suất của các hàm memcpy và memmove, đồng thời duy trì khả năng tương thích với tất cả các tổ hợp giá trị đầu vào.
Vào đầu tháng 3, hai phiên bản sửa lỗi đã được chuẩn bị, vượt qua khung thử nghiệm của các nhà bảo trì Glibc và bộ thử nghiệm nội bộ của Aurora. Vào ngày XNUMX tháng XNUMX, một trong những phương án đã được chọn và vào danh sách gửi thư của Glibc. Một tuần sau
đã một bản vá khác có cách tiếp cận tương tự, giúp khắc phục sự cố trong quá trình triển khai đa nền tảng mà Huawei trước đây đã cố gắng khắc phục. Việc thử nghiệm mất một tháng và do tầm quan trọng của bản vá.
Chỉnh sửa ngày 8 tháng XNUMX đến nhánh chính của bản phát hành glibc 2.32 sắp tới. Việc triển khai bao gồm hai bản vá - để triển khai memcpy đa nền tảng cho ARMv7 và để triển khai ngôn ngữ tập hợp chung của memcpy() và memmove() cho ARM.
Sự cố này ảnh hưởng đến hàng triệu thiết bị ARMv7 chạy Linux và nếu không có bản cập nhật thích hợp, chủ sở hữu sẽ gặp rủi ro khi kết nối chúng với mạng (các dịch vụ và ứng dụng có thể truy cập mạng chấp nhận dữ liệu đầu vào mà không bị giới hạn kích thước có thể bị tấn công). Ví dụ: cách khai thác do các nhà nghiên cứu đã xác định lỗ hổng chuẩn bị cho thấy cách tấn công máy chủ HTTP được tích hợp trong hệ thống thông tin ô tô bằng cách gửi yêu cầu GET rất lớn và giành quyền truy cập root vào hệ thống.
Nguồn: opennet.ru