Race TOCTOU trong SCTP của Linux kernel (Linux) có thể gây use-after-free

Lưu ý: Dữ liệu này chỉ có tính chất tham khảo, phục vụ nghiên cứu an ninh mạng.CyStack khuyến nghị người dùng không sử dụng các thông tin này nhằm các mục đích bất hợp pháp

Giới thiệu chung

Dữ liệu gốc

Trong Linux kernel, lỗ hổng sau đã được khắc phục: sctp: sửa race TOCTOU trong SCTP_CMD_TIMER_START. Handler SCTP_CMD_TIMER_START kiểm tra timer_pending() trước khi gọi timer_reduce(). Timer có thể hết hạn và bị tách giữa hai thao tác này, khiến timer_reduce() kích hoạt lại timer mà không lấy association reference cần thiết cho timer vừa được kích hoạt. Callback của timer sau đó luôn giảm association reference của nó, có thể làm mất cân bằng bộ đếm reference của association và dẫn đến use-after-free trong quá trình teardown association. Sử dụng giá trị trả về của timer_reduce() để xác định timer có thực sự được kích hoạt hay không. Chỉ lấy association reference khi timer_reduce() khởi động thành công timer mới, qua đó loại bỏ race giữa việc kiểm tra trạng thái timer và kích hoạt lại timer. Vấn đề này được Nico Yip (@cyeaa) báo cáo khi làm việc với TrendAI Zero Day Initiative.

Sản phẩm và phạm vi ảnh hưởng

  • Linux kernel: bản ghi đánh dấu 4.19.126 đến trước 4.20 là bị ảnh hưởng.
  • Linux kernel: bản ghi đánh dấu 5.4.44 đến trước 5.5 là bị ảnh hưởng.
  • Linux kernel: bản ghi đánh dấu 5.6.16 đến trước 5.7 là bị ảnh hưởng; 5.7 cũng được đánh dấu bị ảnh hưởng trong một mục riêng.
  • Dữ liệu cập nhật của bản ghi liệt kê các ranh giới sửa theo nhánh được duy trì: 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.111, 6.18.53 và 7.2.7. Các nhánh tương ứng bị ảnh hưởng trước ranh giới sửa của chính nhánh đó. 7.3-rc1 được liệt kê là bị ảnh hưởng, trong khi 7.3 được liệt kê là không bị ảnh hưởng theo commit sửa gốc.
  • Bản ghi cũng đánh dấu nhiều dải Git và một số revision Git độc lập là bị ảnh hưởng. Không nên suy ra trạng thái an toàn của một revision hoặc nhánh song song chỉ từ việc một nhánh khác đã có bản vá.
  • Microsoft VEX đánh dấu azl3 kernel 0:6.6.157.1-1.azl3 của Azure Linux 3.0 là known affected và azl3 kernel 0:6.6.158.1-1.azl3 là bản sửa; trạng thái của Azure Linux 4.0 vẫn được đánh dấu under investigation.
  • Red Hat VEX liệt kê nhiều kernel product và OpenShift component là known affected, đồng thời ghi rõ một số sản phẩm không có bản sửa trong mục VEX đó. Các sản phẩm RHEL 6 được ghi nhận là ngoài phạm vi hỗ trợ.

Chi tiết kỹ thuật

Lỗi nằm trong handler SCTP_CMD_TIMER_START của SCTP. Handler kiểm tra timer_pending() rồi mới gọi timer_reduce(). Timer có thể hết hạn và bị tách giữa hai thao tác này; khi đó timer_reduce() vẫn có thể kích hoạt lại timer nhưng không lấy association reference cần thiết cho timer mới. Callback của timer sau đó luôn giảm association reference, làm mất cân bằng bộ đếm tham chiếu và có thể dẫn đến use-after-free trong quá trình teardown association.

Cách sửa sử dụng giá trị trả về của timer_reduce() để xác định timer có thực sự được kích hoạt hay không, rồi chỉ giữ association reference khi thao tác này thành công. Điều kiện khai thác là đường xử lý SCTP phải có thể tiếp cận được và kẻ tấn công phải tạo đúng cửa sổ thời gian rất hẹp giữa thao tác kiểm tra và thao tác kích hoạt lại timer. Bản ghi xác nhận khả năng tiếp cận qua mạng, không yêu cầu đặc quyền hoặc tương tác người dùng; chi tiết về chuỗi gói tin hoàn chỉnh và khả năng đạt được thực thi mã tùy ý chưa được thiết lập.

Khả năng khai thác

  • Khả năng tiếp cận: Có thể bị kích hoạt từ xa qua lưu lượng SCTP. Đánh giá trong bản ghi cho biết peer mạng không cần xác thực và không cần người dùng tương tác.
  • Điều kiện: Kẻ tấn công phải thắng một race TOCTOU rất hẹp khi timer SCTP hết hạn trong lúc association đang đi qua quá trình đóng hoặc teardown. Vì vậy độ phức tạp khai thác cao và việc khai thác đáng tin cậy là khó.
  • Phạm vi triển khai: Red Hat cho biết SCTP kernel module không được nạp mặc định trong các hệ thống của họ; các máy không chạy dịch vụ phụ thuộc SCTP không nằm trong điều kiện phơi nhiễm được mô tả ở đó.
  • Tình trạng khai thác: Bản ghi được cung cấp không xác lập tình trạng khai thác thực tế hoặc public exploit. Không nên suy ra hệ thống an toàn chỉ từ việc chưa có trạng thái đó.

