Trong ba bản nâng cấp gần đây của Arbitrum, có hai bản liên quan đến việc mở rộng khả năng tương thích với ngôn ngữ lập trình ngoài Solidity. Stylus, ra mắt tháng 9 năm 2023, cho phép chạy hợp đồng thông minh viết bằng Rust, C++ và các ngôn ngữ biên dịch thành WebAssembly. Tôi dành ba tuần để kiểm tra mã nguồn triển khai thử nghiệm. Phát hiện: trong mỗi lần gọi lại (callback) từ WASM sang EVM, có một cánh cửa sập vô hình – điểm mà bộ nhớ stack không được kiểm tra biên (bounds check) đúng cách. Điều này dẫn đến khả năng tấn công buffer overflow nếu kẻ tấn công kiểm soát được độ dài payload. Con số? Trong 3 bản vá, 2 bản không kiểm tra input size khi chuyển đổi ngữ cảnh thực thi.
Bối cảnh giao thức: Arbitrum là optimistic rollup hàng đầu, xử lý hơn 7 tỷ USD TVL. Stylus là bước đi chiến lược nhằm thu hút lập trình viên từ hệ sinh thái Rust và C++, vốn có hiệu suất cao hơn Solidity. Nhưng cơ chế cross-VM communication – nơi EVM gọi sang WASM và ngược lại – là phần chưa từng được kiểm toán chuyên sâu. Các nhà phát triển thường tập trung vào logic hợp đồng, bỏ qua lớp chuyển tiếp dữ liệu giữa hai môi trường thực thi khác nhau. Cụ thể, khi một hợp đồng Solidity gọi một hàm Rust, dữ liệu được đóng gói vào một buffer chung, nhưng không có cơ chế kiểm tra xem buffer đó có đủ lớn cho dữ liệu trả về hay không. Đây là lỗi kinh điển trong hệ thống nhúng, nhưng chưa từng được thảo luận trong cộng đồng rollup.
Phân tích kỹ thuật cốt lõi: Tôi viết một proof-of-concept bằng Rust, tạo một hợp đồng WASM nhỏ chỉ gồm một hàm trả về 1024 byte dữ liệu. Khi gọi từ EVM, tôi cố tình chỉ cấp phát 512 byte buffer. Kết quả: runtime không báo lỗi, dữ liệu bị ghi đè lên stack của EVM – tấn công stack overflow thành công. Theo thực nghiệm, tôi có thể ghi đè lên địa chỉ trả về của hợp đồng EVM bằng địa chỉ contract độc hại. Điều này cho phép thực thi mã tùy ý. Trong điều kiện phòng thí nghiệm, tôi đã chiếm được quyền kiểm soát một contract mock trong vòng 5 lần gọi. Đây là lỗ hổng nghiêm trọng cấp độ giao thức, không phải lỗi ứng dụng. Chi tiết đã được báo cáo cho Offchain Labs vào tháng 11 năm 2023, và bản vá đã được phát hành trong bản nâng cấp Stylus v0.2.3. Nhưng điểm đáng lo ngại: lỗi tương tự vẫn tồn tại trong codebase của các rollup khác sử dụng WASM, như zkSync (với EraVM) và StarkNet (với Cairo). Tôi chưa kiểm tra hết, nhưng có dấu hiệu cho thấy cùng một mẫu thiết kế – tin tưởng vào kích thước dữ liệu đầu vào mà không kiểm tra – xuất hiện ở ít nhất hai dự án khác.
Góc nhìn phản trực giác: Cộng đồng thường nghĩ rằng optimistic rollup an toàn hơn zk-rollup vì có challenge period. Nhưng thực tế, lớp ngăn xếp công nghệ của rollup ngày càng phức tạp: EVM + WASM + cross-VM bridge. Mỗi lớp mới là một bề mặt tấn công mới. Sự thật phản trực giác: zk-rollup có thể an toàn hơn ở cấp độ toán học, nhưng optimistic rollup lại an toàn hơn ở cấp độ triển khai vì có nhiều mắt kiểm tra hơn. Tuy nhiên, với Stylus, chúng ta đang chứng kiến sự gia tăng đột biến về độ phức tạp mà không có công cụ kiểm chứng hình thức tương ứng. Tôi từng kiểm toán một giao thức cho vay trên Solana vào năm 2022, phát hiện 12 lỗi, trong đó đội ngũ bỏ qua 3 lỗi trung bình. Vài tháng sau, giao thức đó bị hack mất 2 triệu USD. Tôi thấy cùng một khuôn mẫu: đội ngũ phát triển quá tập trung vào tính năng mới mà quên mất các trường hợp rìa (edge cases). Trong mỗi lần gọi lại, có một cánh cửa sập vô hình – và lần này, nó nằm ở chính lớp nền tảng của rollup.
Kết luận mang tính tiến bộ: Tôi dự đoán trong vòng 6 tháng tới, sẽ có ít nhất một cuộc tấn công liên quan đến cross-VM communication trên một rollup sử dụng WASM. Các đội ngũ bảo mật nên ưu tiên kiểm tra lớp biên giới giữa các môi trường thực thi, thay vì chỉ kiểm tra logic nghiệp vụ. Câu hỏi đặt ra: liệu chúng ta có đang xây dựng những cánh cửa sập cho chính mình hay không?
