Phân tích lỗ hổng 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 trong những thành phần cơ bản của hệ thống máy tính hiện đại, chức năng chính của nó là 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 CPU hoặc máy ảo của máy tính.

Mặc dù hầu hết các nhà phát triển và nhân viên an ninh thường chú trọng hơn đến tính bảo mật của mã ứng dụng, nhưng tính bảo mật của chính trình biên dịch cũng quan trọng không kém. Là một chương trình máy tính, trình biên dịch cũng có thể tồn tại các lỗ hổng bảo mật, và trong một số trường hợp, điều này có thể mang đến những rủi ro an ninh nghiêm trọng.

Lấy trình duyệt làm ví dụ, trong quá trình biên dịch và thực thi mã JavaScript phía trước, có thể do lỗ hổng của trình thông dịch JavaScript, dẫn đến việc người dùng khi truy cập vào trang web độc hại có thể bị kẻ tấn công lợi dụng lỗ hổng để thực hiện mã từ xa, cuối cùng kiểm soát trình duyệt của nạn nhân thậm chí cả hệ điều hành. Ngoài ra, lỗi của trình biên dịch C++ cũng có thể dẫn đến việc thực thi mã từ xa và các hậu quả nghiêm trọng khác.

Trình biên dịch Solidity cũng có lỗ hổng bảo mật. Theo cảnh báo an ninh của nhóm phát triển Solidity, nhiều phiên bản của trình biên dịch Solidity đều có lỗ hổng bảo mật.

Lỗ hổng trình biên dịch Solidity

Vai trò của trình biên dịch Solidity là chuyển đổi mã hợp đồng thông minh thành mã lệnh của máy ảo Ethereum (EVM). Các mã lệnh này được đóng gói qua giao dịch và tải lên Ethereum, cuối cùng được EVM phân tích và thực thi.

Cần lưu ý rằng lỗ hổng trình biên dịch Solidity khác với lỗ hổng của chính EVM. Lỗ hổng EVM là những vấn đề an ninh phát sinh khi máy ảo thực hiện các lệnh, có thể ảnh hưởng đến toàn bộ mạng Ethereum. Trong khi đó, lỗ hổng trình biên dịch Solidity là những vấn đề tồn tại khi chuyển đổi Solidity thành mã EVM, không ảnh hưởng trực tiếp đến bản thân mạng Ethereum.

Một nguy cơ của lỗ hổng biên dịch Solidity là nó có thể dẫn đến mã EVM được tạo ra không nhất quán với mong đợi của nhà phát triển hợp đồng thông minh. Vì các hợp đồng thông minh trên Ethereum thường liên quan đến tài sản tiền điện tử của người dùng, nên bất kỳ lỗi nào do biên dịch viên gây ra đều có thể dẫn đến tổn thất tài sản của người dùng, tạo ra hậu quả nghiêm trọng.

Các nhà phát triển và nhân viên kiểm toán hợp đồng có thể tập trung vào các vấn đề thực hiện logic mã hợp đồng, cũng như các vấn đề an ninh ở mức Solidity như tấn công tái nhập và tràn số nguyên. Tuy nhiên, rất khó để phát hiện các lỗ hổng trong trình biên dịch Solidity chỉ thông qua việc kiểm toán logic mã nguồn hợp đồng. Cần phải phân tích kết hợp giữa phiên bản trình biên dịch cụ thể và các mẫu mã cụ thể để xác định liệu hợp đồng thông minh có bị ảnh hưởng bởi các lỗ hổng của trình biên dịch hay không.

Ví dụ về lỗ hổng biên dịch Solidity

Dưới đây là một vài ví dụ thực tế về lỗi biên dịch Solidity, cho thấy hình thức cụ thể, nguyên nhân và tác hại.

SOL-2016-9 HighOrderByteCleanStorage

Lỗi này tồn tại trong các phiên bản cũ hơn của trình biên dịch Solidity (>=0.1.6 <0.4.4).

Xem xét đoạn mã sau:

solidity hợp đồng C { uint32 a = 0x12345678; uint32 b = 0; function run() returns (uint256) { a += 1; return b; } }

Biến storage b không bị thay đổi, do đó hàm run() nên trả về giá trị mặc định 0. Tuy nhiên, trong mã được tạo ra bởi trình biên dịch phiên bản có lỗ hổng, run() sẽ trả về 1.

Tình huống không nhất quán này, nếu biến b được sử dụng cho xác thực quyền hạn, kế toán tài sản và các mục đích khác, có thể dẫn đến hậu quả nghiêm trọng.

Nguyên nhân xuất hiện tình huống này là do EVM sử dụng các phần tử ngăn xếp có kích thước 32 byte, trong khi Solidity hỗ trợ các kiểu dữ liệu nhỏ hơn như uint32. Trình biên dịch cần thực hiện thao tác xóa bit cao khi xử lý các kiểu này, nhưng không xử lý đúng trong trường hợp tràn số nguyên, dẫn đến bit 1 cao bị ghi vào biến b liền kề.

