Arch Linux cho biết sự cố mã độc nay đã được kiểm soát: ảnh hưởng tới hơn 1.500 gói

 (phoronix.com/news)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong kho lưu trữ AUR do người dùng đóng góp của Arch Linux, sau khi ban đầu xác nhận hơn 400 gói bị nhiễm mã độc, con số cuối cùng đã tăng lên hơn 1.500 gói
  • Trong bản cập nhật vài giờ trước, các gói bị nhiễm trong sự cố tuần này được xác định là khoảng 900 gói
  • Sau đó, các nhà phát triển Arch Linux đã xóa toàn bộ các commit độc hại mà họ nhận biết được, và số gói bị ảnh hưởng được thống kê là 1.579
  • Danh sách 1.579 gói này cũng được ghi chú là danh sách gồm nhiều gói bị ảnh hưởng nhưng không phải toàn bộ, nên phạm vi thực tế có thể còn lớn hơn
  • Nhiều phần mềm trong kho lưu trữ do người dùng duy trì đã bị ảnh hưởng bởi sự cố bảo mật lần này, và trong một bản cập nhật riêng, một đợt tấn công mã độc tinh vi hơn lại tiếp tục xảy ra

Tổng quan sự cố

  • Sự cố bắt đầu khi hơn 400 gói bị nhiễm mã độc được phát hiện trong kho lưu trữ AUR do người dùng đóng góp dành cho người dùng Arch Linux
  • Vào cuối ngày, phía Arch Linux cho rằng tất cả các commit bị ảnh hưởng đã được xử lý, nhưng số gói bị ảnh hưởng đã tăng lên hơn 1.500
  • Đây là một sự cố bảo mật ảnh hưởng tới nhiều phần mềm trong kho lưu trữ Arch Linux do người dùng duy trì

Thay đổi về phạm vi ảnh hưởng

  • Trong bản cập nhật vài giờ trước, khoảng 900 gói được xác định đã bị nhiễm mã độc trong sự cố tuần này
  • Sau đó, theo thông điệp cuối cùng trong chủ đề về sự cố bảo mật, các nhà phát triển Arch Linux đã xóa toàn bộ các commit độc hại mà họ biết đến
  • Danh sách được trích dẫn cho biết số gói bị ảnh hưởng bởi mã độc là 1.579

Những điểm còn chưa chắc chắn

  • Danh sách hiển thị 1.579 gói cũng được ghi chú là “danh sách gồm nhiều gói bị ảnh hưởng nhưng không phải toàn bộ”
  • Vì vậy, con số được công bố cho thấy phạm vi ảnh hưởng lớn đã được xác nhận, nhưng bản thân danh sách này không bao quát toàn bộ các gói

Cập nhật tiếp theo

  • Một bản cập nhật riêng tiếp tục cho biết Arch Linux AUR đã hứng chịu thêm một làn sóng tấn công mã độc khác với mức độ tinh vi cao hơn

Bài viết liên quan

