Phân tích lỗ hổng tràn số nguyên trong mô-đun an toàn của ngôn ngữ Move
Gần đây, khi chúng tôi 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 khá thú vị, dưới đây chúng tôi sẽ phân tích sâu về lỗ hổng này và nhân cơ hội này để thảo luận về một số khái niệm cốt lõi của ngôn ngữ Move.
Ngôn ngữ Move sẽ thực hiện xác minh đơn vị mã trước khi thực thi mã byte, quá trình này được chia thành bốn bước. Lỗ hổng được thảo luận trong bài viết này xảy ra trong bước reference_safety.
Mô-đun reference_safety chủ yếu chịu trách nhiệm xác minh tính an toàn của các tham chiếu trong mã, bao gồm kiểm tra xem có tồn tại tham chiếu lơ lửng hay không, việc truy cập tham chiếu biến có an toàn hay không, và việc truy cập tham chiếu lưu trữ toàn cầu có tuân thủ hay không.
Trong quá trình xác thực an ninh, hệ thống sẽ phân tích từng khối cơ bản. Khối cơ bản là một chuỗi mã không có lệnh nhánh ngoại trừ lệnh vào và lệnh ra. Ngôn ngữ Move xác định các khối cơ bản bằng cách duyệt mã byte, tìm tất cả các lệnh nhánh và chuỗi lệnh vòng lặp.
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, tham chiếu thay đổi được sử dụng để sửa đổi dữ liệu. Thiết kế này giúp nâng cao tính an toàn và khả năng đọc của mã.
Quy trình chính của xác thực an toàn tham chiếu bao gồm: quét các khối cơ bản trong hàm, phân tích các lệnh bytecode, xác định xem tất cả các thao tác tham chiếu có hợp pháp hay không. Quá trình này sử dụng cấu trúc AbstractState, trong đó chứa đồ thị mượn và biến cục bộ, cùng nhau đảm bảo tính an toàn của tham chiếu trong hàm.
Trong quá trình xác thực, trạng thái trước và sau khi thực hiện khối cơ bản sẽ được so sánh ( trạng thái trước và trạng thái sau ), và kết quả sẽ được hợp nhất để cập nhật trạng thái khối. Nếu trạng thái thay đổi và khối hiện tại có cạnh quay trở lại chỉ vào chính nó (cho thấy có vòng lặp), thì khối cơ bản đó sẽ được thực hiện lại, cho đến khi trạng thái không còn thay đổi hoặc xuất hiện lỗi.
Lỗi xảy ra trong quá trình xác định xem kết quả join có thay đổi hay không. Khi tổng chiều dài của tham số hàm và chiều dài biến cục bộ vượt quá 256, do sử dụng loại u8 để biểu diễn chỉ mục cục bộ, có thể dẫn đến tràn số nguyên. Mặc dù ngôn ngữ Move có quá trình kiểm tra số lượng locals, nhưng chỉ kiểm tra số lượng biến cục bộ mà không bao gồm chiều dài tham số.
Lỗ hổng tràn số nguyên này có thể dẫn đến tấn công từ chối dịch vụ (DoS). Kẻ tấn công có thể tạo ra một khối mã lặp, tận dụng sự tràn để thay đổi trạng thái của khối, khiến bản đồ locals mới khác với trước đó. Khi thực thi lại hàm execute_block, 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ẽ gây ra panic, dẫn đến việc toàn bộ nút bị sập.
Để minh họa lỗ hổng này, chúng tôi cung cấp một PoC có thể tái hiện trong git. PoC này bao gồm một khối cơ bản có chỉ thị nhánh vô điều kiện, có thể kích hoạt nhiều lần các hàm execute_block và join. Bằng cách thiết lập cẩn thận các tham số và số lượng biến cục bộ, có thể giảm chiều dài map locals mới xuống còn 8, sau đó kích hoạt panic vào lần thực thi thứ hai.
Lỗ hổng này một lần nữa chứng minh rằng không có mã nào hoàn toàn an toàn. Mặc dù ngôn ngữ Move đã trải qua kiểm tra tĩnh nghiêm ngặt trước khi thực thi, nhưng vẫn có thể bị vượt qua bởi các lỗ hổng tràn. Điều này cũng nhấn mạnh tầm quan trọng của việc kiểm toán mã, cũng như sự cần thiết phải thêm các kiểm tra an toàn trong thời gian chạy vào thiết kế ngôn ngữ.
Là những 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à đề xuất các nhà thiết kế ngôn ngữ thêm nhiều mã kiểm tra hơn vào thời gian chạy của Move để ngăn chặn các tình huống bất ngờ xảy ra. Hiện tại, ngôn ngữ Move chủ yếu thực hiện kiểm tra an toàn trong giai đoạn xác minh, nhưng chúng tôi cho rằng điều này vẫn chưa đủ. Khi việc xác minh bị bỏ qua, việc thiếu các biện pháp an toàn đủ trong giai đoạn chạy có thể dẫn đến những vấn đề nghiêm trọng hơn.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 thích
Phần thưởng
13
5
Chia sẻ
Bình luận
0/400
FUD_Whisperer
· 7giờ trước
Sao vẫn còn nhiều lỗ hổng thế này, làm tâm lý.
Xem bản gốcTrả lời0
LadderToolGuy
· 07-06 19:13
Quả thật có không ít lỗi tràn.
Xem bản gốcTrả lời0
MetaverseMigrant
· 07-06 17:57
Lại khiến tôi cảm thấy như quay trở lại lúc thử nghiệm Solana vào năm 2021.
Lỗi tràn số nguyên trong mô-đun bảo mật của ngôn ngữ Move có thể dẫn đến cuộc tấn công DoS
Phân tích lỗ hổng tràn số nguyên trong mô-đun an toàn của ngôn ngữ Move
Gần đây, khi chúng tôi 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 khá thú vị, dưới đây chúng tôi sẽ phân tích sâu về lỗ hổng này và nhân cơ hội này để thảo luận về một số khái niệm cốt lõi của ngôn ngữ Move.
Ngôn ngữ Move sẽ thực hiện xác minh đơn vị mã trước khi thực thi mã byte, quá trình này được chia thành bốn bước. Lỗ hổng được thảo luận trong bài viết này xảy ra trong bước reference_safety.
Mô-đun reference_safety chủ yếu chịu trách nhiệm xác minh tính an toàn của các tham chiếu trong mã, bao gồm kiểm tra xem có tồn tại tham chiếu lơ lửng hay không, việc truy cập tham chiếu biến có an toàn hay không, và việc truy cập tham chiếu lưu trữ toàn cầu có tuân thủ hay không.
Trong quá trình xác thực an ninh, hệ thống sẽ phân tích từng khối cơ bản. Khối cơ bản là một chuỗi mã không có lệnh nhánh ngoại trừ lệnh vào và lệnh ra. Ngôn ngữ Move xác định các khối cơ bản bằng cách duyệt mã byte, tìm tất cả các lệnh nhánh và chuỗi lệnh vòng lặp.
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, tham chiếu thay đổi được sử dụng để sửa đổi dữ liệu. Thiết kế này giúp nâng cao tính an toàn và khả năng đọc của mã.
Quy trình chính của xác thực an toàn tham chiếu bao gồm: quét các khối cơ bản trong hàm, phân tích các lệnh bytecode, xác định xem tất cả các thao tác tham chiếu có hợp pháp hay không. Quá trình này sử dụng cấu trúc AbstractState, trong đó chứa đồ thị mượn và biến cục bộ, cùng nhau đảm bảo tính an toàn của tham chiếu trong hàm.
Trong quá trình xác thực, trạng thái trước và sau khi thực hiện khối cơ bản sẽ được so sánh ( trạng thái trước và trạng thái sau ), và kết quả sẽ được hợp nhất để cập nhật trạng thái khối. Nếu trạng thái thay đổi và khối hiện tại có cạnh quay trở lại chỉ vào chính nó (cho thấy có vòng lặp), thì khối cơ bản đó sẽ được thực hiện lại, cho đến khi trạng thái không còn thay đổi hoặc xuất hiện lỗi.
Lỗi xảy ra trong quá trình xác định xem kết quả join có thay đổi hay không. Khi tổng chiều dài của tham số hàm và chiều dài biến cục bộ vượt quá 256, do sử dụng loại u8 để biểu diễn chỉ mục cục bộ, có thể dẫn đến tràn số nguyên. Mặc dù ngôn ngữ Move có quá trình kiểm tra số lượng locals, nhưng chỉ kiểm tra số lượng biến cục bộ mà không bao gồm chiều dài tham số.
Lỗ hổng tràn số nguyên này có thể dẫn đến tấn công từ chối dịch vụ (DoS). Kẻ tấn công có thể tạo ra một khối mã lặp, tận dụng sự tràn để thay đổi trạng thái của khối, khiến bản đồ locals mới khác với trước đó. Khi thực thi lại hàm execute_block, 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ẽ gây ra panic, dẫn đến việc toàn bộ nút bị sập.
Để minh họa lỗ hổng này, chúng tôi cung cấp một PoC có thể tái hiện trong git. PoC này bao gồm một khối cơ bản có chỉ thị nhánh vô điều kiện, có thể kích hoạt nhiều lần các hàm execute_block và join. Bằng cách thiết lập cẩn thận các tham số và số lượng biến cục bộ, có thể giảm chiều dài map locals mới xuống còn 8, sau đó kích hoạt panic vào lần thực thi thứ hai.
Lỗ hổng này một lần nữa chứng minh rằng không có mã nào hoàn toàn an toàn. Mặc dù ngôn ngữ Move đã trải qua kiểm tra tĩnh nghiêm ngặt trước khi thực thi, nhưng vẫn có thể bị vượt qua bởi các lỗ hổng tràn. Điều này cũng nhấn mạnh tầm quan trọng của việc kiểm toán mã, cũng như sự cần thiết phải thêm các kiểm tra an toàn trong thời gian chạy vào thiết kế ngôn ngữ.
Là những 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à đề xuất các nhà thiết kế ngôn ngữ thêm nhiều mã kiểm tra hơn vào thời gian chạy của Move để ngăn chặn các tình huống bất ngờ xảy ra. Hiện tại, ngôn ngữ Move chủ yếu thực hiện kiểm tra an toàn trong giai đoạn xác minh, nhưng chúng tôi cho rằng điều này vẫn chưa đủ. Khi việc xác minh bị bỏ qua, việc thiếu các biện pháp an toàn đủ trong giai đoạn chạy có thể dẫn đến những vấn đề nghiêm trọng hơn.