Các gói AUR bị lây nhiễm infostealer và rootkit

• Kho gói AUR là nơi các gói không được quản lý có thể được bất kỳ ai nhận nuôi và gửi thay đổi cho PKGBUILD cùng các tệp liên quan; trong sự cố lần này có dấu hiệu hơn 408 gói đã bị lây nhiễm
• Một maintainer gói AUR mới đã mạo danh maintainer đáng tin cậy để nhận nuôi các gói, và các maintainer AUR khác đang tiến hành loại bỏ các gói bị nhiễm
• Các gói bị nhiễm ban đầu đã bị sửa để chạy npm trong script preinstall nhằm cài payload độc hại atomic-lockfile
• Các đợt lây nhiễm sau đó đã dùng Bun để cài js-digest độc hại, và NPM đã gỡ gói này
• Phần lớn các gói ít được dùng, nhưng điều quan trọng là phạm vi ảnh hưởng lớn và đây là một cuộc tấn công chuỗi cung ứng có cả hành vi đánh cắp thông tin lẫn eBPF rootkit

---

Tình hình sự cố

• Đã xảy ra chuyện gì

  • Có dấu hiệu một maintainer gói AUR mới đã mạo danh maintainer đáng tin cậy để nhận nuôi và lây nhiễm hơn 408 gói
  • Sau khi vụ xâm phạm được báo cáo, các maintainer AUR khác đã tiến hành gỡ bỏ các gói bị nhiễm
  • Tính đến 2026-06-12T17:30:00Z, các maintainer AUR báo cáo đã loại bỏ mọi commit độc hại
  • Các maintainer AUR quyết định áp dụng kiểm soát và hạn chế đối với một số tính năng, bao gồm cả chức năng nhận nuôi gói
  • Arch Linux đã đăng thông báo Active AUR malicious packages incident

• Phụ thuộc độc hại

  • Cuộc tấn công bao gồm ít nhất hai phụ thuộc độc hại riêng biệt
  • Các gói bị ảnh hưởng ban đầu đã bị sửa để dùng npm trong script preinstall nhằm cài gói payload độc hại atomic-lockfile
  • Gói premake-git có commit ví dụ cho thay đổi này
  • Các đợt lây nhiễm sau đó dùng Bun để cài js-digest độc hại, và NPM đã gỡ js-digest
  • Phân tích cuộc tấn công có trong Preliminary analysis of AUR malware

Ứng phó và chỉ dấu xâm phạm

• Biện pháp được khuyến nghị

  • Nếu không dùng Arch, bạn không phải đối tượng bị ảnh hưởng trực tiếp bởi vụ xâm phạm gói AUR lần này
  • Người dùng Arch nên xem lại danh sách các gói bị ảnh hưởng và kiểm tra hệ thống bằng script xác minh mức độ phơi nhiễm
  • aur_check.sh được liên kết trong bài gốc là phiên bản cũ; mục kiểm tra mới nhất cần làm theo hướng dẫn trong Gist tương ứng
  • Nếu phát hiện chỉ dấu xâm phạm, cần bảo toàn hệ thống để phục vụ điều tra pháp chứng phù hợp
  • Nếu tìm thấy gói bị nhiễm, cần làm theo quy trình ứng phó sự cố thông thường, thay toàn bộ thông tin xác thực và cân nhắc cài lại Arch
  • Do khả năng có rootkit, không thể đảm bảo độ tin cậy của hệ thống nữa
  • Tất cả người dùng nên chặn lưu lượng Tor đi ra khỏi mạng

• Chỉ dấu xâm phạm

  • SHA256 của tệp thực thi Linux độc hại được nhúng trong js-digest là 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
  • Có thể phát hiện eBPF Maps đáng ngờ bằng bpftool map list
  • Các tên map đáng ngờ gồm hidden_pids, hidden_names, hidden_inodes