Tác động kỹ thuật

Lỗi có thể làm association reference bị giảm thừa, giải phóng sctp_association khi vẫn còn đường xử lý sử dụng nó, rồi dẫn đến use-after-free hoặc refcount underflow trong kernel. Hậu quả trực tiếp có thể là crash kernel, từ chối dịch vụ hoặc mất ổn định host. Vì vùng nhớ bị giải phóng thuộc đối tượng kernel, việc ghi hoặc đọc sau khi giải phóng có thể ảnh hưởng đến tính toàn vẹn và bảo mật của kernel, nhưng bản ghi không xác nhận một exploit đáng tin cậy cho thực thi mã hoặc leo thang đặc quyền. Tác động được giới hạn trong cùng miền bảo vệ kernel theo đánh giá hiện có và phụ thuộc vào việc hệ thống thực sự cung cấp SCTP.

Tác động đến tổ chức

  • Máy chủ sử dụng SCTP có thể bị crash hoặc gián đoạn dịch vụ nếu race làm hỏng vòng đời của SCTP association.
  • Vì lỗi xảy ra trong kernel và liên quan đến use-after-free, việc khai thác thành công có thể làm mất ổn định toàn bộ host, không chỉ một tiến trình cung cấp SCTP.
  • Tác động cụ thể đến dữ liệu hoặc quyền hạn phụ thuộc vào khả năng kiểm soát vùng nhớ sau khi association bị giải phóng; bản ghi không chứng minh một kịch bản chiếm quyền hoặc rò rỉ dữ liệu cụ thể.
  • Hệ thống không sử dụng SCTP có điều kiện phơi nhiễm thấp hơn, nhưng vẫn cần xác minh kernel package thay vì chỉ dựa vào việc SCTP module hiện chưa được nạp.

Cách khắc phục

  1. Ưu tiên cập nhật kernel theo bản vá SCTP upstream hoặc bản cập nhật của nhà phân phối. Với các nhánh có ranh giới đã được ghi nhận, sử dụng bản tương ứng tại 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.111, 6.18.53 hoặc 7.2.7 tùy nhánh. Không dùng ranh giới của một nhánh để kết luận cho nhánh khác.
  2. Với Azure Linux 3.0, cập nhật từ azl3 kernel 0:6.6.157.1-1.azl3 lên azl3 kernel 0:6.6.158.1-1.azl3, theo trạng thái VEX của Microsoft.
  3. Đối với các hệ thống chạy kernel thuộc các khoảng 4.19.126 đến trước 4.20, 5.4.44 đến trước 5.5, hoặc 5.6.16 đến trước 5.7, áp dụng bản cập nhật kernel hoặc patch upstream tương ứng. Vì 5.7 cũng được ghi nhận là bị ảnh hưởng trong mục riêng, không coi việc chuyển sang 5.7 tự động là biện pháp khắc phục.
  4. Kiểm tra advisory của nhà phân phối cho các kernel package và kernel-rt package cụ thể. Red Hat hiện ghi nhận nhiều sản phẩm downstream bị ảnh hưởng và một số sản phẩm không có fix trong VEX; RHEL 6 được ghi nhận là ngoài phạm vi hỗ trợ.
  5. Nếu chưa thể cập nhật, xác định các dịch vụ SCTP phụ thuộc trước khi cân nhắc không nạp hoặc hạn chế SCTP. Việc không chạy dịch vụ SCTP có thể loại bỏ điều kiện phơi nhiễm được Red Hat mô tả, nhưng không thay thế việc cập nhật kernel.

Cách phát hiện

  1. Kiểm kê kernel đang chạy, gói kernel và, nếu có thể, commit hoặc bản vá SCTP tương ứng. Đối chiếu từng nhánh với các ranh giới bị ảnh hưởng và đã được sửa trong affected_summary.
  2. Xác định máy có nạp SCTP module hoặc có ứng dụng cung cấp hay sử dụng SCTP hay không. Đây là kiểm tra mức phơi nhiễm, không phải bằng chứng rằng kernel đã an toàn.
  3. Với mã nguồn hoặc bản dựng nội bộ, kiểm tra handler SCTP_CMD_TIMER_START và xác nhận association reference chỉ được giữ khi timer_reduce() thực sự khởi động timer mới.
  4. Rà soát kernel log, crash dump và báo cáo lỗi liên quan đến use-after-free, refcount imbalance hoặc crash trong SCTP association teardown như một biện pháp giám sát bổ sung. Đây là tín hiệu phòng ngừa, không phải IOC đã được xác nhận.
  5. Không coi việc không thấy log lỗi là bằng chứng loại trừ lỗ hổng hoặc chứng minh hệ thống không bị khai thác.
Nguồn (26)
Tìm hiểu thêm

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện

Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.

Khám phá các giải pháp khác liên quan