Làm cách nào để đánh giá rủi ro bảo mật của "EVM rẽ nhánh"?

Odaily资深作者

2023-05-30 09:35

Bài viết này có khoảng 2306 từ, đọc toàn bộ bài viết mất khoảng 4 phút

9 trong số 10 chuỗi TVL hàng đầu hỗ trợ hợp đồng thông minh EVM.

Bài viết này đến từ CoinbaseBài viết này đến từ

Để tăng cường bảo mật và đảm bảo lưu ký cho khách hàng giao dịch ERC-20 và các tài sản dựa trên hợp đồng thông minh khác, nhóm Bảo mật Chuỗi khối Coinbase đã điều tra lớp lập trình xác định hành vi của các tài sản này: Máy ảo Ethereum (EVM). Khi đánh giá các dự án sửa đổi EVM của mạng riêng của họ, nhóm bảo mật chuỗi khối của Coinbase xem xét các thay đổi EVM chính để xác định xem EVM đã sửa đổi có thể cung cấp bảo mật và đảm bảo lưu ký giống như triển khai EVM ban đầu hay không.

tiêu đề phụ

Trạng thái EVM rẽ nhánh

Kể từ tháng 5 năm 2023, Máy ảo Ethereum (EVM) đã khẳng định danh hiệu "Người anh lớn" cho nền tảng thực thi hợp đồng thông minh phổ biến nhất. Theo DefiLlama, 9 trong số 10 chuỗi hàng đầu theo tổng giá trị bị khóa (TVL) hỗ trợ hợp đồng thông minh EVM. Do đó, hiểu biết sâu sắc về EVM là rất quan trọng để hỗ trợ các hợp đồng thông minh trên toàn hệ sinh thái chuỗi khối.

EVM là một máy ảo để thực thi phi tập trung các hợp đồng thông minh trên mạng Ethereum. Nhiều chuỗi khối tương thích với EVM tận dụng triển khai tiêu chuẩn của các ứng dụng khách thực thi Ethereum phổ biến bằng các ngôn ngữ khác nhau như go-ethereum (Golang) và besu (Java) trực tiếp trong phần mềm giao thức của họ.Điều đó có nghĩa là,Việc rẽ nhánh và sửa đổi EVM thực sự rất phổ biến trong hệ sinh thái chuỗi khối, ngay cả trong các giao thức chính

. Ví dụ: Ngăn xếp lạc quan Bedrock, "cung cấp năng lượng" cho chuỗi khối Base L2 của Coinbase, sử dụng một nhánh của ứng dụng khách thực thi go-ethereum có tên op-geth, chạy EVM giống với ứng dụng khách thực thi ethereum phổ biến tương thích. Tuy nhiên, điều này không có nghĩa là EVM trên Ethereum hoạt động giống hệt như EVM trên Optimism: EVM op-geth hoạt động hơi khác trong một số trường hợp (tức là KHÓ trả về các giá trị ngẫu nhiên được xác định bởi trình sắp xếp thứ tự).Các hợp đồng có thể thực thi khác nhau trên một số chuỗi tương thích với EVM so với trên Ethereum và các giả định bảo mật cho hành vi của hợp đồng thông minh EVM cũng có thể rất khác nhau giữa các giao thức khác nhau.

tiêu đề phụ

Chuyển đổi khung bảo mật EVM

Để đạt được mục tiêu này, Coinbase đã phát triển khung bảo mật Web3 để đánh giá tác động bảo mật trong một số triển khai EVM rẽ nhánh. Chúng tôi gọi nó là khung EVM rẽ nhánh của Coinbase, được giải thích chi tiết bên dưới.

Với khung bảo mật EVM rẽ nhánh này, Coinbase có thể:
Hiểu được tính không hợp lệ của các giả định bảo mật của khung mã thông báo Ethereum của chúng tôi cho phép chúng tôi kích hoạt một cách an toàn các chuỗi khối mới tương thích với EVM để hỗ trợ mã thông báo ERC-20/ERC-721 trên các sàn giao dịch phi tập trung của chúng tôi;
Đảm bảo sử dụng và thực thi an toàn các hợp đồng thông minh EVM trên chuỗi khối Base L2 của Coinbase.

tiêu đề phụ

Một tiêu chuẩn bảo mật cho các chuỗi khối tương thích với EVM

Chúng tôi tóm tắt bảo mật thành hai tiêu chí bảo mật đại diện cho các yêu cầu tối thiểu đối với bất kỳ triển khai EVM rẽ nhánh nào để đủ điều kiện nhận hỗ trợ của Coinbase.

tiêu đề phụ

Làm cách nào để chúng tôi kiểm tra các rủi ro bảo mật khi triển khai EVM?

Khung EVM rẽ nhánh của chúng tôi tập trung vào các yêu cầu kiểm tra sau đây khi đánh giá việc tuân thủ các tiêu chí bảo mật tổng thể (nghĩa là tính bất biến của hợp đồng và môi trường thực thi an toàn). Cần lưu ý rằng các thành phần rủi ro sau đây không phải là phạm vi đầy đủ của kiểm toán EVM fork.

