9 trong số 10 chuỗi TVL hàng đầu hỗ trợ hợp đồng thông minh EVM.
Original title: "How to Uate Forked EVMs for Security Risks"
撰文：Ethan Pociask、Eric Meng、Nadir Akhtar、Gabriela Melendez Quan、Tom Ryan
Biên dịch: Katie Koo
Để 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 sẽ xem xét các thay đổi EVM chính để xác định xem EVM đã sửa đổi có thể cung cấp các đảm bảo về bảo mật và lưu ký giống như triển khai EVM ban đầu hay không.
Trạng thái EVM rẽ nhánh
Kể từ tháng 5 năm 2023, Máy ảo Ethereum (EVM) đã giành được danh hiệu "Anh cả" của 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 Total Value Locked (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 trong toàn bộ 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 triển khai 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 đó nói rằng, forking và sửa đổi EVM thực sự khá phổ biến trong hệ sinh thái blockchain, ngay cả trong các giao thức chính. Ví dụ: Ngăn xếp nền tảng lạc quan "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 gọi là op-geth, chạy cùng một EVM 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ự).
Mặc dù điều này nghe có vẻ đáng sợ, nhưng nó thường có lợi cho việc áp dụng EVM. Mặc dù việc triển khai EVM tiêu chuẩn được tối ưu hóa cao cho giao thức Ethereum cơ bản, nhưng các EVM rẽ nhánh thường mở rộng nó cho các giao thức mới của riêng chúng. Do đó, 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 về 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.
Phân nhánh 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 của 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, sẽ đượ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;
Cung cấp cho kiểm toán viên hợp đồng thông minh bản phân tích về tình trạng lỗ hổng hợp đồng thông minh của EVM rẽ nhánh, đặc biệt là những khác biệt nhỏ trong mạng chéo;
Đảm bảo việc sử dụng và thực hiện 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 chuẩn bảo mật cho các chuỗi khối tương thích với EVM
Để hiểu các rủi ro bảo mật tồn tại như thế nào trong máy ảo Ethereum, trước tiên chúng ta phải biết điều gì đảm bảo việc triển khai EVM tiêu chuẩn cung cấp cho chúng ta. Chúng tôi xác định EVM tiêu chuẩn là EVM được sử dụng nhất quán bởi các máy khách thực thi trình xác thực Ethereum như được mô tả trong Đặc tả triển khai Ethereum. Cho đến nay, ứng dụng khách được sử dụng nhiều nhất là ethereum (tức là geth).
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.
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 (x1 + x2) để trừ hai giá trị (x1 - x2).
Do đó, EVM' bị lệch là không bình đẳng 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 các chức năng phức tạp (chẳng hạn như chức năng mã hóa), 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à bất kỳ thay đổi nào đối với 9 trình biên dịch trước này hoặc việc giới thiệu các trình biên dịch trước mới đều cần đượ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 triển khai go-ethereum sai lệch để 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 quá trình xác minh. 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 trước mới để thực hiện EVM sai lệch.
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 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;
Cung cấp quyền truy cập vào giá trị trong 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 sẵn đầu tiên (ecrecover, sha256 và &ripemd) được chuyển qua Solidity. đại diện trong ngôn ngữ. Đằ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);
Giả định về vị trí tiền biên dịch của trình biên dịch Solidity là 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 trình thông dịch 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 thực thi không xác định;
Bỏ qua kiểm soát truy cập, cho phép bất kỳ đối tác nào đơn phương truy cập vào tất cả các trạng thái chuỗi;
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.
Tại sao chúng ta nên quan tâm đến bảo mật EVM?
Mục tiêu của chúng tôi là xây dựng một hệ thống tài chính mở dựa trên công nghệ chuỗi khối và để đạt được mục tiêu này, chúng tôi khuyến khích phát triển các triển khai EVM khác nhau. Tuy nhiên, để một chuỗi khối tuân thủ EVM được Coinbase hỗ trợ đầy đủ, nó phải đáp ứng các yêu cầu cơ bản của việc triển khai EVM tiêu chuẩn. Bài báo này hy vọng sẽ nâng cao nhận thức về các rủi ro liên quan đến việc đi chệch khỏi EVM và khuyến khích các nhà phát hành tài sản ưu tiên phát triển các thành phần bảo mật khi đi chệch khỏi EVM, nâng cao nhận thức về bảo mật trên toàn bộ hệ sinh thái Web3.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Làm cách nào để đánh giá rủi ro bảo mật của "EVM rẽ nhánh"?
Original title: "How to Uate Forked EVMs for Security Risks"
撰文：Ethan Pociask、Eric Meng、Nadir Akhtar、Gabriela Melendez Quan、Tom Ryan
Biên dịch: Katie Koo
Để 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 sẽ xem xét các thay đổi EVM chính để xác định xem EVM đã sửa đổi có thể cung cấp các đảm bảo về bảo mật và lưu ký giống như triển khai EVM ban đầu hay không.
Trạng thái EVM rẽ nhánh
Kể từ tháng 5 năm 2023, Máy ảo Ethereum (EVM) đã giành được danh hiệu "Anh cả" của 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 Total Value Locked (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 trong toàn bộ 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 triển khai 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 đó nói rằng, forking và sửa đổi EVM thực sự khá phổ biến trong hệ sinh thái blockchain, ngay cả trong các giao thức chính. Ví dụ: Ngăn xếp nền tảng lạc quan "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 gọi là op-geth, chạy cùng một EVM 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ự).
Mặc dù điều này nghe có vẻ đáng sợ, nhưng nó thường có lợi cho việc áp dụng EVM. Mặc dù việc triển khai EVM tiêu chuẩn được tối ưu hóa cao cho giao thức Ethereum cơ bản, nhưng các EVM rẽ nhánh thường mở rộng nó cho các giao thức mới của riêng chúng. Do đó, 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 về 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.
Phân nhánh 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 của 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, sẽ đượ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ể:
Tiêu chuẩn bảo mật cho các chuỗi khối tương thích với EVM
Để hiểu các rủi ro bảo mật tồn tại như thế nào trong máy ảo Ethereum, trước tiên chúng ta phải biết điều gì đảm bảo việc triển khai EVM tiêu chuẩn cung cấp cho chúng ta. Chúng tôi xác định EVM tiêu chuẩn là EVM được sử dụng nhất quán bởi các máy khách thực thi trình xác thực Ethereum như được mô tả trong Đặc tả triển khai Ethereum. Cho đến nay, ứng dụng khách được sử dụng nhiều nhất là ethereum (tức là geth).
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.
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 (x1 + x2) để trừ hai giá trị (x1 - x2).
Do đó, EVM' bị lệch là không bình đẳng 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 các chức năng phức tạp (chẳng hạn như chức năng mã hóa), 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à bất kỳ thay đổi nào đối với 9 trình biên dịch trước này hoặc việc giới thiệu các trình biên dịch trước mới đều cần đượ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 triển khai go-ethereum sai lệch để 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 quá trình xác minh. 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 trước mới để thực hiện EVM sai lệch.
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:
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 sẵn đầu tiên (ecrecover, sha256 và &ripemd) được chuyển qua Solidity. đại diện trong ngôn ngữ. Đằ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:
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:
Tại sao chúng ta nên quan tâm đến bảo mật EVM?
Mục tiêu của chúng tôi là xây dựng một hệ thống tài chính mở dựa trên công nghệ chuỗi khối và để đạt được mục tiêu này, chúng tôi khuyến khích phát triển các triển khai EVM khác nhau. Tuy nhiên, để một chuỗi khối tuân thủ EVM được Coinbase hỗ trợ đầy đủ, nó phải đáp ứng các yêu cầu cơ bản của việc triển khai EVM tiêu chuẩn. Bài báo này hy vọng sẽ nâng cao nhận thức về các rủi ro liên quan đến việc đi chệch khỏi EVM và khuyến khích các nhà phát hành tài sản ưu tiên phát triển các thành phần bảo mật khi đi chệch khỏi EVM, nâng cao nhận thức về bảo mật trên toàn bộ hệ sinh thái Web3.