Phân tích sâu về một lỗ hổng nghiêm trọng khác trong ngôn ngữ Move
Trước đây, chúng tôi đã phát hiện một lỗ hổng nghiêm trọng trong Aptos Moveevm, sau khi nghiên cứu sâu, chúng tôi lại phát hiện một lỗ hổng tràn số nguyên mới. Quá trình kích hoạt lỗ hổng lần này thú vị hơn, dưới đây chúng tôi sẽ phân tích sâu về lỗ hổng này, đồng thời giới thiệu một số kiến thức cơ bản về ngôn ngữ Move. Chắc chắn rằng qua bài viết này, bạn sẽ có sự hiểu biết sâu hơn về ngôn ngữ Move.
Như mọi người đã biết, ngôn ngữ Move sẽ xác minh mã trước khi thực thi bytecode. Quá trình xác minh được chia thành 4 bước, và lỗ hổng này xuất hiện trong bước reference_safety.
Mô-đun reference_safety định nghĩa hàm chuyển đổi được sử dụng để xác minh tính an toàn của các tham chiếu trong quá trình. Kiểm tra của nó bao gồm xác minh không có tham chiếu lơ lửng, truy cập vào các tham chiếu có thể thay đổi có an toàn không, truy cập vào các tham chiếu lưu trữ toàn cầu có an toàn không, v.v.
Hàm vào gọi xác thực an toàn sẽ gọi analyze_function. Trong analyze_function, hàm sẽ xác thực từng khối cơ bản. Khối cơ bản là đoạn mã không có chỉ thị phân nhánh ngoại trừ đầu vào và đầu ra.
Ngôn ngữ Move xác định 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 lặp. Một ví dụ về khối mã IR Move điển hình có thể chứa 3 khối cơ bản, được xác định bởi các lệnh BrTrue, Branch và Ret.
An toàn tham chiếu trong Move
Lấy cảm hứng từ tư tưởng của ngôn ngữ Rust, 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, tham chiếu thay đổi được sử dụng để sửa đổi dữ liệu. Việc sử dụng hợp lý các loại tham chiếu giúp duy trì tính an toàn và nhận diện các mô-đun đọc.
Mô-đun an toàn tham chiếu của Move sẽ quét mã byte của các khối cơ bản trong hàm theo từng hàm, xác minh tất cả các thao tác tham chiếu là hợp pháp. Quá trình xác minh chủ yếu liên quan đến cấu trúc AbstractState, nó bao gồm đồ thị mượn và các biến địa phương, được sử dụng để đảm bảo tính an toàn của các tham chiếu trong hàm.
Quá trình xác minh sẽ so sánh trạng thái trước và sau khi thực hiện khối cơ bản, và sẽ hợp nhất kết quả để cập nhật trạng thái khối, đồng thời truyền điều kiện hậu khối này đến các khối tiếp theo. Quá trình này tương tự như tư tưởng Sea of Nodes trong V8 turbofan.
Vòng lặp chính sẽ thực thi mã khối, sau đó cố gắng hợp nhất trạng thái trước và trạng thái sau. Nếu trạng thái thay đổi và khối hiện tại có một cạnh quay ngược chỉ đến chính nó ( chỉ ra rằng có một vòng lặp ), nó sẽ nhảy về đầu vòng lặp, tiếp tục thực thi khối cơ bản này cho đến khi trạng thái sau bằng trạng thái trước hoặc bị dừng lại do lỗi.
Phân tích lỗ hổng
Lỗi xảy ra trong quá trình xác định xem kết quả join có thay đổi hay không. Hàm join_ được sử dụng để cập nhật biến cục bộ và đồ thị quan hệ borrow. Khi tổng chiều dài tham số hàm cộng với chiều dài biến cục bộ vượt quá 256, do biến local có kiểu u8, sẽ xảy ra tràn khi duyệt qua locals.
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, không bao gồm tham số length. Các nhà phát triển dường như nhận ra cần phải kiểm tra tổng số tham số và giá trị cục bộ, nhưng mã thực tế chỉ kiểm tra số lượng biến cục bộ.
Từ tràn số nguyên đến tấn công DoS
Vòng lặp chính sẽ quét các khối mã và gọi hàm execute_block, sau đó hợp nhất trạng thái trước và sau khi thực hiện. Khi trong mã có vòng lặp, nó sẽ nhảy đến đầu khối mã để thực hiện lại.
Nếu chúng ta xây dựng một khối mã lặp và sử dụng 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 đây, thì khi thực hiện lại execute_block, việc phân tích chuỗi lệnh trong khối cơ bản sẽ truy cập bản đồ locals mới. Lúc này, nếu chỉ mục mà lệnh cần truy cập không tồn tại trong bản đồ mới, sẽ dẫn đến DoS.
Trong mô-đun reference safety, các mã lệnh MoveLoc/CopyLoc/FreeRef có thể đạt được mục tiêu này. Lấy ví dụ về hàm copy_loc, nó sẽ cố gắng lấy giá trị địa phương thông qua LocalIndex, nếu LocalIndex không tồn tại sẽ dẫn đến panic, làm cho toàn bộ nút bị sập.
Trình diễn PoC
Chúng ta có thể xây dựng một khối cơ bản chứa lệnh nhánh vô điều kiện, cho phép gọi nhiều lần các hàm execute_block và join. Bằng cách thiết lập các tham số thích hợp và số lượng biến cục bộ, có thể giảm độ dài của bản đồ locals mới xuống còn 8 sau lần thực thi đầu tiên.
Trong lần thực hiện thứ hai, việc cố gắng truy cập offset không tồn tại sẽ gây ra panic, từ đó kích hoạt DoS.
Tóm tắt
Lỗ hổng này cho thấy ngay cả ngôn ngữ Move đã trải qua kiểm tra tĩnh nghiêm ngặt cũng tồn tại nguy cơ bảo mật. Lỗ hổng tràn có thể vượt qua kiểm tra biên, làm nổi bật tầm quan trọng của việc kiểm toán mã.
Là người dẫn đầu trong nghiên cứu an toàn ngôn ngữ Move, chúng tôi khuyên các nhà thiết kế ngôn ngữ nên thêm nhiều mã kiểm tra hơn vào thời gian chạy Move để ngăn chặn các tình huống không mong muốn 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 trong giai đoạn chạy lại thiếu các biện pháp bảo vệ an toàn đủ, có thể dẫn đến những vấn đề nghiêm trọng hơn.
Chúng tôi cũng đã phát hiện ra một lỗ hổng khác của ngôn ngữ Move, sẽ chia sẻ với mọi người 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 mới trong ngôn ngữ Move: từ an toàn tham chiếu đến tấn công DoS
Phân tích sâu về một lỗ hổng nghiêm trọng khác trong ngôn ngữ Move
Trước đây, chúng tôi đã phát hiện một lỗ hổng nghiêm trọng trong Aptos Moveevm, sau khi nghiên cứu sâu, chúng tôi lại phát hiện một lỗ hổng tràn số nguyên mới. Quá trình kích hoạt lỗ hổng lần này thú vị hơn, dưới đây chúng tôi sẽ phân tích sâu về lỗ hổng này, đồng thời giới thiệu một số kiến thức cơ bản về ngôn ngữ Move. Chắc chắn rằng qua bài viết này, bạn sẽ có sự hiểu biết sâu hơn về ngôn ngữ Move.
Như mọi người đã biết, ngôn ngữ Move sẽ xác minh mã trước khi thực thi bytecode. Quá trình xác minh được chia thành 4 bước, và lỗ hổng này xuất hiện trong bước reference_safety.
Mô-đun reference_safety định nghĩa hàm chuyển đổi được sử dụng để xác minh tính an toàn của các tham chiếu trong quá trình. Kiểm tra của nó bao gồm xác minh không có tham chiếu lơ lửng, truy cập vào các tham chiếu có thể thay đổi có an toàn không, truy cập vào các tham chiếu lưu trữ toàn cầu có an toàn không, v.v.
Hàm vào gọi xác thực an toàn sẽ gọi analyze_function. Trong analyze_function, hàm sẽ xác thực từng khối cơ bản. Khối cơ bản là đoạn mã không có chỉ thị phân nhánh ngoại trừ đầu vào và đầu ra.
Ngôn ngữ Move xác định 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 lặp. Một ví dụ về khối mã IR Move điển hình có thể chứa 3 khối cơ bản, được xác định bởi các lệnh BrTrue, Branch và Ret.
An toàn tham chiếu trong Move
Lấy cảm hứng từ tư tưởng của ngôn ngữ Rust, 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, tham chiếu thay đổi được sử dụng để sửa đổi dữ liệu. Việc sử dụng hợp lý các loại tham chiếu giúp duy trì tính an toàn và nhận diện các mô-đun đọc.
Mô-đun an toàn tham chiếu của Move sẽ quét mã byte của các khối cơ bản trong hàm theo từng hàm, xác minh tất cả các thao tác tham chiếu là hợp pháp. Quá trình xác minh chủ yếu liên quan đến cấu trúc AbstractState, nó bao gồm đồ thị mượn và các biến địa phương, được sử dụng để đảm bảo tính an toàn của các tham chiếu trong hàm.
Quá trình xác minh sẽ so sánh trạng thái trước và sau khi thực hiện khối cơ bản, và sẽ hợp nhất kết quả để cập nhật trạng thái khối, đồng thời truyền điều kiện hậu khối này đến các khối tiếp theo. Quá trình này tương tự như tư tưởng Sea of Nodes trong V8 turbofan.
Vòng lặp chính sẽ thực thi mã khối, sau đó cố gắng hợp nhất trạng thái trước và trạng thái sau. Nếu trạng thái thay đổi và khối hiện tại có một cạnh quay ngược chỉ đến chính nó ( chỉ ra rằng có một vòng lặp ), nó sẽ nhảy về đầu vòng lặp, tiếp tục thực thi khối cơ bản này cho đến khi trạng thái sau bằng trạng thái trước hoặc bị dừng lại do lỗi.
Phân tích lỗ hổng
Lỗi xảy ra trong quá trình xác định xem kết quả join có thay đổi hay không. Hàm join_ được sử dụng để cập nhật biến cục bộ và đồ thị quan hệ borrow. Khi tổng chiều dài tham số hàm cộng với chiều dài biến cục bộ vượt quá 256, do biến local có kiểu u8, sẽ xảy ra tràn khi duyệt qua locals.
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, không bao gồm tham số length. Các nhà phát triển dường như nhận ra cần phải kiểm tra tổng số tham số và giá trị cục bộ, nhưng mã thực tế chỉ kiểm tra số lượng biến cục bộ.
Từ tràn số nguyên đến tấn công DoS
Vòng lặp chính sẽ quét các khối mã và gọi hàm execute_block, sau đó hợp nhất trạng thái trước và sau khi thực hiện. Khi trong mã có vòng lặp, nó sẽ nhảy đến đầu khối mã để thực hiện lại.
Nếu chúng ta xây dựng một khối mã lặp và sử dụng 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 đây, thì khi thực hiện lại execute_block, việc phân tích chuỗi lệnh trong khối cơ bản sẽ truy cập bản đồ locals mới. Lúc này, nếu chỉ mục mà lệnh cần truy cập không tồn tại trong bản đồ mới, sẽ dẫn đến DoS.
Trong mô-đun reference safety, các mã lệnh MoveLoc/CopyLoc/FreeRef có thể đạt được mục tiêu này. Lấy ví dụ về hàm copy_loc, nó sẽ cố gắng lấy giá trị địa phương thông qua LocalIndex, nếu LocalIndex không tồn tại sẽ dẫn đến panic, làm cho toàn bộ nút bị sập.
Trình diễn PoC
Chúng ta có thể xây dựng một khối cơ bản chứa lệnh nhánh vô điều kiện, cho phép gọi nhiều lần các hàm execute_block và join. Bằng cách thiết lập các tham số thích hợp và số lượng biến cục bộ, có thể giảm độ dài của bản đồ locals mới xuống còn 8 sau lần thực thi đầu tiên.
Trong lần thực hiện thứ hai, việc cố gắng truy cập offset không tồn tại sẽ gây ra panic, từ đó kích hoạt DoS.
Tóm tắt
Lỗ hổng này cho thấy ngay cả ngôn ngữ Move đã trải qua kiểm tra tĩnh nghiêm ngặt cũng tồn tại nguy cơ bảo mật. Lỗ hổng tràn có thể vượt qua kiểm tra biên, làm nổi bật tầm quan trọng của việc kiểm toán mã.
Là người dẫn đầu trong nghiên cứu an toàn ngôn ngữ Move, chúng tôi khuyên các nhà thiết kế ngôn ngữ nên thêm nhiều mã kiểm tra hơn vào thời gian chạy Move để ngăn chặn các tình huống không mong muốn 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 trong giai đoạn chạy lại thiếu các biện pháp bảo vệ an toàn đủ, có thể dẫn đến những vấn đề nghiêm trọng hơn.
Chúng tôi cũng đã phát hiện ra một lỗ hổng khác của ngôn ngữ Move, sẽ chia sẻ với mọi người trong thời gian tới.