Thông tin chi tiết về các bản vá do Đại học Minnesota đệ trình được tiết lộ

Trong vài ngày qua đã có cuộc thảo luận trường hợp về các hành động được thực hiện bởi một nhóm các nhà nghiên cứu từ Đại học Minnesota, vì theo quan điểm của nhiều người, những hành động như vậy liên quan đến việc đưa ra các lỗ hổng trong Nhân Linux là không có lý do gì.

Và mặc dù một nhóm Các nhà nghiên cứu của Đại học Minnesotđể xuất bản một bức thư ngỏ xin lỗi, mà việc chấp nhận các thay đổi đối với nhân Linux đã bị chặn bởi Greg Kroah-Hartman, tiết lộ chi tiết các bản vá được gửi cho các nhà phát triển nhân và thư từ với những người bảo trì liên quan đến các bản vá này.

Đáng chú ý là tất cả các bản vá sự cố đã bị từ chối Theo sáng kiến ​​của những người bảo trì, không có bản vá nào được chấp thuận. Thực tế này cho thấy rõ tại sao Greg Kroah-Hartman lại hành động thô bạo như vậy, vì không rõ các nhà nghiên cứu sẽ làm gì nếu các bản vá được người bảo trì chấp thuận.

Khi nhìn lại, lập luận rằng họ định báo cáo lỗi và họ sẽ không cho phép các bản vá truy cập vào Git, nhưng không rõ họ sẽ thực sự làm gì hoặc họ có thể đi bao xa.

Tổng cộng, trong tháng 2020 năm XNUMX, năm bản vá đã được gửi từ các địa chỉ ẩn danh acostag.ubuntu@gmail.com và jameslouisebond@gmail.com (một lá thư của James Bond): hai bản đúng và ba bản có lỗi ẩn, tạo điều kiện cho sự xuất hiện của các lỗ hổng.

Mỗi bản vá chỉ chứa 1 đến 4 dòng mã. Ý tưởng chính đằng sau các bản vá lỗi là việc sửa lỗi rò rỉ bộ nhớ có thể tạo điều kiện cho lỗ hổng miễn phí kép.

Dự án nhằm mục đích cải thiện tính bảo mật của quá trình vá lỗi trong OSS. Là một phần của dự án, chúng tôi đã nghiên cứu các vấn đề tiềm ẩn với quy trình vá lỗi OSS, bao gồm nguyên nhân của các vấn đề và đề xuất giải quyết chúng.

Trên thực tế, nghiên cứu này bộc lộ một số vấn đề, nhưng mục tiêu của nó là kêu gọi nỗ lực cải thiện
quá trình vá lỗi để thúc đẩy nhiều công việc hơn nhằm phát triển các kỹ thuật kiểm tra và xác minh các bản vá và cuối cùng là làm cho hệ điều hành trở nên an toàn hơn.

Dựa trên các bản vá này, chúng tôi tóm tắt mô hình của chúng, nghiên cứu lý do cụ thể khiến các bản vá gây ra lỗi khó phát hiện (bằng cả phân tích định tính và định lượng) và quan trọng nhất là đưa ra đề xuất để giải quyết vấn đề.

Bản vá có vấn đề đầu tiên đã khắc phục rò rỉ bộ nhớ bằng cách thêm lệnh gọi tới kfree() trước khi trả lại quyền điều khiển trong trường hợp có lỗi nhưng tạo điều kiện truy cập vào vùng nhớ sau khi được giải phóng (use-after-free).

Bản vá được chỉ định đã bị nhà bảo trì từ chối, người đã xác định được vấn đề và chỉ ra rằng một năm trước ai đó đã cố gắng đề xuất một thay đổi tương tự và ban đầu nó đã được chấp nhận nhưng đã bị loại bỏ cùng ngày sau khi xác định được tình trạng của lỗ hổng.

Bản vá thứ hai cũng có các điều kiện để sử dụng sau khi phát hành. Bản vá được chỉ định không được người bảo trì chấp nhận. Người này đã từ chối bản vá do một vấn đề khác với list_add_tail, nhưng không nhận thấy rằng con trỏ "chdev" có thể được giải phóng trong hàm put_device, sau đó được sử dụng trong lệnh gọi tới dev_err (& chdev -> dev..). Tuy nhiên, bản vá không được chấp nhận, mặc dù vì những lý do không liên quan đến lỗ hổng.

Thật kỳ lạ, Ban đầu người ta cho rằng 4 trong số 5 bản vá có vấn đề, nhưng chính các nhà nghiên cứu đã mắc sai lầm và trong một bản vá có vấn đề, theo quan điểm của họ, giải pháp chính xác đã được đề xuất mà không có các điều kiện được cho là về việc sử dụng bộ nhớ sau khi phát hành.

Trong nghiên cứu này, chúng tôi trình bày khái niệm về "lỗ hổng chưa trưởng thành" trong đó tình trạng dễ bị tổn thương bị thiếu, nhưng có thể trở thành lỗ hổng thực sự khi điều kiện đó được ngầm ẩn.
được giới thiệu bởi một bản vá cho một lỗi khác.

Chúng tôi cũng phát triển các công cụ giúp chúng tôi tìm ra những vị trí có thể bị ảnh hưởng trong mã.
các bản vá lỗi và đề xuất những gì có thể khiến các bản vá lỗi này khó bị phát hiện.

Một tuần sau, thông tin được gửi đến các nhà phát triển hạt nhân với đề xuất thảo luận về khả năng thúc đẩy các lỗ hổng dưới chiêu bài sửa lỗi tầm thường đối với rò rỉ bộ nhớ, nhưng không có thông tin gì về những nỗ lực gửi bản vá độc hại trước đó.

Bản vá thứ ba cũng bị nhà bảo trì từ chối do một lỗi khác không có lỗ hổng (ứng dụng kép trong pdev).


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.