Dirty Frag: lỗ hổng LPE Linux phổ quát (leo thang đặc quyền cục bộ)

 (openwall.com)
2 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Dirty Frag là lỗ hổng leo thang đặc quyền cục bộ phổ quát cho phép giành quyền root trên hầu hết các bản phân phối Linux lớn, và do lịch công bố có trách nhiệm cùng lệnh cấm công bố bị phá vỡ nên hiện vẫn chưa có bản vá và chưa có CVE
  • Đây là phần mở rộng của cùng lớp lỗi với Dirty Pipe và Copy Fail; vì là lỗi logic mang tính quyết định, nên không cần race condition và tỷ lệ thành công rất cao
  • Vòng đời hiệu lực của lỗ hổng vào khoảng 9 năm, đã được kiểm thử trên các bản phân phối lớn như Ubuntu, RHEL, Fedora, openSUSE
  • Ngay cả trên các hệ thống đã áp dụng biện pháp giảm thiểu Copy Fail trước đây (blacklist algif_aead), chúng vẫn dễ bị ảnh hưởng bởi Dirty Frag
  • Biện pháp giảm thiểu tạm thời được khuyến nghị là gỡ các mô-đun esp4, esp6, rxrpc gây ra lỗ hổng cho đến khi bản vá từ bản phân phối được phát hành

Tổng quan

  • Đây là lớp lỗi làm nhiễm bẩn thành viên frag của cấu trúc sk_buff, là phần mở rộng của cùng lớp lỗi mà Dirty Pipe và Copy Fail cùng thuộc về
  • Có thể xâu chuỗi lỗ hổng xfrm-ESP Page-Cache Write và RxRPC Page-Cache Write để giành quyền root trên các bản phân phối Linux lớn
  • Là lỗi logic mang tính quyết định nên không phụ thuộc vào timing window, không cần race condition
  • Ngay cả khi khai thác thất bại thì kernel panic cũng không xảy ra, và tỷ lệ thành công rất cao

Lý do xâu chuỗi hai lỗ hổng

  • xfrm-ESP Page-Cache Write cung cấp primitive STORE 4 byte tùy ý mạnh, tương tự Copy Fail, và có trong hầu hết các bản phân phối, nhưng yêu cầu quyền tạo namespace
  • Trên Ubuntu, trong một số môi trường chính sách AppArmor chặn việc tạo user namespace không đặc quyền, nên trong môi trường đó không thể kích hoạt xfrm-ESP Page-Cache Write
  • RxRPC Page-Cache Write không cần quyền tạo namespace, nhưng bản thân mô-đun rxrpc.ko lại không có trong phần lớn các bản phân phối
    • Tuy vậy, trên Ubuntu mô-đun rxrpc.ko được nạp mặc định
  • Khi xâu chuỗi hai lỗ hổng, có thể bù đắp điểm mù của nhau, nhờ đó giành quyền root trên mọi bản phân phối lớn

Quan hệ với Copy Fail

  • Copy Fail là động lực khởi đầu nghiên cứu này
  • xfrm-ESP Page-Cache Write dùng chung sink với Copy Fail, nhưng có thể được kích hoạt bất kể mô-đun algif_aead có sẵn hay không
  • Ngay cả trên các hệ thống đã áp dụng biện pháp giảm thiểu Copy Fail được công bố (blacklist algif_aead), chúng vẫn dễ bị Dirty Frag ảnh hưởng

Phạm vi ảnh hưởng

  • xfrm-ESP Page-Cache Write: từ commit cac2661c53f3 (2017-01-17) đến upstream hiện tại
  • RxRPC Page-Cache Write: từ commit 2dc334f1a63a (2023-06) đến upstream hiện tại
  • Vòng đời hiệu lực của lỗ hổng vào khoảng 9 năm
  • Các phiên bản bản phân phối đã kiểm thử:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

Biện pháp giảm thiểu

  • Do lịch công bố có trách nhiệm và lệnh cấm công bố bị phá vỡ, chưa có bản vá cho bất kỳ bản phân phối nào
  • Biện pháp giảm thiểu tạm thời là cung cấp lệnh gỡ các mô-đun gây ra lỗ hổng: 
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    • Đăng ký blacklist các mô-đun esp4, esp6, rxrpc trong /etc/modprobe.d/dirtyfrag.conf và gỡ chúng
  • Sau khi từng bản phân phối backport bản vá, cần áp dụng bản cập nhật tương ứng

