Các lỗ hổng nhân Linux không được thông báo trước cho các bản phân phối

 (openwall.com)
1 điểm bởi GN⁺ 2026-05-01 | 2 bình luận | Chia sẻ qua WhatsApp
  • CopyFail, một lỗ hổng leo thang đặc quyền cục bộ trong nhân Linux, được xếp vào nhóm nghiêm trọng nhất trong số các lỗ hổng “make-me-root” gần đây của nhân (biến người dùng thường thành root)
  • Lỗ hổng này được đưa vào từ một commit cụ thể của nhân phiên bản 4.14, trùng với thời điểm bổ sung tối ưu hóa in-place cho mô-đun authencesn mà CopyFail đã khai thác
  • Bản sửa đã được đưa vào nhân 6.18.22, 6.19.12, 7.0; trong đó 6.18.22 và 6.19.12 được phát hành vào ngày 11 tháng 4 với bản sửa đã được backport (áp dụng bản vá từ phiên bản cao hơn xuống phiên bản thấp hơn)
  • Tuy nhiên, các nhân Longterm vẫn còn được dùng rộng rãi (6.12, 6.6, 6.1, 5.15, 5.10) vẫn chưa bao gồm bản sửa này, và cũng chưa được xác nhận trong upstream stable queue
    • Vì vấn đề đã được đưa vào từ năm 2017, nên cần kiểm tra xem các nhân Longterm cũ này có nằm trong phạm vi bị ảnh hưởng hay không
  • Bản vá sửa lỗi này không thể clean apply (áp dụng gọn gàng mà không xung đột mã) lên các nhân cũ, và do một số thay đổi API, ngay cả khi thử backport cũng khó thực hiện một cách chắc chắn
  • Trong các môi trường cần ứng phó ngay, có thể áp dụng tạm thời bản vá vô hiệu hóa mô-đun authencesn của IPSec; ngay cả với người không phải chuyên gia IPSec, đây vẫn là “lựa chọn chưa hoàn hảo nhưng ít tệ hơn”
  • Nói cách khác, vấn đề mang tính cấu trúc nằm ở chính quy trình công bố lỗ hổng của nhân Linux:
    • Trừ khi người báo cáo lỗ hổng chủ động thông báo tới mailing list linux-distros (kênh riêng nơi các nhóm bảo mật của bản phân phối cùng tham gia), các bản phân phối sẽ không nhận được thông báo trước
    • Trong vụ CopyFail lần này cũng không có cảnh báo sớm (heads-up) nào được gửi qua linux-distros ML
    • Điều đó có nghĩa là các nhóm bảo mật của những bản phân phối lớn như Ubuntu, RHEL, SUSE đã không có cơ hội chuẩn bị bản vá trước khi lỗ hổng được công khai

Bài viết liên quan

2 bình luận

 
unsure4000 2026-05-02

Bài viết blog hơi có phần trẻ con, nhưng tôi nghĩ để đánh giá đó là lỗi vượt quá mức chỉ gây phản cảm thì những khiếm khuyết mang tính hệ thống có vẻ còn lớn hơn.
 
GN⁺ 2026-05-01
Ý 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