Việc sửa đổi định nghĩa và mã hóa của opcode EVM có thể dẫn đến sự khác biệt đáng kể trong cách thực thi hợp đồng. Ví dụ: giả sử một số triển khai EVM rẽ nhánh (EVM') thay đổi opcode THÊM số học để xác định logic (x 1 + x 2 ) để trừ hai giá trị (x 1 - x 2 ).

Do đó, EVM' sai lệch không bằng nhau và không tương thích khi thực thi với EVM tiêu chuẩn. Hậu quả của việc sửa đổi opcodes có thể là hành vi có lợi, chẳng hạn như ngăn tràn và tràn số nguyên trong opcodes số học hoặc hành vi nguy hiểm hơn, chẳng hạn như hành vi tự hủy gây ra việc đúc tài sản cục bộ vô hạn.

EVM sử dụng các hợp đồng được biên dịch trước để xác định chức năng phức tạp (chẳng hạn như chức năng mật mã), sử dụng ngôn ngữ hiệu quả và thuận tiện hơn như Golang, thay vì sử dụng mã byte EVM ít truy cập hơn.

Về cơ bản, đây là các chức năng được lập trình được truy cập thông qua các địa chỉ chuỗi được xác định trước được thể hiện trong phần mềm nút. Có 9 trình biên dịch trước được xác định trong Sách vàng Ethereum (kể từ tháng 5 năm 2023) và mọi thay đổi đối với 9 trình biên dịch trước này hoặc giới thiệu các trình biên dịch trước mới đều phải được kiểm tra.

Hãy lấy một ví dụ cụ thể khác — lỗ hổng BNB Smart Chain. Chuỗi thông minh BNB sử dụng cách triển khai sai lệch của go-ethereum để chạy các nút. Để đạt được mục tiêu này, hai hợp đồng mới được biên dịch trước (tmHeaderValidate, iavlMerkleProofValidate) được giới thiệu, sử dụng phần mềm của bên thứ ba (tức là Cosmos SDK) để thực hiện xác thực khối ứng dụng nhẹ và xác thực bằng chứng Merkle. Vấn đề là phần mềm Cosmos SDK có một lỗi triển khai trong biểu diễn cây IAWL của nó cho phép các bằng chứng không hợp lệ về mật mã vượt qua xác thực. Nói cách khác, bất kỳ ai cũng có thể tạo ra tiền từ không khí. Những kẻ tấn công đã có thể khai thác lỗ hổng triển khai này được lồng trong trình biên dịch trước iavlMerkleProofValidate để bòn rút hàng trăm triệu đô la từ cầu nối chuỗi chéo Binance.

Ví dụ khai thác này nhằm chứng minh sự cần thiết của bảo mật trình biên dịch trước và các rủi ro tiềm ẩn khi giới thiệu các hợp đồng được biên dịch sẵn mới để làm sai lệch triển khai EVM.

Các rủi ro có thể gây tử vong khi giới thiệu các trình biên dịch trước bổ sung bao gồm:
Cho phép một bên đơn phương sửa đổi trạng thái của bất kỳ hợp đồng đã triển khai nào;
Điều này bao gồm tất cả các sửa đổi bộ nhớ (chèn, cập nhật, xóa);
Sử dụng các phụ thuộc bên thứ ba không đáng tin cậy, chưa được xác minh hoặc chưa được kiểm tra;

Cung cấp quyền truy cập vào các giá trị trong một nút không xác định.

Mặc dù coi trình biên dịch và EVM là các thực thể hoàn toàn riêng biệt, điều đáng chú ý là trình biên dịch Solidity đưa ra các giả định nghiêm ngặt về hành vi của ba hợp đồng được biên dịch trước đầu tiên (ecrecover, sha 256 và &ripemd), được chuyển qua biểu diễn hàm từ khóa ngôn ngữ bản địa trong ngôn ngữ Solidity. Đằng sau hậu trường, trình biên dịch Solidity thực sự xử lý các từ khóa này thành mã byte, thực thi các cuộc gọi tĩnh giữa các hợp đồng. Sơ đồ dưới đây minh họa thêm cách giao tiếp này giữa các hợp đồng.

Rủi ro bảo mật được đưa ra bằng cách sửa đổi trình biên dịch trước tiêu chuẩn bao gồm:
Cho phép các đối tác tập trung đơn phương sửa đổi trạng thái của bất kỳ hợp đồng đã triển khai nào;
Điều này bao gồm tất cả các sửa đổi bộ nhớ (chèn, cập nhật, xóa);
Các giả định về vị trí được biên dịch trước của trình biên dịch Solidity không nhất quán;
Cung cấp quyền truy cập vào các giá trị trong các nút không xác định;

Sử dụng các phụ thuộc của bên thứ ba không đáng tin cậy, chưa được xác minh hoặc chưa được kiểm tra.

Các rủi ro chính do sửa đổi các thành phần cơ bản của EVM bao gồm:
không hạn chế ngăn xếp thông dịch viên phải lớn vô hạn;
Thay đổi kích thước hoặc thay đổi mô hình bộ nhớ có thể dẫn đến việc thực thi không xác định;
Sử dụng các phụ thuộc của bên thứ ba không đáng tin cậy, chưa được xác minh hoặc chưa được kiểm tra.