• Các điểm xác nhận thêm

  • Không phải các tài khoản maintainer hiện có đã thực hiện commit độc hại; thay vào đó, các tài khoản maintainer đã biết đã bị mạo danh
  • Phần lớn các gói ít được dùng, nhưng phạm vi lây nhiễm hơn 408 gói là rất lớn
  • Một cuộc tấn công chuỗi cung ứng có cả hành vi đánh cắp thông tin lẫn eBPF rootkit là trường hợp hiếm gặp
  • Trang atomic-lockfile trên Socket.dev hiển thị số lượt tải của gói NPM độc hại là 134
  • Gói NPM này do người dùng herbsobering duy trì
  • Tìm kiếm tên người dùng herbsobering trên GitHub cho thấy có một image container đơn lẻ trông như công cụ reverse shell/proxy là herbsobering430
  • Kho gói AUR cho phép bất kỳ ai nhận nuôi một gói khi gói đó được đánh dấu là không được quản lý, rồi gửi thay đổi cho PKGBUILD và các tệp liên quan
  • Việc tự động tìm và nhận nuôi các gói bị bỏ rơi không phải là chuyện hiếm; bối cảnh liên quan có trong chuỗi Mastodon

[GN⁺]

Ý kiến trên Hacker News

• Cần chấp nhận rằng AUR chỉ là một bộ sưu tập các PKGBUILD do người dùng tạo ra
  Bạn bắt buộc phải tự xem xét mã nguồn của mọi PKGBUILD cài từ AUR, và các bản cập nhật cũng không ngoại lệ. Đây là tiền đề đã được bàn đi bàn lại hơn 10 năm nay, và cũng là lý do không có một AUR helper chính thức nào như yay
  Có nhiều lời phàn nàn rằng Arch Linux mang tính tinh hoa, nhưng thực tế đây là một bản phân phối dành cho những người biết mình đang làm gì và không muốn được cầm tay chỉ việc ở từng bước. Điều đó cũng có nghĩa là nếu bạn cài ngẫu nhiên các gói AUR rồi làm hỏng hoặc để hệ thống bị xâm nhập, thì trách nhiệm thuộc về bạn
  Tuy vậy, thời kỳ để bất kỳ ai cũng có thể tiếp quản một gói AUR có lẽ sắp kết thúc. Chỉ riêng chi phí hoàn tác các gói bị ảnh hưởng mỗi lần xảy ra sự cố đã là quá lớn. Còn phương án xem xét mọi yêu cầu tiếp quản thì quá tốn công, và cũng không đảm bảo lúc nào cũng hữu ích

  • Nếu phải xem xét mã nguồn của mọi PKGBUILD cài từ AUR, thì điều đó chẳng phải cũng áp dụng tương tự với tiện ích mở rộng trình duyệt, tiện ích mở rộng VSCode, gói NuGet, crate Cargo, gói Python, gói npm, v.v. sao
    Tôi nghĩ là đúng, trừ khi bạn chỉ chạy chúng ở nơi không có truy cập Internet hoặc chỉ được phép truy cập những thứ không cần giữ kín dù có bị công khai
    Có thể không phải AUR, nhưng các hệ sinh thái khác về mặt lý thuyết có thể được cải thiện bằng mô hình quyền hạn hoặc sandbox. Tiện ích mở rộng trình duyệt đã có các lựa chọn như vậy, nhưng người dùng “bình thường” hầu như không dùng
    Đáng tiếc là 99,99% mọi người không thể hoặc không có thời gian để xem xét tất cả mọi thứ. Các gói của bản phân phối với maintainer đáng tin cậy, hoặc những nơi có quyền hạn và mức độ kiểm duyệt nhất định như iOS App Store, có vẻ là an toàn nhất
  • Tôi không nghĩ đây thực sự là lời giải. Mô hình tấn công phổ biến kiểu này vốn là giấu payload ở đâu đó trong phụ thuộc
    Vụ này hơi khác ở chỗ họ khá cẩu thả khi chỉ npm install ngay trong PKGBUILD. Giờ thì gần như mọi kho gói ngoài AUR cũng gặp cùng vấn đề này, và việc tự kiểm toán toàn bộ chuỗi phụ thuộc là không thực tế
    Tất nhiên tôi cũng không có giải pháp
  • Tin rằng dù chỉ một phần rất nhỏ người dùng thực sự làm chuyện này cũng là một suy nghĩ xa rời thực tế nghiêm trọng
  • Tôi không rõ việc AUR là tập hợp PKGBUILD do người dùng tạo ra khác hệ sinh thái PyPI, npm hay toàn bộ Docker Hub đến mức nào
    Mọi người tắt SELinux, --privileged thì vô hiệu hóa seccomp và AppArmor, và các CVE thoát sandbox cũng tồn tại
  • Việc bất kỳ ai cũng có thể tiếp quản gói AUR lẽ ra ngay từ đầu đã không nên tồn tại
    Cuối cùng tôi muốn nó trở thành cấu trúc như username/packagename-bin|git. Như vậy sẽ rõ ràng hơn nhiều về việc mọi người thực sự đang cài cái gì và từ ai

