Lỗ hổng kernel Linux không được báo trước cho các bản phân phối

 (openwall.com)
1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • CopyFail, một lỗ hổng leo thang đặc quyền cục bộ của kernel Linux, thuộc nhóm nghiêm trọng nhất trong số các lỗ hổng kernel kiểu “make-me-root” gần đây
  • Vấn đề được đưa vào từ commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 của 4.14 và đã được sửa trong 6.18.22, 6.19.12, 7.0
  • 6.19.12 và 6.18.22 đã bao gồm bản backport bản vá vào ngày 11 tháng 4, nhưng các nhánh Longterm 6.12, 6.6, 6.1, 5.15, 5.10 khi đó chưa nhận được bản sửa
  • Bản vá không clean apply trên các kernel cũ, và trong tình huống cần phát hành ngay, bản vá vô hiệu hóa module authencesn của IPSec có thể được dùng làm biện pháp tạm thời
  • Lỗ hổng kernel Linux sẽ không được báo trước cho các bản phân phối trừ khi người báo cáo đưa nó lên linux-distros ML, và trong trường hợp này cũng không có heads-up nào

Phạm vi ảnh hưởng và trạng thái khắc phục của CVE-2026-31431

  • CopyFail là một lỗ hổng leo thang đặc quyền cục bộ của kernel Linux và thuộc nhóm nghiêm trọng nhất trong số các lỗ hổng kernel kiểu “make-me-root” gần đây
  • Vấn đề được đưa vào từ commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 của 4.14, và lần lượt được sửa trong 6.18.22, 6.19.12, 7.0
  • Commit sửa trong 6.18.22
  • Commit sửa trong 6.19.12
  • Commit sửa trong 7.0
  • 6.19.12 và 6.18.22 được phát hành vào ngày 11 tháng 4 với bản backport bản vá đã được đưa vào
  • Các nhánh Longterm 6.12, 6.6, 6.1, 5.15, 5.10 khi đó chưa có bản sửa, và cũng chưa thấy trong hàng đợi stable upstream
  • Nếu đây là vấn đề được đưa vào từ năm 2017, cần xác nhận liệu các kernel cũ hơn cũng bị ảnh hưởng hay không