Quá trình công bố

  • Sau khi trao đổi với các maintainer của linux-distros@vs.openwall.org, tài liệu Dirty Frag được công bố theo yêu cầu của họ
  • Lệnh cấm công bố đã bị phá vỡ bởi yếu tố bên ngoài, và hiện chưa có bản vá hay CVE
  • PoC đã được công bố sau khi trao đổi với linux-distros nhằm cung cấp thông tin chính xác, và không được sử dụng trên các hệ thống không được phép

Bài viết liên quan

1 bình luận

 
GN⁺ 1 giờ trước
Ý kiến trên Lobste.rs

  • Đúng là một tuần quá dữ dội nếu phải quản trị máy chủ Linux dùng chung. Dù vậy, lần công bố này nói thẳng ngay vào trọng tâm nên cũng đáng khen
    Nhưng tôi không hiểu vì sao trong hướng dẫn giảm thiểu ai cũng che stderr đi
    Sửa: cái này được báo cáo vào ngày 30 tháng 4 sau khi lấy “cảm hứng” từ copy.fail, vậy là bị phát hiện chưa đầy một ngày sau đó sao? Ấn tượng thật
    Với tư cách là người có quyền sudo trên một máy chủ dùng chung khá lớn, tôi cũng tự hỏi liệu tự biên dịch kernel với số module ít nhất có thể có phải là ý hay không. Tôi chưa cân nhắc kỹ ưu nhược điểm, nhưng có vẻ như như vậy đã có thể tránh được cả hai lỗ hổng leo thang đặc quyền cục bộ trong tuần này
    Sửa 2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    Ồ, cái này không cần setuid. Thật tốt khi họ đã đưa nó vào

    • Tôi đang làm vậy trên hệ thống nhiều người dùng mà mình duy trì, và thực tế đã tránh được cả hai exploit root cục bộ trong tuần này

  • Liệu có khả thi và hợp lý không nếu lấy danh sách module kernel đang được nạp trên một hệ thống đang chạy rồi dùng nó làm danh sách cho phép của modprobe cho chính hệ thống đó?
    Cả CopyFail lẫn DirtyFrag đều có vẻ khai thác các module kernel không được nạp trên bất kỳ hệ thống nào tôi đã kiểm tra. Nếu vậy thì việc chặn các module rõ ràng là không cần thiết có thể giúp giảm thiểu trước một số cuộc tấn công chăng?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    Tôi không hiểu sao chuyện này lại có thể xảy ra. Việc thông tin ở quy mô như thế này lại nằm trong một môi trường khó có thể tin cậy như vậy thật sự quá vô lý

    • Tôi không chắc câu “một bên thứ ba không liên quan đã công bố” có phải đang nói đến trường hợp này không, nhưng để tham khảo thì Brad Spengler đã nhìn vào commit vá lỗi được đẩy lên trước và nhận ra lỗ hổng bảo mật được ám chỉ trong thông điệp commit, rồi trong phần trả lời có người dùng vibe coding để tạo exploit
      Bất kỳ bên thứ ba nào theo dõi các commit của Linux cũng có thể đã lần ra cùng những manh mối đó và tạo được exploit
    • Cách diễn đạt “bên thứ ba không liên quan” nghe như thể họ không biết bug đó đang trong thời gian embargo
      “Môi trường khó có thể tin cậy” ở đây là toàn bộ Internet, và thực tế gần như chẳng có gì có thể gọi là cách ly cả. Vốn dĩ trước giờ đã vậy, chỉ là bây giờ điều đó rõ ràng hơn thôi. Bài viết gần đây của Stefan Eissing về việc lỗi Apache httpd bị tái phát hiện đến hai lần trước khi được vá cũng đáng đọc

  • Có cách nào để kiểm tra xem các module bị ảnh hưởng có thực sự không thể được nạp hay không?
    Lần CopyFail trước tôi đã mắc lỗi khi áp dụng biện pháp giảm thiểu ban đầu. Tên tệp trong /etc/modprobe.d/ của tôi không kết thúc bằng .conf, và tôi không nhận ra điều đó cho đến khi chạy lệnh kiểm tra ở https://news.ycombinator.com/item?id=47954159. Có lệnh tương tự nào cho các module esp4/esp6/rxrpc không?

    • Tôi đã thử nạp cả ba module bằng modprobe và gặp cùng lỗi như lần trước
      Cũng có đoạn mã chứng minh khái niệm được đính kèm, nhưng tôi vẫn chưa thử nó