SOL-2022-4 InlineAssemblyMemorySideEffects

Lỗi này tồn tại trong các phiên bản biên dịch từ 0.8.13 đến 0.8.15.

Xem xét mã sau:

solidity hợp đồng C { function f() public pure returns (uint) { lắp ráp { mstore(0, 0x42) } uint x; lắp ráp { x := mload(0) } return x; } }

Lỗ hổng này xuất phát từ các thao tác tối ưu hóa biên dịch. Trình biên dịch sẽ phân tích và tối ưu hóa từng khối assembly, nếu một thao tác ghi vào bộ nhớ nào đó sau đó không được đọc, nó sẽ bị xóa để tiết kiệm gas. Tuy nhiên, thao tác ghi và đọc trong mã trên nằm ở hai khối assembly khác nhau, trình biên dịch đã sai lầm xác định thao tác ghi đầu tiên là thừa và đã xóa nó, dẫn đến việc hàm f() trả về 0 thay vì 0x42 chính xác.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Lỗ hổng này ảnh hưởng đến các phiên bản biên dịch từ 0.5.8 đến 0.8.16.

Xem xét đoạn mã sau:

solidity hợp đồng C { function f(bytes4[] calldata a) external pure returns (bytes4[] memory) { trả về abi.decode(abi.encode(a), (bytes4[])); } }

Trong trường hợp bình thường, mã này sẽ trả về biến a đã nhập. Nhưng trong phiên bản có lỗ hổng, nếu nhập "aaaa", nó sẽ trả về mảng rỗng.

Điều này là do Solidity khi thực hiện thao tác abi.encode trên mảng kiểu calldata, đã vô tình làm sạch một số dữ liệu, dẫn đến việc thay đổi dữ liệu liền kề, gây ra sự không nhất quán giữa dữ liệu sau khi mã hóa và giải mã.

Cần lưu ý rằng, khi thực hiện cuộc gọi bên ngoài và phát sự kiện, Solidity sẽ ngầm mã hóa các tham số bằng abi.encode, do đó xác suất xuất hiện các lỗ hổng loại này có thể cao hơn so với tưởng tượng.

Đề xuất an toàn

Đối với lỗ hổng của trình biên dịch Solidity, đưa ra các khuyến nghị sau cho các nhà phát triển và nhân viên an ninh:

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. Các phiên bản mới thường sửa chữa các vấn đề bảo mật đã biết.
• Hoàn thiện các trường hợp kiểm tra đơn vị. Hầu hết các lỗi ở cấp trình biên dịch sẽ dẫn đến kết quả thực thi mã không nhất quán với mong đợi, việc nâng cao độ phủ sóng kiểm tra có thể tối đa hóa khả năng tránh những vấn đề như vậy.
• Cố gắng tránh sử dụng lắp ráp nội tuyến, mã hóa và giải mã abi phức tạp, v.v., không sử dụng mù quáng các tính năng mới và các chức năng thử nghiệm. Hầu hết các lỗ hổng biên dịch liên quan đến những hoạt động phức tạp này.

Đối với nhân viên an ninh:

• Khi kiểm toán mã Solidity, đừng bỏ qua những rủi ro an toàn mà trình biên dịch có thể gây ra.
• Trong quy trình phát triển nội bộ, khuyến khích đội ngũ phát triển nâng cấp phiên bản trình biên dịch Solidity, có thể xem xét việc đưa vào quy trình CI/CD việc kiểm tra tự động phiên bản trình biên dịch.
• Không cần quá lo lắng về lỗ hổng biên dịch, hầu hết các lỗ hổng chỉ kích hoạt trong các mẫu mã cụ thể, cần đánh giá ảnh hưởng thực tế dựa trên tình hình cụ thể của dự án.

Một số tài nguyên hữu ích:

• Thông báo bảo mật được đội ngũ Solidity phát hành định kỳ
• Danh sách lỗi được cập nhật định kỳ từ kho chính thức của Solidity
• Danh sách lỗi biên dịch viên các phiên bản
• Biểu tượng hình tam giác và dấu chấm than ở góc trên bên phải trang mã hợp đồng trên Etherscan có thể cho biết các lỗ hổng bảo mật của trình biên dịch phiên bản hiện tại.

Tóm lại, lỗ hổng của trình biên dịch Solidity là một rủi ro an ninh không thể xem nhẹ trong phát triển hợp đồng thông minh. Các nhà phát triển và nhân viên an ninh nên nâng cao cảnh giác và thực hiện các biện pháp thích hợp để giảm thiểu các mối đe dọa tiềm ẩn do lỗ hổng này mang lại.