• Chiến dịch này vẫn đang diễn ra. Tôi vừa nhận được email báo rằng một gói cũ của mình đã bị tiếp quản; nó đã không hoạt động suốt nhiều năm và cũng là gói mồ côi từ lâu. Ngay sau khi bị tiếp quản, một commit độc hại đã được đẩy lên
  Có vẻ giờ họ dùng bun thay vì npm, nên các cách né tránh dựa trên npm có thể sẽ không còn hiệu quả
  https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

  • Đến mức này thì tôi tự hỏi liệu chính khái niệm tiếp quản gói mồ côi có phải đã hỏng hoàn toàn không, và có nên bị loại bỏ hẳn không
    Dù sẽ bất tiện, nhưng có lẽ tốt hơn là AUR buộc phải gửi mới thay vì cho phép tiếp quản gói mà người khác đã bỏ, rồi định kỳ xóa các gói mồ côi sau một khoảng thời gian nhất định
  • Tôi cũng vừa nhận được thông báo rằng một gói AUR tôi đang theo dõi đã bị chuyển cho một người lạ chỉ vì nó là gói mồ côi

• Rõ ràng là phải cẩn thận khi cài thứ gì đó từ AUR, và trước đây cũng luôn có những gói đáng ngờ, tức là được build sai hoặc đóng gói sai, nhưng việc thấy hành vi cài cắm mã độc chủ động là điều đáng lo ngại
  Tôi nghĩ AUR có hai vấn đề lớn. Thứ nhất, nó là tàn dư của một thời kỳ mã nguồn mở bình đẳng hơn, khi người ta phần lớn còn có thể tin mã của bên thứ ba. Thứ hai, bất kỳ ai cũng có thể tiếp quản các gói mồ côi mà vẫn giữ nguyên lịch sử và dấu vết xác minh sẵn có
  Thời kỳ đầu tiên đã qua rồi, còn vấn đề thứ hai có thể được giảm nhẹ bằng cách kiểm soát chặt hơn tài khoản AUR hoặc thêm cơ chế bảo vệ trong các AUR helper. Ví dụ, nếu một gói vừa đổi chủ gần đây thì hiển thị một cảnh báo thật lớn và đáng sợ. Dĩ nhiên vẫn sẽ có người cứ bấm y cho qua, nhưng còn hơn là không có gì
  Hoặc cũng có thể tránh hẳn AUR helper và tự xem xét PKGBUILD rồi build gói mình cần

  • Chính sách tiếp quản gói chưa từng hợp lý ở bất kỳ thời điểm nào
  • Theo tôi, AUR helper ngược lại còn giúp tích hợp bước xem xét vào quy trình làm việc dễ hơn
    Chúng chủ động hỏi bạn có muốn xem xét không, và sau khi bạn chấp nhận rủi ro cuối cùng, chúng còn cho biết liệu đã có thay đổi nào không
    Dù vậy, quan điểm “AUR có hại” không phải là mới. Người dùng AUR cần hiểu rủi ro ở đây, và về cơ bản nó chỉ khá hơn một bậc so với việc lấy thứ gì đó trên StackOverflow rồi curl | bash thôi

