An ninh chuỗi cung ứng: Không ai nợ bạn sự an toàn

An ninh chuỗi cung ứng: Không ai nợ bạn sự an toàn

Gần đây, cộng đồng công chứng đã chứng kiến nhiều chỉ trích nhắm vào crates.io – kho chứa các gói thư viện (crate) chính của ngôn ngữ lập trình Rust – liên quan đến các vấn đề về an ninh chuỗi cung ứng. Tuy nhiên, phần lớn những lời chỉ trích này đang bỏ lỡ điểm cốt lõi của vấn đề. Chúng ta cần nhìn nhận thực tế về cách thức các cuộc tấn công này diễn ra và tại sao các giải pháp kỹ thuật đơn giản thường không hiệu quả.

Cách thức tấn công và giới hạn của giải pháp kỹ thuật

Một trong những phương thức tấn công phổ biến nhất là typo-squatting (đánh cắp tên gói qua lỗi chính tả). Kẻ tấn công tạo ra một thư viện có tên giống hệt hoặc rất giống với thư viện chính thống (ví dụ: num_cpu thay vì num_cpus). Nhiều người đề xuất sử dụng URL trực tiếp hoặc không gian tên (namespaces) để giải quyết vấn đề này.

Tuy nhiên, thực tế phức tạp hơn nhiều. Hãy tưởng tượng bạn nhận được một Pull Request thêm các dòng sau vào file Cargo.toml:

itertools = { git = "https://github.com/rust-itertools/itertools" }
bitflags = { git = "https://github.com/rust-bitflags/bitflags" }

Một trong hai URL trên là giả mạo. Bạn có thể nhận ra URL nào là đúng không? Đó là itertools với URL chính xác là https://github.com/rust-itertools/itertools. Trong khi đó, https://github.com/itertools chỉ là một tài khoản ngẫu nhiên và rust-bitflags thậm chí chưa được đăng ký.

Việc kỳ vọng nhà phát phát triển nhớ chính xác URL của từng gói thư viện là điều không khả thi. Bằng cách làm cho ID của các crate dài hơn thông qua namespacing hay domain, chúng ta chỉ làm tăng gánh nặng trí nhớ cho người dùng, từ đó khiến việc phát hiện typo-squatting trở nên khó khăn hơn.

Rủi ro từ Build Scripts và Procedural Macros

Rust cung cấp cho build scripts (build.rs) và procedural macros quyền truy cập hoàn toàn vào máy tính của bạn. Nguy hiểm hơn, công cụ như rust-analyzer tự động chạy cargo check khi bạn mở thư mục dự án, điều này có thể biến nó thành một lỗ hổng RCE (Remote Code Execution) không cần tương tác (0-click).

Đã có nhiều nỗ lực để giải quyết vấn đề này, chẳng hạn như sandboxing build.rs hoặc biên dịch macro sang WebAssembly. Tuy nhiên, đây không phải là giải pháp khả thi trong ngắn hạn. Mặc dù cargo build có thể được làm an toàn, nhưng ngay sau đó bạn thường chạy cargo test hoặc cargo run, những lệnh này gần như không thể sandbox hoàn toàn mà không làm hỏng chức năng của phần mềm. Đòi hỏi cargo phải chịu trách nhiệm về sự cô lập ở mức hệ thống là quá sức đối với một công cụ quản lý gói thư viện.

Sự không đồng nhất giữa Git và crates.io

Một vấn đề thường được nhắc đến là mã nguồn trên crates.io và trong kho Git đôi khi không khớp nhau. Việc giải quyết điều này không hề đơn giản. Bạn không thể biến crates.io thành một hệ thống DNS ánh xạ tên crate sang URL repo, bởi vì crates.io được thiết kế để hoạt động như một kho lưu trữ vĩnh viễn, ngăn chặn việc các maintainer xóa dữ liệu và làm hỏng hệ thống downstream (như bài học từ sự kiện left-pad trên npm).

crates.io có thể lấy file từ repo khi bạn chạy cargo publish, nhưng nếu maintainer thực hiện force-push sau đó, cơ chế này trở nên vô nghĩa. Việc quét định kỳ các kho lưu trữ để phát hiện thay đổi lịch sử cũng đầy rẫy các trường hợp ngoại lệ và báo động giả (false positives), đặc biệt khi các repo tự lưu trữ hoặc sử dụng mã được tự động sinh ra.

Trách nhiệm thuộc về ai?

Tất cả các vấn đề trên đều dựa trên một giả định ngầm chưa được kiểm chứng: việc giữ mã độc ra khỏi crates.io là trách nhiệm của "Rust". Nếu bạn sử dụng một dependency và cargo add totally-safe-package đánh cắp thông tin đăng nhập của bạn, người ta thường quy lỗi cho crates.io.

Đây là một cách nhìn sai lầm. Giống như hầu hết phần mềm mã nguồn mở, Rust được cung cấp "nguyên trạng" (AS IS) theo giấy phép MIT, không có bất kỳ bảo đảm nào. Rust không được tài trợ bởi các tập đoàn lớn như Microsoft hay Red Hat ở cùng mức độ mà GitHub hay Linux được hưởng. Trình biên dịch và thư viện chuẩn chủ yếu được phát triển bởi các tình nguyện viên.

Rust Foundation là một tổ chức phi lợi nhuận với nguồn lực hạn chế. Việc kỳ vọng một kho đăng ký nhỏ, chủ yếu dựa vào tình nguyện viên và kiểm duyệt sau (post-moderated) như crates.io có thể cung cấp mức độ bảo mật tương đương với các kho tập trung, được tài trợ mạnh mẽ như Ubuntu là hoàn toàn phi lý.

Người dùng cần tự bảo vệ mình

Trong bối cảnh hiện tại, không ai khác có thể chịu trách nhiệm về an ninh cho bạn ngoài chính bạn. Rust đã cung cấp đầy đủ các công cụ cần thiết để bạn tự bảo vệ:

• Lockfiles: Giới hạn cài đặt ở các phiên bản đã được xác minh.
• Quản lý phiên bản: Sử dụng cargo add package@version để cài đặt phiên bản cụ thể.
• Kiểm toán mã nguồn: Sử dụng cargo-vet, kiểm tra biểu đồ tải xuống trong 90 ngày trên crates.io (kẻ tấn công khó có thể giả mạo số lượng này), và nhấn vào "browse source" để xem nhanh mã nguồn.
• Cập nhật cẩn thận: Sử dụng cargo update --dry-run để xem danh sách các crate cần cập nhật và kiểm tra lại chúng trước khi thực sự cập nhật.
• Sandboxing: Sử dụng cargo-chef hoặc các công cụ như firejail để cô lập quá trình build.

Rất ít trong số chúng ta là các nhà nghiên cứu bảo mật chuyên nghiệp, nhưng phần lớn việc kiểm tra an ninh chỉ cần sự tỉnh táo và một chút tò mò. Nếu bạn không kiểm toán mã nguồn bạn sử dụng, thì ai sẽ làm?