Phân tích lỗ hổng trình biên dịch Solidity và chiến lược đối phó
Biên dịch viên 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 bậc cao thành mã lệnh có thể thực thi bởi 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 đều chú trọng đến sự an toàn của mã nguồn ứng dụng, nhưng sự an toàn của chính trình biên dịch cũng không thể bị bỏ qua. 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 lỗ hổng an ninh, trong một số trường hợp có thể mang lại rủi ro an ninh nghiêm trọng. Ví dụ, khi trình duyệt biên dịch và thực thi mã JavaScript phía trước, có thể do lỗ hổng trong động cơ phân tích JavaScript mà người dùng khi truy cập trang web độc hại có thể bị tấn công thực thi mã từ xa, cuối cùng dẫn đến việc kẻ tấn công kiểm soát trình duyệt của nạn nhân hoặc thậm chí hệ điều hành.
Trình biên dịch Solidity cũng không phải là ngoại lệ, nhiều phiên bản của trình biên dịch Solidity có tồn tại lỗ hổng bảo mật. Chức năng 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 (EVM) cho máy ảo Ethereum, những mã lệnh này cuối cùng sẽ được thực thi trong EVM.
Cần lưu ý rằng lỗ hổng biên dịch Solidity và lỗ hổng của EVM là khác nhau. Lỗ hổng EVM chỉ các vấn đề bảo mật phát sinh khi máy ảo thực thi lệnh, có thể ảnh hưởng đến toàn bộ mạng Ethereum. Trong khi đó, lỗ hổng biên dịch Solidity là những vấn đề xảy ra khi chuyển đổi mã Solidity thành mã EVM, không ảnh hưởng trực tiếp đến mạng Ethereum, nhưng có thể dẫn đến mã EVM được tạo ra không đúng như mong đợi của nhà phát triển.
Một mối nguy hiểm của lỗ hổng trình 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 các nhà phát triển hợp đồng thông minh. Bởi 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, bất kỳ lỗi nào do trình biên dịch gây ra đều có thể dẫn đến mất mát tài sản của người dùng, với 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 thường quan tâm nhiều hơn đến việc thực hiện logic mã hợp đồng và các vấn đề bảo mật ở cấp độ Solidity, trong khi bỏ qua lỗ hổng của trình biên dịch. Chỉ thông qua việc kiểm toán mã nguồn hợp đồng rất khó để phát hiện lỗ hổng của trình biên dịch, cần phải kết hợp phiên bản trình biên dịch cụ thể và các mẫu mã cụ thể để phân tích.
Dưới đây là một vài ví dụ thực tế về lỗ hổng của trình biên dịch Solidity:
SOL-2016-9 HighOrderByteCleanStorage
Lỗi này tồn tại trong các phiên bản trình biên dịch Solidity sớm hơn (>=0.1.6 <0.4.4). Trong một số trường hợp, trình biên dịch không làm sạch đúng cách các byte cao, dẫn đến việc bit 1 ở cao bị ghi vào bộ nhớ lưu trữ sau khi tràn số nguyên, ghi đè lên giá trị của các biến liền kề. Hành vi không nhất quán này có thể gây ra hậu quả nghiêm trọng khi liên quan đến xác thực quyền truy cập hoặc ghi chép tài sản.
SOL-2022-4 Tác động đến bộ nhớ InlineAssembly
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. Do vấn đề về chính sách tối ưu hóa của trình biên dịch, trong một số trường hợp, nó sẽ xóa sai lệnh ghi bộ nhớ, dẫn đến giá trị trả về của hàm không khớp với mong đợi. Loại lỗi liên quan đến tối ưu hóa này rất khó phát hiện qua việc xem xét mã đơn giản.
Lỗi này ảnh hưởng đến các phiên bản biên dịch 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, trình biên dịch đã xóa sai 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 trong dữ liệu sau khi mã hóa và giải mã. Vấn đề này cũng có thể xảy ra khi gọi hàm bên ngoài và phát sự kiện, vì những thao tác này sẽ thực thi abi.encode một cách ngầm định.
Dựa trên phân tích lỗ hổng của trình biên dịch Solidity, đưa ra các khuyến nghị bảo mật sau:
Đối với 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 vấn đề bảo mật đã biết thường ít hơn.
Hoàn thiện các trường hợp kiểm tra đơn vị, nâng cao tỷ lệ mã được kiểm tra, giúp phát hiện các vấn đề do trình biên dịch gây ra.
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, cẩn thận khi sử dụng các tính năng mới và tính năng thử nghiệm.
Đối với nhân viên an ninh:
Xem xét rủi ro an ninh có thể do trình biên dịch gây ra trong quá trình kiểm toán
Thúc giục nâng cấp phiên bản biên dịch viên trong quy trình SDL, xem xét việc đưa vào kiểm tra phiên bản tự động trong CI/CD.
Đánh giá tác động thực tế của lỗ hổng biên dịch dựa trên tình hình cụ thể của dự án, tránh lo lắng quá mức.
Một số tài nguyên hữu ích:
Cảnh báo an toàn được phát hành chính thức bởi Solidity
Danh sách lỗi được cập nhật định kỳ trong kho Solidity
Danh sách lỗi biên dịch viên các phiên bản, có thể được sử dụng để kiểm tra tự động
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, mặc dù lỗi biên dịch Solidity không phổ biến, nhưng có thể gây ra hậu quả nghiêm trọng. 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 tương ứng để giảm thiểu rủi ro.
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.
21 thích
Phần thưởng
21
7
Chia sẻ
Bình luận
0/400
FrogInTheWell
· 4giờ trước
Biên dịch viên 🔨 nhưng lại là thứ chết người.
Xem bản gốcTrả lời0
TokenGuru
· 5giờ trước
Giữ lại một +1 nhé các anh em, lỗ hổng này nhất định phải cẩn thận. Khuyên nên kiểm tra phiên bản hợp đồng trước khi nhập một vị thế.
Xem bản gốcTrả lời0
AltcoinAnalyst
· 07-21 10:23
Hãy cẩn thận, đây là những vấn đề cũ của phiên bản 0.8.x
Xem bản gốcTrả lời0
MemecoinResearcher
· 07-21 10:12
rekt đang chờ xảy ra fr dựa trên phân tích của tôi (p<0.01)
Xem bản gốcTrả lời0
just_another_wallet
· 07-21 10:12
Các nhà phát triển trẻ hãy nhanh chóng xem nào!
Xem bản gốcTrả lời0
FarmHopper
· 07-21 10:11
Ôi trời, lỗ hổng này nhìn thật đáng sợ.
Xem bản gốcTrả lời0
YieldWhisperer
· 07-21 10:10
đã thấy mẫu khai thác biên dịch viên giống như này từ năm 2021... các nhà phát triển không bao giờ học được smh
Phân tích lỗ hổng của trình biên dịch Solidity: Những rủi ro an ninh và cách ứng phó
Phân tích lỗ hổng trình biên dịch Solidity và chiến lược đối phó
Biên dịch viên 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 bậc cao thành mã lệnh có thể thực thi bởi 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 đều chú trọng đến sự an toàn của mã nguồn ứng dụng, nhưng sự an toàn của chính trình biên dịch cũng không thể bị bỏ qua. 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 lỗ hổng an ninh, trong một số trường hợp có thể mang lại rủi ro an ninh nghiêm trọng. Ví dụ, khi trình duyệt biên dịch và thực thi mã JavaScript phía trước, có thể do lỗ hổng trong động cơ phân tích JavaScript mà người dùng khi truy cập trang web độc hại có thể bị tấn công thực thi mã từ xa, cuối cùng dẫn đến việc kẻ tấn công kiểm soát trình duyệt của nạn nhân hoặc thậm chí hệ điều hành.
Trình biên dịch Solidity cũng không phải là ngoại lệ, nhiều phiên bản của trình biên dịch Solidity có tồn tại lỗ hổng bảo mật. Chức năng 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 (EVM) cho máy ảo Ethereum, những mã lệnh này cuối cùng sẽ được thực thi trong EVM.
Cần lưu ý rằng lỗ hổng biên dịch Solidity và lỗ hổng của EVM là khác nhau. Lỗ hổng EVM chỉ các vấn đề bảo mật phát sinh khi máy ảo thực thi lệnh, có thể ảnh hưởng đến toàn bộ mạng Ethereum. Trong khi đó, lỗ hổng biên dịch Solidity là những vấn đề xảy ra khi chuyển đổi mã Solidity thành mã EVM, không ảnh hưởng trực tiếp đến mạng Ethereum, nhưng có thể dẫn đến mã EVM được tạo ra không đúng như mong đợi của nhà phát triển.
Một mối nguy hiểm của lỗ hổng trình 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 các nhà phát triển hợp đồng thông minh. Bởi 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, bất kỳ lỗi nào do trình biên dịch gây ra đều có thể dẫn đến mất mát tài sản của người dùng, với 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 thường quan tâm nhiều hơn đến việc thực hiện logic mã hợp đồng và các vấn đề bảo mật ở cấp độ Solidity, trong khi bỏ qua lỗ hổng của trình biên dịch. Chỉ thông qua việc kiểm toán mã nguồn hợp đồng rất khó để phát hiện lỗ hổng của trình biên dịch, cần phải kết hợp phiên bản trình biên dịch cụ thể và các mẫu mã cụ thể để phân tích.
Dưới đây là một vài ví dụ thực tế về lỗ hổng của trình biên dịch Solidity:
Lỗi này tồn tại trong các phiên bản trình biên dịch Solidity sớm hơn (>=0.1.6 <0.4.4). Trong một số trường hợp, trình biên dịch không làm sạch đúng cách các byte cao, dẫn đến việc bit 1 ở cao bị ghi vào bộ nhớ lưu trữ sau khi tràn số nguyên, ghi đè lên giá trị của các biến liền kề. Hành vi không nhất quán này có thể gây ra hậu quả nghiêm trọng khi liên quan đến xác thực quyền truy cập hoặc ghi chép tài sản.
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. Do vấn đề về chính sách tối ưu hóa của trình biên dịch, trong một số trường hợp, nó sẽ xóa sai lệnh ghi bộ nhớ, dẫn đến giá trị trả về của hàm không khớp với mong đợi. Loại lỗi liên quan đến tối ưu hóa này rất khó phát hiện qua việc xem xét mã đơn giản.
Lỗi này ảnh hưởng đến các phiên bản biên dịch 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, trình biên dịch đã xóa sai 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 trong dữ liệu sau khi mã hóa và giải mã. Vấn đề này cũng có thể xảy ra khi gọi hàm bên ngoài và phát sự kiện, vì những thao tác này sẽ thực thi abi.encode một cách ngầm định.
Dựa trên phân tích lỗ hổng của trình biên dịch Solidity, đưa ra các khuyến nghị bảo mật sau:
Đối với các nhà phát triển:
Đối với nhân viên an ninh:
Một số tài nguyên hữu ích:
Tóm lại, mặc dù lỗi biên dịch Solidity không phổ biến, nhưng có thể gây ra hậu quả nghiêm trọng. 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 tương ứng để giảm thiểu rủi ro.