Phân tích lỗ hổng tràn số nguyên trong ngôn ngữ Move
Lời mở đầu
Sau khi nghiên cứu sâu về Aptos Moveevm, chúng tôi đã phát hiện ra một lỗ hổng tràn số nguyên mới. Quá trình kích hoạt lỗ hổng này tương đối thú vị hơn, dưới đây chúng tôi sẽ phân tích sâu về lỗ hổng này và giới thiệu một số kiến thức nền tảng về ngôn ngữ Move. Thông qua bài viết này, chúng tôi tin rằng bạn sẽ có cái nhìn sâu sắc hơn về ngôn ngữ Move.
Ngôn ngữ Move sẽ xác thực các đơn vị mã trước khi thực thi bytecode. Quá trình xác thực được chia thành 4 bước, và lỗ hổng này xuất hiện trong bước reference_safety.
An toàn tham chiếu trong Move
Ngôn ngữ Move hỗ trợ hai loại tham chiếu: tham chiếu không thay đổi (&) và tham chiếu thay đổi (&mut). Tham chiếu không thay đổi được sử dụng để đọc dữ liệu từ cấu trúc, trong khi tham chiếu thay đổi được sử dụng để sửa đổi dữ liệu. Việc sử dụng loại tham chiếu thích hợp giúp duy trì tính an toàn và nhận diện mô-đun đọc.
Trong mô-đun an toàn tham chiếu của Move, mã byte của các khối cơ bản trong hàm sẽ được quét theo từng hàm để xác minh tất cả các thao tác tham chiếu có hợp pháp hay không. Quy trình chính để xác minh an toàn tham chiếu bao gồm việc thực hiện các khối cơ bản, tạo trạng thái sau, hợp nhất trạng thái trước và sau, v.v.
Phân tích lỗ hổng
Lỗi xuất hiện trong hàm join_ được gọi là mô-đun bảo mật. Khi tổng chiều dài tham số của hàm và chiều dài biến cục bộ lớn hơn 256, việc sử dụng loại u8 để biểu diễn biến local sẽ dẫn đến tràn số nguyên.
Mặc dù Move có quy trình kiểm tra số lượng locals, nhưng trong mô-đun kiểm tra giới hạn chỉ kiểm tra locals mà không bao gồm độ dài tham số. Các nhà phát triển dường như nhận ra cần kiểm tra tổng số tham số và giá trị cục bộ, nhưng trong mã chỉ kiểm tra số lượng biến cục bộ.
Từ tràn số nguyên đến tấn công DoS
Bằng cách tận dụng lỗ hổng tràn số nguyên này, kẻ tấn công có thể tạo ra một khối mã lặp, thay đổi trạng thái của khối. Khi hàm execute_block được thực thi lại, nếu chỉ thị cần truy cập chỉ mục không tồn tại trong bản đồ locals của AbstractState mới, sẽ dẫn đến cuộc tấn công DoS.
Trong mô-đun reference safety, các mã thao tác như MoveLoc/CopyLoc/FreeRef có thể kích hoạt tình huống này. Ví dụ, trong hàm copy_loc, nếu LocalIndex không tồn tại sẽ dẫn đến panic, từ đó dẫn đến sự cố toàn bộ nút.
Tái hiện lỗ hổng
Bạn có thể tái tạo lỗ hổng này trong git bằng mã PoC sau:
di chuyển
public fun test(a: u64, b: u64, c: u64, d: u64) {
let x = 0;
vòng {
nếu (x == 1) {
nghỉ
};
x = x + 1;
}
}
Các bước kích hoạt DoS như sau:
Lần đầu tiên thực hiện hàm execute_block, thiết lập parameters và locals đều là SignatureIndex(0), dẫn đến num_locals là 264. Sau khi thực hiện hàm join_, độ dài của bản đồ locals mới trở thành 8.
Khi thực thi hàm execute_block lần thứ hai, thực thi dòng mã move đầu tiên là copyloc(57). Do lúc này locals chỉ có độ dài 8, offset 57 không tồn tại, dẫn đến hàm get(57).unwrap() trả về None, cuối cùng gây ra panic.
Tóm tắt
Lỗ hổng này cho thấy không có mã nào hoàn toàn an toàn. Mặc dù ngôn ngữ Move đã thực hiện kiểm tra tĩnh trước khi thực thi mã, nhưng vẫn có thể bị vượt qua bởi lỗ hổng tràn. Điều này một lần nữa nhấn mạnh tầm quan trọng của việc kiểm toán mã.
Đối với ngôn ngữ Move, chúng tôi khuyên nên thêm nhiều mã kiểm tra hơn trong quá trình thực thi để ngăn chặn các tình huống bất ngờ xảy ra. Hiện tại, Move chủ yếu thực hiện kiểm tra an toàn ở giai đoạn xác minh, nhưng một khi việc xác minh bị bỏ qua, thiếu sự gia cố an toàn đầy đủ trong giai đoạn thực thi có thể dẫn đến các vấn đề nghiêm trọng hơn.
Là người dẫn đầu trong nghiên cứu an toàn ngôn ngữ Move, chúng tôi sẽ tiếp tục nghiên cứu sâu về các vấn đề an toàn của Move và sẽ chia sẻ thêm nhiều phát hiện trong thời gian tới.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Phân tích lỗ hổng tràn số nguyên trong ngôn ngữ Move: từ bảo mật tham chiếu đến cuộc tấn công DoS
Phân tích lỗ hổng tràn số nguyên trong ngôn ngữ Move
Lời mở đầu
Sau khi nghiên cứu sâu về Aptos Moveevm, chúng tôi đã phát hiện ra một lỗ hổng tràn số nguyên mới. Quá trình kích hoạt lỗ hổng này tương đối thú vị hơn, dưới đây chúng tôi sẽ phân tích sâu về lỗ hổng này và giới thiệu một số kiến thức nền tảng về ngôn ngữ Move. Thông qua bài viết này, chúng tôi tin rằng bạn sẽ có cái nhìn sâu sắc hơn về ngôn ngữ Move.
Ngôn ngữ Move sẽ xác thực các đơn vị mã trước khi thực thi bytecode. Quá trình xác thực được chia thành 4 bước, và lỗ hổng này xuất hiện trong bước reference_safety.
An toàn tham chiếu trong Move
Ngôn ngữ Move hỗ trợ hai loại tham chiếu: tham chiếu không thay đổi (&) và tham chiếu thay đổi (&mut). Tham chiếu không thay đổi được sử dụng để đọc dữ liệu từ cấu trúc, trong khi tham chiếu thay đổi được sử dụng để sửa đổi dữ liệu. Việc sử dụng loại tham chiếu thích hợp giúp duy trì tính an toàn và nhận diện mô-đun đọc.
Trong mô-đun an toàn tham chiếu của Move, mã byte của các khối cơ bản trong hàm sẽ được quét theo từng hàm để xác minh tất cả các thao tác tham chiếu có hợp pháp hay không. Quy trình chính để xác minh an toàn tham chiếu bao gồm việc thực hiện các khối cơ bản, tạo trạng thái sau, hợp nhất trạng thái trước và sau, v.v.
Phân tích lỗ hổng
Lỗi xuất hiện trong hàm join_ được gọi là mô-đun bảo mật. Khi tổng chiều dài tham số của hàm và chiều dài biến cục bộ lớn hơn 256, việc sử dụng loại u8 để biểu diễn biến local sẽ dẫn đến tràn số nguyên.
Mặc dù Move có quy trình kiểm tra số lượng locals, nhưng trong mô-đun kiểm tra giới hạn chỉ kiểm tra locals mà không bao gồm độ dài tham số. Các nhà phát triển dường như nhận ra cần kiểm tra tổng số tham số và giá trị cục bộ, nhưng trong mã chỉ kiểm tra số lượng biến cục bộ.
Từ tràn số nguyên đến tấn công DoS
Bằng cách tận dụng lỗ hổng tràn số nguyên này, kẻ tấn công có thể tạo ra một khối mã lặp, thay đổi trạng thái của khối. Khi hàm execute_block được thực thi lại, nếu chỉ thị cần truy cập chỉ mục không tồn tại trong bản đồ locals của AbstractState mới, sẽ dẫn đến cuộc tấn công DoS.
Trong mô-đun reference safety, các mã thao tác như MoveLoc/CopyLoc/FreeRef có thể kích hoạt tình huống này. Ví dụ, trong hàm copy_loc, nếu LocalIndex không tồn tại sẽ dẫn đến panic, từ đó dẫn đến sự cố toàn bộ nút.
Tái hiện lỗ hổng
Bạn có thể tái tạo lỗ hổng này trong git bằng mã PoC sau:
di chuyển public fun test(a: u64, b: u64, c: u64, d: u64) { let x = 0; vòng { nếu (x == 1) { nghỉ }; x = x + 1; } }
Các bước kích hoạt DoS như sau:
Lần đầu tiên thực hiện hàm execute_block, thiết lập parameters và locals đều là SignatureIndex(0), dẫn đến num_locals là 264. Sau khi thực hiện hàm join_, độ dài của bản đồ locals mới trở thành 8.
Khi thực thi hàm execute_block lần thứ hai, thực thi dòng mã move đầu tiên là copyloc(57). Do lúc này locals chỉ có độ dài 8, offset 57 không tồn tại, dẫn đến hàm get(57).unwrap() trả về None, cuối cùng gây ra panic.
Tóm tắt
Lỗ hổng này cho thấy không có mã nào hoàn toàn an toàn. Mặc dù ngôn ngữ Move đã thực hiện kiểm tra tĩnh trước khi thực thi mã, nhưng vẫn có thể bị vượt qua bởi lỗ hổng tràn. Điều này một lần nữa nhấn mạnh tầm quan trọng của việc kiểm toán mã.
Đối với ngôn ngữ Move, chúng tôi khuyên nên thêm nhiều mã kiểm tra hơn trong quá trình thực thi để ngăn chặn các tình huống bất ngờ xảy ra. Hiện tại, Move chủ yếu thực hiện kiểm tra an toàn ở giai đoạn xác minh, nhưng một khi việc xác minh bị bỏ qua, thiếu sự gia cố an toàn đầy đủ trong giai đoạn thực thi có thể dẫn đến các vấn đề nghiêm trọng hơn.
Là người dẫn đầu trong nghiên cứu an toàn ngôn ngữ Move, chúng tôi sẽ tiếp tục nghiên cứu sâu về các vấn đề an toàn của Move và sẽ chia sẻ thêm nhiều phát hiện trong thời gian tới.