Cửa hậu xz được phát hiện nhờ NixOS và các bản dựng có thể tái lập

• Vào tháng 3 năm 2024, một cửa hậu đã được phát hiện trong phần mềm xz dùng để giải nén source tarball trên các bản phân phối Linux.
• Cửa hậu này đã bị một người bảo trì độc hại, Jia Tan, âm thầm cài vào trong suốt 3 năm.
• Sự việc này có tác động rất lớn vì cho phép thực thi mã từ xa và cực kỳ khó bị phát hiện.
• Andres Freund, nhà phát triển Postgres tại Microsoft, đã tình cờ phát hiện ra khi điều tra hiện tượng suy giảm hiệu năng, qua đó tránh được một thảm họa lớn.

Cách cuộc tấn công hoạt động

• Cửa hậu chiếm quyền chương trình ssh để cho phép thực thi mã từ xa.
• Nó sửa đổi hàm RSA_public_decrypt để kẻ tấn công có thể chạy lệnh tùy ý khi đăng nhập bằng một khóa RSA cụ thể.
• Nó gồm hai thành phần chính:
  1. Một script cài đặt tệp đối tượng độc hại như một phần của quy trình build xz.
  2. Một thủ tục hook hàm RSA_public_decrypt.

1. Script cài đặt tệp đối tượng độc hại

• Tệp đối tượng độc hại được ẩn trong các tệp kiểm thử của kho Git xz.
• Cửa hậu chỉ được kích hoạt trong release tarball do người bảo trì cung cấp.

2. Thủ tục hook hàm RSA_public_decrypt

• Nó sử dụng tính năng ifunc của glibc để buộc thực thi mã chạy tại thời điểm nạp động.
• Khi ssh chạy, libsystemd và liblzma được nạp, và trong quá trình này cửa hậu thực thi mã tùy ý.

Cách tránh thảm họa xz

• Để nâng cao độ tin cậy của phần mềm mã nguồn mở, cần xử lý cả vấn đề xã hội lẫn vấn đề kỹ thuật.
• Cần cải thiện các quy trình bảo mật chuỗi cung ứng phần mềm.

Build phần mềm từ nguồn đáng tin cậy

• Cuộc tấn công hiệu quả vì nhiều bản phân phối đã build xz từ tarball do người bảo trì cung cấp.
• Khi có thể, nên build phần mềm từ nguồn đáng tin cậy nhất.

Khi hoàn cảnh cho phép...

• NixOS là một bản phân phối dựa trên mô hình quản lý gói hàm, trong đó mỗi gói được biểu diễn bằng ngôn ngữ lập trình hàm Nix.
• NixOS có văn hóa sử dụng các kho lưu trữ mã nguồn được GitHub tự động tạo ra.

Xây dựng niềm tin với release tarball không đáng tin cậy

• NixOS từng phải sử dụng tarball do người bảo trì cung cấp ở giai đoạn bootstrap.
• Cần thiết lập các biện pháp bảo vệ cụ thể để tăng cường an ninh chuỗi cung ứng phần mềm.

1. So sánh nguồn

• Điều quan trọng là phải xác nhận source tarball mà bản phân phối sử dụng có giống với bản trên GitHub hay không.
• Tuy nhiên, release tarball thường khác với mã nguồn, và điều đó không phải là vấn đề.

2. Tận dụng khả năng tái lập đến từng bit

• Bản dựng có thể tái lập là thuộc tính của một dự án phần mềm tạo ra cùng một artifact khi được build hai lần trong cùng điều kiện.
• Khả năng tái lập đến từng bit có thể giúp xây dựng niềm tin đối với tarball do người bảo trì cung cấp nhưng không đáng tin cậy.

Kết luận

• Sự cố cửa hậu xz nhắc lại tầm quan trọng của bảo mật chuỗi cung ứng phần mềm mã nguồn mở.
• Các hệ thống như NixOS có thể tăng cường bảo mật thông qua các bản dựng có thể tái lập.

[GN⁺]

Ý kiến trên Hacker News