Thông báo trước cho bản phân phối và biện pháp tạm thời

  • Bản vá này không clean apply trên các kernel cũ hơn
  • Đã thử backport trong tình huống cần phát hành ngay, nhưng do một số thay đổi API nên khó triển khai một cách chắc chắn
  • Có thể dùng bản vá vô hiệu hóa module authencesn của IPSec như biện pháp tạm thời, và ngay cả khi không phải chuyên gia IPSec thì đây vẫn gần như là “lựa chọn ít tệ hơn”
  • 0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch: bản vá vô hiệu hóa module authencesn để ứng phó CVE-2026-31431
  • Lỗ hổng kernel Linux sẽ không được báo trước cho các bản phân phối trừ khi người báo cáo đưa nó lên linux-distros ML
  • Trong trường hợp này, cũng không có heads-up nào thông qua linux-distros ML

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Hacker News

  • Sam James, tác giả của bài viết được liên kết, là một nhà phát triển Gentoo
    Dù sao thì chuyện này gần như là một thảm họa, và việc công bố exploit trước khi các bản phân phối kịp phát hành bản vá là cực kỳ vô trách nhiệm
    Không thể biết đã có bao nhiêu nhà cung cấp shared hosting bị tấn công vì việc này
    Tôi cũng lo ngại vì có vẻ không hề có sự liên lạc giữa kernel security team và các maintainer của bản phân phối
    Người ta dễ cho rằng bên trước sẽ thông báo cho bên sau, nhưng trên thực tế lại có vẻ như người phát hiện lỗ hổng mới là người phải chịu trách nhiệm đó

    • Tôi không thấy vấn đề gì với chuyện công khai sau 30 ngày kể từ khi bên được báo cáo đã có bản vá
      Tham khảo thêm, Google Project Zero cũng dùng chính sách tương tự kiểu “90+30”: https://projectzero.google/vulnerability-disclosure-policy.h...
      Vấn đề thực sự là không có kênh liên lạc nào giữa kernel security team và maintainer của các bản phân phối
      Người phát hiện lỗ hổng không nên phải chịu trách nhiệm báo riêng cho mọi downstream
      Đội kernel lẽ ra phải thông báo cho danh sách phụ trách bảo mật của các bản phân phối về mức độ nghiêm trọng của bản vá và lịch công khai sau 30 ngày
    • Lần công bố này nghe giống marketing hơn là bảo mật
      Ngay trên trang công bố cũng có những câu như “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]”
      Đây là kiểu làm khiến sản phẩm trông hấp dẫn hơn khi tình hình càng hỗn loạn
    • Với tư cách vừa là người dùng vừa là quản trị viên, tôi không đồng ý với nhận định là “cực kỳ vô trách nhiệm”
      Cụm từ Responsible Disclosure cũng giống “Secure Boot”, là một cách diễn đạt được thiết kế rất khéo về mặt ngôn ngữ, nhưng trên thực tế lại có vẻ phục vụ việc quản lý danh tiếng của các tổ chức trung gian như công ty hay quỹ đứng giữa tôi và máy tính của tôi
      Họ quan tâm đến việc ngăn người ta nói “RHEL có lỗ hổng”, “Ubuntu có lỗ hổng” hơn là việc từng máy tính của tôi có đang dễ bị tấn công hay không
      Lỗ hổng thì dù sao vẫn tồn tại, nên tôi cho rằng biết về rủi ro và có cơ hội giảm thiểu nó vẫn tốt hơn là chỉ ngồi chờ nó được vá trong im lặng
      Nói cách khác, tôi nghĩ chỉ có công khai ngay lập tức mới là lựa chọn không vô trách nhiệm
    • Bỏ qua lập trường về chính quy trình công bố, nếu có hosting provider nào bị hack vì chuyện này thì cấu trúc của họ vốn dĩ đã là kiểu sớm muộn cũng thua
      Chạy các tenant workload không tin cậy lẫn nhau dưới một shared kernel duy nhất là không ổn
      Kernel LPE không phải chuyện hiếm, và vụ này chỉ đặc biệt ở chỗ nó đơn giản và dễ port, còn primitive capability của nó thì gần như đã là hàng CNE commodity
    • Linux kernel không phù hợp để dùng làm ranh giới bảo mật
      Nếu làm shared hosting mà không muốn bị hack thì nên dùng các biện pháp khác như gVisor hoặc Firecracker VM
      Hệ thống quan trọng hiếm hoi dùng nó như ranh giới bảo mật là Android, nhưng được giảm thiểu nhờ việc cài APK cần sự chấp thuận của người dùng, cùng các chính sách SELinux và seccomp nghiêm ngặt, cũng như hardening của GrapheneOS
      Trong trường hợp này việc giảm thiểu cũng đã thành công: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

  • Tôi không hiểu tại sao người ta lại nói kiểu “với lỗ hổng Linux kernel thì các bản phân phối sẽ không được báo trước trừ khi reporter tự mang nó lên linux-distros ML”
    Việc reporter phải tự điều phối trực tiếp với các bản phân phối giả định rằng họ có kiến thức rất sâu về dự án Linux
    Người báo cáo lỗ hổng không nên có trách nhiệm phải làm việc trực tiếp với mọi bên tiêu thụ downstream của Linux kernel
    Nếu thế thì chẳng lẽ còn phải liên hệ trực tiếp với mọi nhà sản xuất dùng Linux trong thiết bị của họ nữa sao
    Tôi cho rằng chỉ cần báo cáo có trách nhiệm cho Linux và chờ đến khi có bản vá là người báo cáo đã làm đủ phần việc của mình rồi
    Trong nội bộ dự án Linux phải có những người có thẩm quyền và trách nhiệm với các lỗ hổng bảo mật, và việc thông báo cho các distro downstream cũng nên là do họ làm

    • Điều này càng đúng hơn khi họ còn yêu cầu rõ ràng rằng reporter đừng thông báo trước cho đội của các bản phân phối
      https://docs.kernel.org/process/security-bugs.html
      As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
    • Reporter vẫn có thời gian để vào website của mình kiểm tra và nêu đích danh các bản phân phối cụ thể như Ubuntu/RHEL/SUSE
      Ít nhất thì thông báo cho đội bảo mật của các bản phân phối đó có lẽ mới là hành động có trách nhiệm
    • Thật khó coi là hợp lý khi reporter đã dựng cả một website nêu đích danh Ubuntu, RedHat, Amazon và SUSE nhưng lại không thông báo cho họ
      Cũng khó tin là họ không biết các bản phân phối đó là downstream của đội kernel
    • Có thể đó không phải yêu cầu bắt buộc, nhưng tôi nghĩ mọi người đã phải khổ hơn vì các reporter quan tâm đến danh tiếng hơn là khắc phục an toàn
    • Tìm cách báo cáo loại vấn đề bảo mật này cho các Linux distro là chuyện cực kỳ dễ
      Chỉ cần Google là ra: https://share.google/aimode/eihDKXZJy94Z5lC1p
      Khó mà hiểu nổi việc không nghĩ đến điều đó rồi để mọi người đều bị phơi ra trước exploit, và ở một số khu vực pháp lý thì chuyện này bị xem là trọng tội cũng không có gì lạ

  • Trao đổi thú vị nhất liên quan đến disclosure nằm ở liên kết này
    https://www.openwall.com/lists/oss-security/2026/05/01/3
    Đây là câu trả lời của greg k-h: “chúng tôi không thể báo trước cho bất kỳ ai, vì nếu làm thế thì phải báo cho tất cả mọi người về mọi thứ. Đó là chính sách duy nhất mà các cơ quan pháp luật và chính phủ chấp nhận để chúng tôi có thể vận hành, nên không còn cách nào khác”

    • Tôi thích Linux, nhưng tôi cho rằng đây là một chính sách ngớ ngẩn

  • Thay vì tiếp tục đổ lỗi cho reporter, nên yêu cầu sửa lại quy trình của kernel
    Linux kernel không còn là một dự án đồ chơi nữa, và có nhiều nhân viên làm full-time được các công ty trả lương
    Việc thông báo cho các bản phân phối lẽ ra phải do họ xử lý, chứ không phải một cá nhân bất kỳ

    • Nếu trong một bài blog mang tính công bố, thực chất gần như là marketing, họ đã nêu đích danh một số distro là bị ảnh hưởng, thì việc gửi heads-up trước khi công khai là điều phù hợp và đáng được kỳ vọng
      Nếu họ không đưa những câu như RHEL 14 vào đó thì có lẽ đã không bị chỉ trích đến mức này
      Đây không phải tình huống của một nhà nghiên cứu bảo mật cá nhân hay giới học thuật, mà là một công ty bảo mật có bộ phận truyền thông chuyên nghiệp đang chĩa ngón tay vào các distro maintainer
    • Đúng là các bản phân phối và các nhà phát triển kernel phải trao đổi về những bản vá mức độ nghiêm trọng cao và hành động nhanh chóng
      Nhưng vì reporter đã không chờ việc đó xảy ra nên có thể đã có người thật sự bị thiệt hại, và trách nhiệm đó thuộc về reporter
    • Báo cáo một lỗ hổng và công khai một exploit mạnh mà bất kỳ ai cũng có thể đem dùng là hai chuyện hoàn toàn khác nhau
      Thả nó ra cho cả thế giới mà không báo trước cho các distro lớn là vô trách nhiệm

  • Đã có một workaround dựa trên eBPF dành cho những ai đang dùng kernel mà AF_ALG được liên kết trực tiếp vào kernel chứ không phải dưới dạng module: https://github.com/Dabbleam/CVE-2026-31431-mitigation
    Tôi đang chạy nó trên production ngay lúc này và nó đang giảm thiểu cuộc tấn công, đến giờ chưa thấy tác dụng phụ ngoài dự kiến nào

  • Tôi cho rằng nosuid và có lẽ cả nodev nên là các filesystem mount option mặc định
    /dev vốn đã là một devtmpfs đặc biệt, còn /dev tối thiểu của initrd nếu cần thì có thể mount rootfs tmpfs của initrd với dev và suid một cách tường minh
    Việc để SUID binary có thể “tồn tại” ở bất kỳ đâu là một rủi ro bảo mật lớn
    Khi mount thiết bị lưu trữ ngoài thì làm sao xác minh được các SUID binary trong block device đó không phải là mã độc
    Hơn nữa, exploit này có vẻ còn yêu cầu người chạy SUID binary cũng phải có quyền đọc binary đó thì mới hoạt động được
    Không có lý do gì để người dùng không phải root lại có quyền đọc một SUID binary
    NixOS xử lý chuyện này đúng cách
    Trong /nix/store, thư mục cài gói thông thường, không có SUID và vì các gói không rò rỉ ra ngoài nên có thể an toàn dùng nosuid cho các mountpoint khác
    Ngoại lệ duy nhất là thư mục /run/wrappers.$hash với mục đích đơn lẻ là chứa các executable-only SUID wrapper một cách an toàn

    • Tôi cũng ghét suid, nhưng ở đây suid không phải vấn đề cốt lõi
      Lỗi bị exploit thực chất cho phép gần như đầu độc page cache tùy ý
      Đến thời điểm đó thì coi như ván đã xong, và vá các chương trình suid có thể là cách dễ nhất để lấy root shell chứ không phải cách duy nhất
    • Proof of concept exploit theo đúng nghĩa đen chỉ là để minh họa một vector tấn công cụ thể
      Còn rất nhiều cách khác
      Nếu mục tiêu chỉ là chặn exploit minh họa thì các cách dễ hơn như blacklist cũng làm được, nhưng điều đó không khiến hệ thống an toàn hơn
      Lỗ hổng này cho phép thao túng page cache
      Có thể thao túng ld.so để gắn hook vào system call tùy ý, đổi uid thành 0, hoặc leo thang đặc quyền bằng nhiều cách khác
      Mount point không liên quan đến vấn đề này
      Dĩ nhiên chặn suid ở vùng người dùng có thể ghi và chặn đọc file suid vẫn luôn là ý hay, nhưng đó là vì lý do khác
      NixOS cũng không vá được lỗ hổng này và vẫn dễ bị ảnh hưởng như các bản phân phối khác
    • Không có quyền đọc thì không thể thực thi binary, điều đó không hợp lý
      Muốn chạy binary thì phải đọc nó từ đĩa và nạp vào bộ nhớ
      Trên thực tế, nếu một binary có quyền đọc nhưng không có quyền thực thi thì vẫn có thể gọi trực tiếp linker để chạy nó
      Ví dụ gọi /bin/ld.so.1 /path/to/binary thì linker sẽ đọc và nạp binary rồi nhảy vào entry point mà không cần gọi exec()

  • Liên kết Bleeping Computer dưới đây có nêu các biện pháp đối phó tiềm năng cho đến khi bản vá sẵn sàng
    https://www.bleepingcomputer.com/news/security/new-linux-cop...

    • Workaround này chỉ áp dụng cho kernel mà phần mã bị ảnh hưởng được biên dịch dưới dạng module
      RHEL, Fedora và Gentoo đều được cấu hình để build phần mã đó trực tiếp vào kernel
      Nếu không có bản vá hoặc thay đổi cấu hình thì, như Sam đã ám chỉ về Gentoo, các bản phân phối đó sẽ vẫn dễ bị ảnh hưởng
    • Trên RedHat và các bản phân phối phái sinh của nó, phần mã bị ảnh hưởng không phải module mà được biên dịch tĩnh, nên biện pháp này không hoạt động

  • NixOS cũng không nhận được cảnh báo trước
    https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

    • Không có bản phân phối nào nhận được cảnh báo trước

  • Hyperbola GNU an toàn vì vẫn dùng Python 3.8 do lý do chính trị và tính ổn định

  • Ubuntu đã phát hành bản vá và việc kiểm thử trước/sau bản vá cũng đã hoàn tất