1 bình luận

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

  • Tôi muốn biết liệu đội AUR đã từng công bố bản phân tích hậu sự cố nào chưa
    Lần ứng phó này nhanh đến mức ấn tượng, nhưng thành thật mà nói, có vẻ cả chính sách AUR lẫn các wrapper đều cần thay đổi
    Nên có khả năng đặt tuổi tối thiểu cho gói như pnpm, và không nên để bất kỳ ai cũng có thể nhận nuôi gói mồ côi
    Việc nhận nuôi có thể bị áp giới hạn tốc độ trên toàn hệ thống để dùng làm tín hiệu tấn công, và cũng cần quét lỗ hổng tại thời điểm phát hành như nhiều công ty đang làm với NPM
    Tuy vậy, phần lớn các thay đổi này có lẽ gần với trách nhiệm của các trình trợ giúp đóng gói và bên thứ ba hơn là của người bảo trì AUR

    • Có lẽ nên chia các gói AUR theo namespace
      Như vậy quyền sở hữu sẽ không biến mất, nên bản thân việc chuyển sang trạng thái mồ côi cũng không còn cần thiết
    • Không có công cụ chính thức nào để tải kho AUR, nên phần đó phụ thuộc vào cách mỗi người tự dùng
    • Lấy cảm hứng từ pnpm, gần đây tôi đã thử tạo một bản vá cho pakku để thêm tuổi AUR tối thiểu [1]
      [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
      [2] https://github.com/zqqw/pakku
    • Nếu chặn việc nhận nuôi gói mồ côi quá mạnh tay thì những gói hoàn toàn có thể được bảo trì tử tế cũng có thể bị bỏ mặc
      Có cần giới hạn, nhưng có lẽ kiểu như 1 lần nhận nuôi mỗi tháng cho người dùng đã đăng ký từ trước một khoảng thời gian nhất định sẽ hợp lý hơn
      Dù sao thì cũng chẳng mấy ai áp dụng cập nhật AUR cài cục bộ theo kiểu tự động và không rà soát, nên bề mặt tấn công vốn đã khá nhỏ
    • Chỉ quét lỗ hổng đơn thuần có lẽ cũng không phát hiện được
      Điểm mấu chốt của sâu miasma chính là chữ ký và cách hoạt động của các helper thay đổi quá nhanh
      Implant độc hại đã mã hóa sẽ giải mã payload bằng khóa AES-128-GCM khác nhau tùy từng vị trí GitHub được tải lên, tên phương thức trong mã cũng thay đổi động, và còn trộn cả các symbol offset đã mã hóa để tái sử dụng
      Đây là malware đa hình nên là đối thủ tệ nhất với các công cụ dựa trên chữ ký
      Có vẻ APT28/29 phần nào dựa vào việc Microsoft chặn tự động các tài khoản người dùng và kho lưu trữ đang bị dùng làm hạ tầng C2 trên GitHub khá chậm
      Cần suy nghĩ xem điều đó có ý nghĩa gì đối với chiến lược bảo mật
      Đến lúc có thể quét chữ ký hay chuỗi ký tự thì thực chất đã là giai đoạn chơi trò mèo vờn chuột với botnet hoàn toàn tự động, và không thể thắng được
      Trong suốt tuần qua, công cụ chuỗi cung ứng duy nhất theo kịp các thay đổi của implant này có lẽ chỉ là socket.dev, còn các công cụ khác thậm chí còn không biết Miasma là gì và đã tái phát hiện nó như một chiến dịch mới
      Đã thiếu nhân lực và toolchain đủ để đảo ngược payload đủ nhanh nhằm theo kịp tốc độ mà adapter cho hệ sinh thái mới xuất hiện mỗi 24 giờ
      Ở đây, “hoàn toàn tự động” nghĩa là trong các hệ sinh thái gói khác, thông tin xác thực bị đánh cắp đã được dùng chỉ sau chưa đến 48 giờ
      Địa chỉ email và tên tuổi cứ liên tục xuất hiện, trông như những người rất có thể còn chưa hiểu tác động của con sâu tự lan truyền này
      Ví dụ, chỉ dấu xâm phạm kiểu tìm các gói phụ thuộc vào bun cũng không giúp ích nhiều
      Malware chỉ cần tải lại bằng phương thức bên ngoài là xong
      Ở chiến dịch PyPI thứ hai, sau khi làn sóng dropper độc hại đầu tiên của chiến dịch RedHat bị người bảo trì PyPI phát hiện, chúng đã chuyển sang dùng tệp WHL nén và tệp setup.pth tự động thực thi để tải dropper
      Trừ khi các trình quản lý gói của các hệ sinh thái này được viết lại từ đầu với giả định về chroot, sandbox, log mạng/tên miền và allowlist theo từng mục, chiến lược phát tán malware thông qua tấn công chuỗi cung ứng vẫn sẽ tiếp tục khả thi
      Kho công cụ giảm thiểu nằm ở [1], còn chi tiết kỹ thuật có trong bài blog [2]
      Composer, Rubygems, NPM, PyPI, Go đều bị ảnh hưởng, tức là đây là vấn đề trên toàn bộ các trình quản lý gói
      Cần thảo luận công khai hơn về việc chúng ta đang đặt bao nhiêu sự bất cẩn và niềm tin từ bên ngoài lên các trình quản lý gói, và điều này thật sự phải thay đổi
      [1] https://github.com/cookiengineer/antimiasma
      [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • Khi các wrapper pacman có thể cài trực tiếp từ AUR bắt đầu xuất hiện, tôi đã thấy cực kỳ khó chịu
    Tôi từng cài vài thứ từ AUR, nhưng phần lớn tôi thích bỏ qua bước trung gian và đi thẳng tới website của dự án hơn
    Một PKGBUILD dựng sẵn không tiện đến mức đáng để chấp nhận rủi ro bị chiếm đoạt do lỗi gõ tên hoặc do lạm dụng phụ thuộc npm/pip

    • Các wrapper như yay sẽ hiển thị khác biệt của PKGBUILD mỗi lần cập nhật
      Khi cài lần đầu, bạn kiểm tra URL và xem script cài đặt các thứ có hợp lý không, còn những lần cập nhật sau thì phần lớn chỉ đổi số phiên bản và checksum
      Tấn công chiếm đoạt do gõ sai tên sẽ lộ ra khá rõ
      Lần cài đầu hơi dễ tổn thương hơn, nhưng đi vào website dự án rồi bấm tải xuống cũng vậy thôi
    • Arch liên tục bị chê là mang tính tinh hoa hoặc cố chặn người dùng phổ thông, nhưng không làm cho những việc nguy hiểm trở nên dễ dàng rõ ràng cũng có mặt tốt
      Nhiều khía cạnh khác trong cuộc sống cũng thế
      Sau khi dùng Void Linux, tôi cũng chuyển sang aurutils trên Arch để có sự tách biệt tương tự
      Nó cho phép dễ dàng tự build, duy trì kho AUR cục bộ, rồi cài và quản lý bằng pacman, nên toàn bộ quy trình nâng cấp tốt hơn
    • Sự đánh đổi này với tôi là không đáng
      Một phần lý do tôi chuyển sang Linux là vì không muốn lãng phí thời gian như người dùng Windows, cứ vào website rồi bấm “download” để cập nhật chương trình
      Nhưng đúng là các wrapper pacman vừa nhắc tới trông có vẻ rủi ro
    • AUR và những kho tương tự trên các bản phân phối khác thực sự khiến tôi thấy đáng sợ
      Các hướng dẫn dùng những kho này lại quá phổ biến, đến mức tôi gần như thấy mình là người kỳ quặc chỉ vì không muốn trao quyền root vô thời hạn cho một người lạ hầu như không có đồng kiểm nào
      Chỉ để cài một phiên bản của gói vốn không cần cập nhật, hoặc rất hiếm khi cần cập nhật, mà chấp nhận rủi ro như vậy

  • Đọc nhanh thì có vẻ đã cài atomic-lockfile, js-digest, lockfile-js từ npm
    Danh sách các gói bị ảnh hưởng nằm ở [1]
    Tôi không tìm ra ngay cách kiểm tra hệ thống, nên đã chạy pacman -Qmi để tìm thông tin về các gói bên ngoài và ngày tháng liên quan
    Có thể đối chiếu đầu ra với danh sách các gói bị ảnh hưởng
    Ngoài ra cũng có thể tìm các tệp như sau ở nhiều vị trí
    grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
    grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
    grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
    Không rõ sau khi chạy thì gói có tự xóa chính nó hay không
    Vì các thông tin khác không giúp được nhiều, tôi muốn chia sẻ ít nhất là các lệnh cơ bản này
    [1] https://md.archlinux.org/s/SxbqukK6IA

    • Tôi đã làm theo cách này
      Dùng yay để lấy danh sách các gói đã cài từ AUR: yay -Qam > packages_aur.last
      Tải danh sách từ https://md.archlinux.org/s/SxbqukK6IA#: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
      Sau đó chạy grep -wFf compromised.txt packages_aur.last, có vẻ sẽ ra các gói xuất hiện trong cả hai tệp, tức là các gói đã từng bị xâm hại vào một thời điểm nào đó
    • Kẻ tấn công đã dùng ít nhất ba phụ thuộc Node, nên chỉ kiểm tra atomic-lockfile là chưa đủ
      js-digest và lockfile-js cũng đã được dùng, và có lúc chúng chuyển từ npm sang bun
    • Cái này cũng đáng tham khảo: https://github.com/lenucksi/aur-malware-check
    • Buồn cười ở chỗ ngay cả trong tình huống cố nhét mã độc vào Arch Linux AUR thì mã độc vẫn được phát tán qua NPM
      Đúng là một nền tảng huyền thoại
    • Tôi không hiểu emacs-magit đã bị ảnh hưởng thế nào
      Theo tôi biết thì nó hoàn toàn không có JavaScript

  • Đây lại là một lời nhắc nhở hợp lý như mọi khi rằng đừng cài các gói, thư viện hay ứng dụng bên thứ ba tùy tiện mà không xem xét
    May là lần này vụ việc chỉ giới hạn trong AUR, mà AUR thực chất là kho gói nơi gần như ai cũng có thể đăng lên, và khác với kho chính thức, người dùng đã nhiều lần được cảnh báo rằng cần xem xét trước khi cài
    Các công cụ dòng lệnh như rua giúp việc xem xét gói trước khi cài từ AUR dễ hơn
    Nếu bạn làm ngân hàng trên cùng một máy tính thì không có lý do gì để không xem xét phần mềm mà mình phụ thuộc
    Giữ số lượng gói ở mức thấp và chỉ dùng thứ thật sự cần cũng sẽ làm việc nâng cấp đơn giản hơn nhiều

    • “Xem xét” là phải làm thế nào
      Ý là phải đọc từng dòng mã trước khi cài sao
      Nếu là gói nhị phân thì sao
      Hay là phải tạo bản dựng tái lập được cho mọi thứ mình cài, hoặc chuyển sang một bản phân phối dựa trên mã nguồn
      Đẩy trách nhiệm này sang cho người dùng không phải là một lời giải bền vững
      Có thể có chỗ cho lẽ thường, nhưng đổ lỗi việc này cho người dùng thì vô lý
    • Nghe có vẻ hợp lý nhưng rốt cuộc lại là lời khuyên không thể thực hiện được, nên không chỉ vô dụng mà còn có hại
      Trên đời có nhiều mã nguồn hơn rất nhiều so với lượng mà một người có thể đọc trong cả đời
      Bản thân bạn cũng rất có thể chưa đọc nổi 1% mã nguồn hiện đang chạy trên máy tính của mình
      Vậy bạn đã ngừng dùng máy tính chưa
      Làm sao bạn có thể tin vào những gì đang diễn ra bên trong nó
    • Tôi nghĩ lập trường “phải xem xét trước khi cài” cần được đánh giá lại
      Các nhà phát triển Arch Linux đang làm việc rất tuyệt và cá nhân tôi biết ơn họ, nhưng trong thời điểm các cuộc tấn công chuỗi cung ứng gia tăng như hiện nay, tôi cảm thấy chỉ cảnh báo người dùng thôi thì đã chạm giới hạn từ lâu rồi
      Không thấy có giải pháp dễ dàng, nhưng các biện pháp kiểm soát như rà soát đồng cấp trước khi đăng hoặc thời gian chờ có thể phần nào giảm bớt vấn đề
    • AUR từ lâu đã được đánh giá cao như một ưu điểm lớn của Arch, nhưng sự tiện lợi đó luôn có cái giá của nó
      Việc đánh dấu một gói là mồ côi, chờ 2 tuần, rồi nếu người bảo trì cũ đang đi nghỉ nên không thể phản hồi thì kẻ tấn công có thể được giao làm người bảo trì và phát hành một bản cập nhật cay độc là điều thật vô lý
    • Tôi xem đây là một ví dụ mạnh mẽ ủng hộ sự kết hợp của tệp hệ thống bất biến, cài đặt cục bộ mặc định cho người dùng, và chỉ cấp đặc quyền tối thiểu cho các thành phần và chương trình
      Các bản phân phối bất biến, Wayland và Flatpak đã có một vài mảnh ghép, nhưng vẫn còn những lỗ hổng quan trọng
      Vấn đề lớn nhất là sandboxing bị gắn chặt với định dạng gói, và tôi nghĩ đó là một sai lầm
      Sandboxing và quyền truy cập nên là tính năng ở cấp hệ thống, để ngay cả nhị phân tùy ý cũng không thể dễ dàng chui qua kẽ hở
      Dù không giải quyết hoàn toàn vấn đề, cách đó có thể giảm đáng kể phạm vi thiệt hại và khiến người dùng bản phân phối trở thành mục tiêu kém hấp dẫn hơn

  • Với những ai đang lo lắng, tôi đã tìm thấy một kho tổng hợp các script mới nhất và danh sách gói để hỗ trợ kiểm tra có bị nhiễm hay không: https://github.com/lenucksi/aur-malware-check

    • Tôi đã đưa cùng danh sách đó (https://md.archlinux.org/s/SxbqukK6IA) cho Claude để kiểm tra mã độc, và nó thực hiện về bản chất cùng một kiểu xác minh như script này làm
      Dùng cách nào chắc cũng đủ ổn thôi

  • Tôi không dùng Arch Linux, nhưng dùng NodeJS khá nhiều, và bên đó cũng thường xuyên gặp các kiểu tấn công tương tự
    Dạo này tôi tự hỏi còn nơi nào quản lý gói phần mềm cho đúng cách và an toàn nữa không

    • AUR dựa trên hỗ trợ từ người dùng nên phần mềm độc hại thỉnh thoảng bị trộn vào gói
      Tuy không ở quy mô lớn như lần này, nhưng ngay từ đầu đã rõ là nó không an toàn, và khắp nơi đều có cảnh báo rủi ro
    • Các bản phân phối Linux làm khá tốt
      Tất cả đều có những người bảo trì xem xét gói và chịu trách nhiệm về chúng
      Arch Linux cũng vậy
      Tính không đáng tin cậy vốn có của AUR luôn được nêu rõ ràng trong Arch Wiki và trong văn hóa xung quanh nó, và nó khác với các trình quản lý gói của ngôn ngữ lập trình như npm hay pip
    • Nếu không dùng AUR thì Arch vẫn ổn
      Nếu dùng AUR thì phải kiểm tra mọi thứ
      Hầu hết các bản phân phối cũng ổn, và các bản phân phối lớn có thành tích khá tốt
    • Có vẻ hệ sinh thái Node có điều gì đó khiến nó đặc biệt dễ tổn thương
      Có thể là do văn hóa DRY quá mức, hoặc cũng có thể vì lý do khác
      Trong những thứ tôi từng dùng, tôi chưa thấy cơn ác mộng cây phụ thuộc nào ở mức tương tự

  • AUR có 15 nghìn gói mồ côi
    Sáng nay tôi sắp xếp theo độ phổ biến và nhận nuôi rồi build 3 gói hầu như không được cập nhật
    Nếu bạn đang dùng các gói mồ côi, có lẽ nên cân nhắc tự nhận nuôi chúng trước khi kẻ xấu lấy mất

  • Có thể tôi sai, nhưng tình huống lần này trông giống một dấu hiệu của việc Linux desktop đang được chấp nhận nhiều hơn

  • Tôi chưa từng cần AUR
    Nếu cần một gói không có trong kho chính thức, tôi sẽ tự build hoặc tải bản phát hành nhị phân nếu có
    Làm vậy thì không cần dùng root khi build, và có thể cài cục bộ cho một người dùng, nên thực ra phù hợp hơn với phần lớn trường hợp dùng desktop
    Ít nhất thì so với đường đi nhà phát triển → người dùng, cách này giảm bớt một tầng khả năng bị chèn mã độc là nhà phát triển → người bảo trì → người dùng

    • makepkg sẽ chủ động từ chối nếu chạy bằng root
      Trừ khi cố tình lách kiểu env EUID=123 makepkg ..., còn không thì nó sẽ không chạy với root
      Tuy vậy, sẽ rất tốt nếu pacman hỗ trợ cài đặt ở mức người dùng
      Hiện tại nó từ chối cài nếu không phải root, dù vẫn có thể lách bằng cách ánh xạ chính mình thành root trong user namespace

  • Tôi hiểu vì sao lần này lại là AUR
    Dù có phải AUR hay không, sẽ rất hay nếu mọi người chia sẻ khi cài một gói thì họ đi qua những bước nào, và làm sao bảo đảm gói cùng các phụ thuộc định cài không phải là phần mềm độc hại
    Một khi đã cài nhầm gói xấu rồi thì có vẻ thực sự rất khó quay lại