• Chuyện này đã trôi qua hơn 7 tiếng mà vẫn chưa có bất kỳ đề cập nào trên archlinux.org hay aur.archlinux.org. Tôi không hiểu vì sao. Đáng lẽ phải chặn AUR cho đến khi có biện pháp chứng minh rằng người dùng đã biết về vụ việc này
  Ví dụ, có thể chỉnh nhẹ URL API của AUR để người dùng yay/yaourt phải đi tìm xem đã xảy ra chuyện gì. API mới cần có hạ tầng để thông báo cho người dùng và xác nhận họ đã đọc thông báo trước khi tiếp tục. Điều này càng cần thiết hơn khi thậm chí còn chưa chắc đã tìm ra hết toàn bộ mã độc
  Ngoài ra cũng cần có cơ sở dữ liệu về các commit AUR đã bị thu hồi hoặc bị xâm phạm, cùng cơ chế cảnh báo nếu người dùng từng cài các gói đó

  • Dù tốt hay xấu thì cảnh báo này luôn tồn tại trên AUR
    Nó nằm ngay trong chính cái tên, và tài liệu wiki cũng nói rất rõ AUR là kho của người dùng, không nên mù quáng tin tưởng
    Ngay trong khung đỏ to ở phần đầu đã viết nguyên văn điều đó: https://wiki.archlinux.org/title/Arch_User_Repository
    Có rất nhiều thứ trên AUR mà tôi sẽ không bao giờ cài, và tôi không nghĩ cách tốt nhất là phát tán tất cả chúng lên mailing list
    Tôi không ghét ý tưởng cảnh báo những người đã cài gói độc hại, nhưng khả năng triển khai rất thấp. AUR không có cơ chế theo dõi cài đặt như các công cụ thương mại. Làm sao biết được ai đã cài gói nào? Về cơ bản AUR gần giống như danh bạ vị trí gói, và thậm chí còn không yêu cầu đăng nhập hay thông tin xác thực
    Vì vậy cảnh báo phải đến từ các công cụ mà người dùng có thể chạy nếu họ chịu chú ý, và thực tế là họ cần phải chú ý. Ví dụ: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
  • Không nên làm vậy. Chỉ vì một số người không nghiêm túc với khuyến nghị bảo mật cơ bản mà không thể phá vỡ quy trình làm việc của mọi người
    Cái API mới vừa thông báo vừa bắt người dùng xác nhận đã đọc thì rốt cuộc phải hoạt động thế nào? Gói AUR đơn thuần là các kho git, và những gì AUR helper làm hay không làm thì maintainer của Arch không thể kiểm soát được
  • Tôi nghĩ nên có thông báo trên trang đầu của AUR. Cá nhân tôi thấy một hướng dẫn ngắn trên trang chủ Arch cùng liên kết đến thông báo ở trang AUR cũng sẽ hữu ích
    Nếu không muốn liệt kê toàn bộ các gói bị ảnh hưởng đã biết, thì ít nhất cũng nên khuyến nghị như một lập trường chính thức rằng ai dùng gói AUR phải đọc mọi tệp của mọi gói mình sử dụng
  • Giờ thì đã có thông báo: https://archlinux.org/news/active-aur-malicious-packages-inc...
  • Nếu có thể tin các con số từ Socket.dev thì may là mức độ ảnh hưởng có vẻ khá nhỏ
    Điều đó cũng có lý. Tôi biết một số gói trong danh sách bị ảnh hưởng, chúng đã quá cũ và cả dự án upstream cũng không còn được duy trì nữa
    Tôi không biết tổng số nạn nhân là bao nhiêu, nhưng có khả năng cao đội AUR có con số chính xác. Tôi nghĩ họ đang xử lý hết sức có thể tương xứng với mức độ ảnh hưởng

