Phân tích lỗ hổng của trình biên dịch Solidity và các chiến lược ứng phó
Trình biên dịch là một phần quan trọng của hệ thống máy tính hiện đại, có chức năng chuyển đổi mã nguồn của ngôn ngữ lập trình cấp cao thành mã lệnh có thể thực thi bởi máy tính. So với mã ứng dụng, tính an toàn của chính trình biên dịch thường dễ bị bỏ qua. Tuy nhiên, lỗ hổng trong trình biên dịch có thể mang lại rủi ro an ninh nghiêm trọng trong một số trường hợp.
Chức năng chính của trình biên dịch Solidity là chuyển đổi mã hợp đồng thông minh thành các lệnh của máy ảo Ethereum (EVM). Khác với các lỗ hổng của chính EVM, các lỗ hổng của trình biên dịch Solidity chủ yếu ảnh hưởng đến các nhà phát triển hợp đồng thông minh, và không gây nguy hiểm trực tiếp đến an ninh mạng Ethereum.
Lỗi biên dịch có thể dẫn đến mã EVM được tạo ra không phù hợp với mong đợi của nhà phát triển. Vì hợp đồng thông minh thường liên quan đến tài sản tiền điện tử, bất kỳ lỗi nào do trình biên dịch gây ra đều có thể dẫn đến thiệt hại tài sản của người dùng. Chỉ thông qua việc kiểm tra mã nguồn hợp đồng rất khó để phát hiện những vấn đề này, cần phải kết hợp với phiên bản trình biên dịch cụ thể và mô hình mã để tiến hành phân tích.
Ví dụ về lỗ hổng biên dịch Solidity
SOL-2016-9 HighOrderByteCleanStorage
Lỗ hổng này tồn tại trong các phiên bản biên dịch Solidity sớm hơn (>=0.1.6 <0.4.4). Trong một số trường hợp, các biến storage có thể bị thay đổi một cách không mong muốn, dẫn đến giá trị trả về của hàm không khớp với mong đợi. Sự không nhất quán này có thể gây ra hậu quả nghiêm trọng trong các tình huống liên quan đến xác thực quyền hạn hoặc kế toán tài sản.
Nguyên nhân gây ra lỗ hổng là do trình biên dịch không xóa đúng dữ liệu cao khi xử lý kiểu dữ liệu nhỏ hơn 32 byte, dẫn đến việc khi tràn số nguyên, dữ liệu cao bị ghi sai vào biến liền kề.
SOL-2022-4 InlineAssemblyMemorySideEffects
Lỗ hổng này ảnh hưởng đến các phiên bản trình biên dịch >=0.8.13 <0.8.15. Vấn đề bắt nguồn từ việc xử lý sai các thao tác bộ nhớ trong quá trình tối ưu hóa của trình biên dịch. Trong một số trường hợp, trình biên dịch có thể sai lầm loại bỏ các chỉ thị ghi bộ nhớ dường như thừa, dẫn đến giá trị trả về của hàm bất thường.
Lỗ hổng này tồn tại trong các phiên bản biên dịch viên từ >= 0.5.8 đến < 0.8.16. Khi thực hiện thao tác abi.encode trên mảng kiểu calldata, biên dịch viên đã xóa bỏ một số dữ liệu một cách sai lầm, dẫn đến việc dữ liệu liền kề bị thay đổi, gây ra sự không nhất quán giữa dữ liệu được mã hóa và giải mã.
Cần lưu ý rằng khi gọi external call và emit event sẽ được thực hiện abi.encode một cách ngầm định, do đó phạm vi ảnh hưởng của lỗ hổng này có thể rộng hơn dự kiến.
Đề xuất an toàn
Đối với lỗ hổng của trình biên dịch Solidity, đội ngũ an ninh blockchain Cobo đưa ra các khuyến nghị sau:
Dành cho các nhà phát triển:
Sử dụng phiên bản trình biên dịch Solidity mới hơn
Hoàn thiện các trường hợp kiểm tra đơn vị, nâng cao tỷ lệ bao phủ mã
Tránh sử dụng lắp ghép nội tuyến, giải mã abi phức tạp và các thao tác tương tự, hãy thận trọng khi sử dụng các tính năng mới và chức năng thử nghiệm.
Đối với nhân viên an ninh:
Chú ý đến các rủi ro bảo mật có thể do trình biên dịch gây ra trong quá trình kiểm toán
Thúc đẩy nâng cấp phiên bản biên dịch viên trong quy trình phát triển, cân nhắc việc giới thiệu kiểm tra phiên bản tự động trong CI/CD
Đánh giá tác động an toàn thực tế của lỗ hổng biên dịch viên dựa trên dự án cụ thể
Tài nguyên thực tiễn:
Blog cảnh báo an toàn chính thức của Solidity
Danh sách lỗi trong kho lưu trữ GitHub của Solidity
Danh sách lỗi biên dịch viên các phiên bản
Thông báo lỗ hổng trình biên dịch trên trang mã hợp đồng Etherscan
Tóm lại, các nhà phát triển và nhân viên an ninh nên chú ý đến rủi ro mà lỗ hổng biên dịch Solidity có thể mang lại, thực hiện các biện pháp tương ứng để giảm thiểu nguy cơ an ninh. Đồng thời cũng cần đánh giá một cách khách quan những tác động cụ thể, tránh hoảng loạn quá mức.
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.
13 thích
Phần thưởng
13
4
Chia sẻ
Bình luận
0/400
AirdropChaser
· 08-02 03:03
又一个 được chơi cho Suckers 的理由出现了
Xem bản gốcTrả lời0
BearMarketBuilder
· 08-02 02:55
Ôi, cả ngày phát triển chỉ sợ cái này.
Xem bản gốcTrả lời0
TeaTimeTrader
· 08-02 02:53
Văn học đổ lỗi cho biên dịch viên có ổn không?
Xem bản gốcTrả lời0
0xOverleveraged
· 08-02 02:42
Cỏ Biên dịch viên đều không đáng tin cậy, còn chơi hợp đồng gì nữa.
Phân tích lỗ hổng biên dịch Solidity: Rủi ro tiềm ẩn mà các nhà phát triển không thể bỏ qua
Phân tích lỗ hổng của trình biên dịch Solidity và các chiến lược ứng phó
Trình biên dịch là một phần quan trọng của hệ thống máy tính hiện đại, có chức năng chuyển đổi mã nguồn của ngôn ngữ lập trình cấp cao thành mã lệnh có thể thực thi bởi máy tính. So với mã ứng dụng, tính an toàn của chính trình biên dịch thường dễ bị bỏ qua. Tuy nhiên, lỗ hổng trong trình biên dịch có thể mang lại rủi ro an ninh nghiêm trọng trong một số trường hợp.
Chức năng chính của trình biên dịch Solidity là chuyển đổi mã hợp đồng thông minh thành các lệnh của máy ảo Ethereum (EVM). Khác với các lỗ hổng của chính EVM, các lỗ hổng của trình biên dịch Solidity chủ yếu ảnh hưởng đến các nhà phát triển hợp đồng thông minh, và không gây nguy hiểm trực tiếp đến an ninh mạng Ethereum.
Lỗi biên dịch có thể dẫn đến mã EVM được tạo ra không phù hợp với mong đợi của nhà phát triển. Vì hợp đồng thông minh thường liên quan đến tài sản tiền điện tử, bất kỳ lỗi nào do trình biên dịch gây ra đều có thể dẫn đến thiệt hại tài sản của người dùng. Chỉ thông qua việc kiểm tra mã nguồn hợp đồng rất khó để phát hiện những vấn đề này, cần phải kết hợp với phiên bản trình biên dịch cụ thể và mô hình mã để tiến hành phân tích.
Ví dụ về lỗ hổng biên dịch Solidity
SOL-2016-9 HighOrderByteCleanStorage
Lỗ hổng này tồn tại trong các phiên bản biên dịch Solidity sớm hơn (>=0.1.6 <0.4.4). Trong một số trường hợp, các biến storage có thể bị thay đổi một cách không mong muốn, dẫn đến giá trị trả về của hàm không khớp với mong đợi. Sự không nhất quán này có thể gây ra hậu quả nghiêm trọng trong các tình huống liên quan đến xác thực quyền hạn hoặc kế toán tài sản.
Nguyên nhân gây ra lỗ hổng là do trình biên dịch không xóa đúng dữ liệu cao khi xử lý kiểu dữ liệu nhỏ hơn 32 byte, dẫn đến việc khi tràn số nguyên, dữ liệu cao bị ghi sai vào biến liền kề.
SOL-2022-4 InlineAssemblyMemorySideEffects
Lỗ hổng này ảnh hưởng đến các phiên bản trình biên dịch >=0.8.13 <0.8.15. Vấn đề bắt nguồn từ việc xử lý sai các thao tác bộ nhớ trong quá trình tối ưu hóa của trình biên dịch. Trong một số trường hợp, trình biên dịch có thể sai lầm loại bỏ các chỉ thị ghi bộ nhớ dường như thừa, dẫn đến giá trị trả về của hàm bất thường.
SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
Lỗ hổng này tồn tại trong các phiên bản biên dịch viên từ >= 0.5.8 đến < 0.8.16. Khi thực hiện thao tác abi.encode trên mảng kiểu calldata, biên dịch viên đã xóa bỏ một số dữ liệu một cách sai lầm, dẫn đến việc dữ liệu liền kề bị thay đổi, gây ra sự không nhất quán giữa dữ liệu được mã hóa và giải mã.
Cần lưu ý rằng khi gọi external call và emit event sẽ được thực hiện abi.encode một cách ngầm định, do đó phạm vi ảnh hưởng của lỗ hổng này có thể rộng hơn dự kiến.
Đề xuất an toàn
Đối với lỗ hổng của trình biên dịch Solidity, đội ngũ an ninh blockchain Cobo đưa ra các khuyến nghị sau:
Dành cho các nhà phát triển:
Đối với nhân viên an ninh:
Tài nguyên thực tiễn:
Tóm lại, các nhà phát triển và nhân viên an ninh nên chú ý đến rủi ro mà lỗ hổng biên dịch Solidity có thể mang lại, thực hiện các biện pháp tương ứng để giảm thiểu nguy cơ an ninh. Đồng thời cũng cần đánh giá một cách khách quan những tác động cụ thể, tránh hoảng loạn quá mức.