• NixOS và các bản dựng có thể tái lập đã không phát hiện được backdoor xz. NixOS đã phân phối bản dựng xz độc hại, nhưng không có vấn đề gì vì nó không nhắm tới NixOS

  • Một nhà phát triển NixOS đã ngạc nhiên khi thấy phiên bản xz độc hại đã được phân phối tới người dùng vào lúc backdoor bị phanh phui
  • Lý thuyết và thực tế là khác nhau, và lý do xz có thể xảy ra không phải do điểm yếu kỹ thuật mà là vấn đề của "thế giới thực". Có một sự khó khăn trong việc nhận ra rằng không thể vá thế giới thực bằng phần mềm

• Có vẻ tác giả chỉ đang tập trung vào riêng vụ việc này. Vụ Jiatan là một trường hợp đơn lẻ, và ở những kịch bản khác thì biện pháp phòng vệ vẫn có thể thất bại

  • Với tư cách là người dùng NixOS, tôi nghĩ rất có thể NixOS đã không bắt được việc này. Không có bằng chứng thì đặt niềm tin vào NixOS là điều ngây thơ

• NixOS không liên quan vì backdoor xz nhắm tới RedHat và Debian. Trớ trêu là backdoor lại được phát hiện bởi một nhân viên Microsoft

• Bài viết nói rằng các bản phân phối nên lấy mã nguồn trực tiếp từ VCS (ví dụ: Github) thay vì tarball cài đặt truyền thống

  • Tuy nhiên, một maintainer độc hại có thể thêm trực tiếp binary blob vào kho mã nguồn
  • Tác giả gợi ý rằng Github đáng tin như thể nó xác minh mã, nhưng thực tế Github không xác minh mã

• Nếu muốn tập trung vào sự cố mà NixOS có thể đã ngăn chặn, thì nên tập trung vào sự cố CrowdStrike. Nếu có thể khởi động bằng cấu hình của ngày hôm qua thì phần lớn vấn đề đã có thể được giảm nhẹ

• NixOS biên dịch mọi thứ từ mã nguồn, xác minh bằng mật mã rằng mã nguồn được dùng không bị sửa đổi, và có quan hệ phụ thuộc phiên bản giữa các gói. Debian cũng có các bản dựng có thể tái lập

  • Vấn đề là hệ thống build đã không loại bỏ các object file được biên dịch sẵn trước khi build từ mã nguồn. Nếu không ai kiểm tra mã nguồn thì có thể chèn backdoor, và NixOS hay các bản phân phối khác cũng không thể ngăn điều đó

• "Có thể đã làm được" nghĩa là điều đó chưa được chứng minh, và trên thực tế họ đã phân phối nó

• Một bài phân tích giải thích rất tốt. Tiêu đề sai lệch, dễ gây hiểu nhầm, có lẽ là "đúng về mặt kỹ thuật", nhưng theo kiểu tốt nhất cho nghĩa "có chứa backdoor"

  • Điều này nhấn mạnh nhu cầu và việc sử dụng các công cụ quản lý build, đồng thời cần xây dựng cách tạo rõ ràng đồ thị truy vết quan hệ nhân quả giữa các tệp trong quá trình build, rồi thực thi theo đồ thị đó hoặc báo cáo các sai lệch so với đồ thị truy vết trước đó

• Nếu PR của Jia Tan được chấp nhận, các artifact độc hại cũng có thể dễ dàng được đưa lên Github release giống như tarball. Thật khó hiểu khi cho rằng Github release là một biện pháp giảm thiểu bảo mật

• Việc tarball phát hành khác với mã nguồn

  • Nếu tarball do maintainer cung cấp được tạo ra một cách trung thực từ mã nguồn gốc, thì khó hiểu vì sao khác phiên bản này nọ lại trở thành vấn đề
  • Cần bảo đảm tarball được tạo ra từ chính mã nguồn, không loại trừ gì cả, rồi git add & commit. Ngay cả trong trường hợp đó vẫn phải kiểm tra lịch sử commit, và vì nó trông vô hại bằng mắt thường nên cũng khó hiểu phải xác minh bằng cách nào
  • Sẽ là vấn đề nếu tarball được maintainer tạo từ mã nguồn của họ và không có trên Github

• Có nhiều vấn đề hơn là chỉ đẩy lên các tệp kiểm thử bị đầu độc, nhưng khó hiểu Nix có thể ngăn điều đó bằng cách nào

  • Nếu một dự án nổi tiếng thay đổi người lãnh đạo, thì có lẽ cần xem kỹ các commit và xác nhận ai là người dẫn dắt

• Không rõ là tôi đã hiểu sai bài viết hay đã bỏ sót điều gì đó