• Kiểu sự việc này rốt cuộc đã trở nên không thể tránh khỏi, và nếu không có thay đổi thì có lẽ sẽ xảy ra thường xuyên hơn. Tôi rất thích hệ thống PKGBUILD của AUR, và cũng hay tận dụng nó khi tự viết gói
  Vấn đề nghiêm trọng nhất mà cũng dễ sửa nhất là bất kỳ ai cũng có thể tiếp quản một gói mồ côi, nhưng người dùng cuối hoàn toàn không được báo về việc đó
  Xóa gói thì công nhiều mà lợi ít, nên cách tối ưu để buông quyền kiểm soát lại là biến nó thành gói mồ côi. Tôi nghĩ điều này phải ngược lại. Ít nhất người dùng phải được biết rõ rằng gói đó đã trở thành gói mồ côi
  Gánh nặng này có thể nằm nhiều hơn ở phía các AUR helper như paru hay yay, và tôi khuyến khích họ thực hiện thay đổi đó

• Có một script đơn giản để quét các gói đã bị xâm phạm
  https://cscs.pastes.sh/aurvulntest20260611.sh
  Không phải script của tôi, nhưng khá dễ đọc và dễ hiểu. Tuyệt đối đừng pipe thẳng script vào bash

  • Cũng có phương án nhanh hơn
    comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
    Không bao giờ là thời điểm tệ để học comm(1)
  • Cách này chỉ kiểm tra gói có được cài hay không, chứ không kiểm tra phiên bản đã cài có bị nhiễm hay không
    Chắc là nếu giống tôi, đã một thời gian, vài tháng rồi chưa chạy yay -Syu, thì có lẽ vẫn ổn nhỉ? …nhỉ?
    Làm ơn đừng bắt tôi phải cài lại Arch. Lần trước mất cả tuần
    Cập nhật: archinstall ổn đấy. Khôi phục lại trong khoảng 15 phút
  • Không có gì đảm bảo danh sách đó là đầy đủ
    Lúc nào cũng phải kiểm tra PKGBUILD và mã nguồn. Nhìn chung AUR không phải thứ để tin cậy. Thậm chí còn ngạc nhiên hơn là kiểu vụ xâm phạm này lại không xảy ra sớm hơn
  • pacman hỗ trợ locale ngày tháng, nên cách tìm 9 Jun chỉ hoạt động với locale tiếng Anh hoặc các locale dùng định dạng tương tự
    Sau khi chỉnh cho phù hợp với môi trường của tôi thì jd-gui bị phát hiện, nhưng thực ra tôi đã cài jd-gui-bin khoảng hai tiếng trước khi vụ xâm phạm xảy ra. Có vẻ tôi đã gặp may vì tối hôm đó lười chờ biên dịch từ mã nguồn nên chọn gói -bin

• Cộng đồng Arch đang nhanh chóng đưa ra các script và công cụ.
  Hiện tại, tiện ích tích hợp mới nhất để kiểm tra xem có bị lây nhiễm hay không là cái này:
  https://github.com/lenucksi/aur-malware-check
  Ngoài ra, trên danh sách thư aur-request cũng đang có rất nhiều yêu cầu xóa và chuyển thành gói mồ côi để hoàn tác các commit độc hại:
  https://lists.archlinux.org/archives/list/aur-requests@lists...

  • Câu hỏi hơi ngớ ngẩn một chút, nhưng vì đây không phải thứ do Arch hay nguồn chính thức phát hành, làm sao biết nó đáng tin?
    Trong script đó có khá nhiều phần khó hiểu, nên chỉ đọc code thôi cũng không dễ đánh giá là có an toàn hay không.
    Tôi vẫn mong chờ phản hồi hoặc giải pháp từ phía các nhà phát triển Arch chính thức.
  • Tôi thích biểu đồ sao ở phía dưới README của kho lưu trữ.
    Nó truyền tải rất rõ cảm giác cấp bách và mức độ nghiêm trọng gắn với một cuộc tấn công malware quy mô lớn như thế này.

