Họ đã phát hiện ra một lỗ hổng trong thư viện uClibc và uClibc-ng ảnh hưởng đến phần sụn Linux 

Một vài ngày trước, tin tức đã được phát hành rằng trong thư viện tiêu chuẩn C uClibc và uClibc-ng, được sử dụng trong nhiều thiết bị nhúng và di động, một lỗ hổng đã được xác định (với CVE chưa được chỉ định), cho phép thay thế dữ liệu giả trong bộ đệm DNS, có thể được sử dụng để giả mạo địa chỉ IP của một miền tùy ý trong bộ đệm và chuyển hướng yêu cầu miền đến máy chủ của kẻ tấn công.

Về vấn đề nó được đề cập rằng điều này ảnh hưởng đến các chương trình cơ sở Linux khác nhau cho bộ định tuyến, điểm truy cập và thiết bị IoT, cũng như các bản phân phối Linux nhúng như OpenWRT và Embedded Gentoo.

Về lỗ hổng

Lỗ hổng là do việc sử dụng các số nhận dạng giao dịch có thể dự đoán được trong mã để gửi các truy vấn của DNS. ID truy vấn DNS được chọn bằng cách chỉ cần tăng bộ đếm mà không cần ngẫu nhiên hóa thêm số cổng, điều này khiến nó có thể làm nhiễm độc bộ nhớ cache DNS bằng cách gửi trước các gói UDP với các phản hồi không có thật (phản hồi sẽ được chấp nhận nếu nó đến trước phản hồi từ máy chủ thực và bao gồm nhận dạng chính xác).

Không giống như phương pháp Kaminsky được đề xuất vào năm 2008, thậm chí không cần phải đoán ID giao dịch, vì ban đầu nó có thể dự đoán được (ban đầu, nó được đặt thành 1, điều này tăng lên theo từng yêu cầu và không được chọn ngẫu nhiên).

Để bảo vệ bản thân chống lại việc đoán ID, đặc điểm kỹ thuật khuyến nghị thêm về việc sử dụng phân phối ngẫu nhiên các số cổng mạng nguồn gốc mà từ đó các truy vấn DNS được gửi đi, điều này bù đắp cho việc không đủ kích thước của ID.

Khi bật ngẫu nhiên cổng, để tạo phản hồi giả, ngoài việc chọn số nhận dạng 16 bit, cũng cần chọn số cổng mạng. Trong uClibc và uClibc-ng, việc ngẫu nhiên hóa đó không được kích hoạt một cách rõ ràng (khi liên kết được gọi, một cổng UDP nguồn ngẫu nhiên không được chỉ định) và việc triển khai nó phụ thuộc vào cấu hình hệ điều hành.

Khi ngẫu nhiên hóa cổng bị tắt, xác định id yêu cầu nào để tăng dần được đánh dấu là một nhiệm vụ tầm thường. Nhưng ngay cả trong trường hợp ngẫu nhiên, kẻ tấn công chỉ cần đoán cổng mạng từ phạm vi 32768-60999, mà hắn có thể sử dụng đồng thời gửi nhiều phản hồi giả trên các cổng mạng khác nhau.

Vấn đề đã được xác nhận trong tất cả các phiên bản hiện tại của uClibc và uClibc-ng, bao gồm các phiên bản mới nhất của uClibc 0.9.33.2 và uClibc-ng 1.0.40.

“Điều quan trọng cần lưu ý là một lỗ hổng ảnh hưởng đến thư viện C tiêu chuẩn có thể khá phức tạp,” nhóm đã viết trong một bài đăng trên blog tuần này.

"Không chỉ có hàng trăm hoặc hàng nghìn lệnh gọi đến chức năng dễ bị tấn công tại nhiều điểm trong một chương trình đơn lẻ, mà lỗ hổng bảo mật còn ảnh hưởng đến một số lượng vô hạn các chương trình đa nhà cung cấp khác được định cấu hình để sử dụng thư viện đó."

Vào tháng 2021 năm XNUMX, thông tin về lỗ hổng bảo mật đã được gửi đi sang CERT / CC để chuẩn bị mảng phối hợp. Vào tháng 2022 năm XNUMX, vấn đề đã được chia sẻ với hơn 200 nhà sản xuất liên kết với CERT / CC.

Vào tháng XNUMX, đã có nỗ lực liên hệ riêng với người bảo trì dự án uClibc-ng, nhưng anh ta trả lời rằng anh ta không thể tự sửa lỗ hổng bảo mật và đề nghị tiết lộ công khai thông tin về sự cố, hy vọng nhận được trợ giúp phát triển bản sửa lỗi của cộng đồng. Từ các nhà sản xuất, NETGEAR đã thông báo về việc phát hành bản cập nhật với việc loại bỏ lỗ hổng bảo mật.

Điều quan trọng cần lưu ý là một lỗ hổng ảnh hưởng đến thư viện C tiêu chuẩn có thể khá phức tạp. Không chỉ có hàng trăm hoặc hàng nghìn lệnh gọi đến chức năng dễ bị tấn công tại nhiều điểm trong một chương trình, mà lỗ hổng bảo mật còn ảnh hưởng đến vô số chương trình khác từ nhiều nhà cung cấp được định cấu hình để sử dụng thư viện đó.

Cần lưu ý rằng lỗ hổng bảo mật xuất hiện trong các thiết bị của nhiều nhà sản xuất (ví dụ: uClibc được sử dụng trong phần sụn của Linksys, Netgear và Axis), nhưng vì lỗ hổng này vẫn chưa được vá trong uClibc và uClibc-ng, thông tin chi tiết về các thiết bị và cụ thể các nhà sản xuất mà sản phẩm của họ có vấn đề, cho đến khi chúng được tiết lộ.

Cuối cùng nếu bạn muốn biết thêm về nó, bạn có thể kiểm tra các chi tiết Trong liên kết sau đây.


Hãy là người đầu tiên nhận xét

Để lại bình luận của bạn

địa chỉ email của bạn sẽ không được công bố. Các trường bắt buộc được đánh dấu bằng *

*

*

  1. Chịu trách nhiệm về dữ liệu: Miguel Ángel Gatón
  2. Mục đích của dữ liệu: Kiểm soát SPAM, quản lý bình luận.
  3. Hợp pháp: Sự đồng ý của bạn
  4. Truyền thông dữ liệu: Dữ liệu sẽ không được thông báo cho các bên thứ ba trừ khi có nghĩa vụ pháp lý.
  5. Lưu trữ dữ liệu: Cơ sở dữ liệu do Occentus Networks (EU) lưu trữ
  6. Quyền: Bất cứ lúc nào bạn có thể giới hạn, khôi phục và xóa thông tin của mình.