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, 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, vào 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 bức thư của James Bond): hai đúng và ba bao gồm 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 một lỗ hổng miễn phí kép.

Dự án nhằm nâng cao tính bảo mật của quá trình vá lỗi trong PMNM. 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 PMNM, 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 cho thấy một số vấn đề, nhưng mục đích của nó là kêu gọi nỗ lực cải thiện
quy trình vá lỗi để thúc đẩy nhiều công việc hơn để 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 an toàn hơn.

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

Bản vá lỗi đầu tiên đã khắc phục sự cố rò rỉ bộ nhớ bằng cách thêm lệnh gọi vào 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ùng nhớ sau khi nó được giải phóng (use-after-free).

Bản vá được chỉ định đã bị từ chối bởi người bảo trì, người đã xác định 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ỏ vào cùng ngày sau khi xác định các điều kiện dễ bị tổn thương.

Bản vá thứ hai cũng bao gồm các điều kiện cho vấn đề mặc sau khi phát hành. Bản vá đã chỉ định không được người bảo trì chấp nhận, người đã 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, được sử dụng tiếp theo 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 bảo mật.

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

Trong tác phẩm này, chúng tôi trình bày khái niệm «tính dễ bị tổn thương chưa trưởng thành» trong đó tình trạng tổn thương bị thiếu, nhưng nó có thể trở thành hiện thực khi tình trạng đó
đượ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 các vị trí mã có thể bị
của các bản vá giới thiệu lỗi và đề xuất điều gì có thể khiến các bản vá giới thiệu 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 bảo mật dưới chiêu bài sửa lỗi rò rỉ bộ nhớ tầm thường, nhưng không có thông tin gì về những nỗ lực gửi các 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).


Nội dung bài viết tuân thủ các nguyên tắc của chúng tôi về đạo đức biên tập. Để báo lỗi, hãy nhấp vào đâ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.