• Tôi nhớ khoảng 10 năm trước từng cài Mednafen, một trình giả lập, trên Arch Linux. Chương trình không chạy được vì nó được liên kết với một thư viện không có trên hệ thống của tôi.
  Hóa ra maintainer đã build phần mềm trên hệ thống của chính họ, và một thư viện có sẵn trên máy đó đã được dùng nhưng không được ghi trong phần phụ thuộc.
  Đó là một gói được bảo trì chính thức, và tôi luôn nghĩ những thứ như vậy được tạo trên máy chủ build chuyên dụng chứ không phải trên máy tính ở nhà hay bởi tình nguyện viên ngẫu nhiên. Tôi không biết Arch hiện giờ còn build theo cách đó không, nhưng chuyện đó đủ đáng sợ để khiến tôi đổi bản phân phối.

  • Điều này vẫn có thể xảy ra ngay cả khi dùng pkgctl build. Trường hợp là makedepends= đã kéo một thư viện dùng chung vào môi trường build theo kiểu bắc cầu, nhưng nó lại bị thiếu trong depends=.
    Có cảnh báo khi phát hiện phụ thuộc .so, nhưng việc nhìn ra và xử lý nó vẫn là trách nhiệm của maintainer.
    Về mặt an toàn và bảo mật, Arch Linux là một trong những trụ cột dẫn dắt dự án reproducible builds, và phần lớn hệ điều hành có thể được xác minh độc lập xem các binary đó có thực sự được build từ mã nguồn hay không. Cơ chế kiểm toán cho các gói chính thức mạnh hơn NixOS và ở mức tương đương Debian:
    https://reproducible.archlinux.org/
    Tuy vậy, toàn bộ chuyện này hoàn toàn tách biệt với vụ AUR lần này.
  • Có những công cụ để bắt kiểu lỗi này bằng cách thử build và cài gói từ một image sạch. Ví dụ như pkgctl.
    Nếu là maintainer thì trước khi đăng lên nhất định phải dùng các công cụ như vậy.
  • Cho đến tương đối gần đây thì cách làm này vẫn rất phổ biến. Debian cũng vận hành như vậy trong thời gian dài, và mãi đến năm 2019 mới cấm hoàn toàn.

• Giải pháp cho vấn đề này là gì? Có phải nên cài những gói như thế này bên trong container Docker không có quyền truy cập mạng? Tôi không nghĩ có thể giả định chuyện này chỉ giới hạn ở AUR.
  Đến năm 2026 thì phải nghi ngờ mọi nguồn phần mềm. Đặc biệt là khi vibe coding đang lan rộng, còn phần mềm đóng thì là hộp đen nên còn hỗn loạn hơn cả mã nguồn mở.

  • Những “app store” không đáng tin như AUR, Flatpak, v.v. nên nằm trong sandbox. Ít nhất có vẻ cũng cần máy ảo như một tùy chọn, hoặc tốt hơn là mặc định.
  • Không muốn nói ra nhưng những người làm Qubes OS đã đúng. Giải pháp là cách ly ứng dụng một cách mạnh tay bằng máy ảo.
    Có ai biết nếu thực sự chuyển sang thì thời lượng pin sẽ tệ đến mức nào không?
  • Cần áp dụng SLSA.
  • Flatpak

• Đang có thêm tin tức liên quan xuất hiện.
  https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
  Tôi từng nghĩ đến ý tưởng tạo một binary canary mà khi chạy sẽ chỉ gửi email hoặc hiện thông báo, rồi đặt tên nó là npm.
  Ở thời điểm này, việc không đổi tên binary npm là một rủi ro lớn.