Nhóm bảo mật giải thích lỗ hổng hợp đồng khóa Edgeware: khủng hoảng tài sản do một dòng mã gây ra
Tiêu đề gốc: "Giới thiệu về lỗ hổng từ chối dịch vụ của Hợp đồng khóa phần mềm Edgeware"
Tác giả gốc: cosine
Nguồn gốc: Công nghệ Manwu
Liên quan đến lỗ hổng từ chối dịch vụ của hợp đồng khóa Edgeware, chúng tôi nhận thấy rằng Edgeware đã bộc lộ một lỗ hổng nghiêm trọng. Lỗ hổng này đã được sửa. Đối với những người dùng đã khóa vị trí của họ và sau khi sửa chữa, Sẽ không có tác động nào đến những người dùng tiếp tục khóa và xét theo tình hình hiện tại, vì lỗ hổng này đã được tiết lộ một cách có trách nhiệm nên sẽ không có tác động thực sự nào.
Nhưng tại sao lỗ hổng này lại được coi là nghiêm trọng? Tôi sẽ chỉ cung cấp cho bạn một số thông tin.
Gần đây, Edgeware, một dự án chuỗi nổi tiếng trong hệ sinh thái Polkadot, nhờ ILO ban đầu của nó (Khóa ban đầu- up Offer), Một trong những cách là cho phép người tham gia nhận được nhiều ưu đãi tiền kỹ thuật số Edgeware hơn bằng cách khóa ETH. Hơn 900 triệu đô la Mỹ ETH đã được xử lý và hơn 290 triệu đô la Mỹ đã bị khóa, điều này từng rất phổ biến.
Như được hiển thị trong "Hình 1", mỗi người tham gia có thể khóa và nhận các ưu đãi thông qua hợp đồng Lockdrop do Edgeware xuất bản trên Ethereum. Thành công sau đó, một Khóa độc lập hợp đồng sẽ được tạo ra dưới sự kiểm soát có thẩm quyền của chính nó. Bản thân hợp đồng này an toàn (ít nhất là chúng tôi chưa tìm thấy bất kỳ rủi ro tiềm ẩn nào đã biết). Nhưng điều thú vị là: lỗ hổng xuất hiện vào thời điểm hợp đồng Khóa được tạo.
Mọi người chú ý chức năng khóa ở "Hình 2", có mã khóa:
assert(address(lockAddr).balance == msg.value);
Mã này đưa ra phán quyết bắt buộc: số tiền trong Hợp đồng khóa thuộc về người tham gia phải bằng số tiền mà người tham gia đã gửi khi khóa vị trí nếu không bằng , nghĩa là khóa không thành công. Thất bại này sẽ khiến hợp đồng Khóa của người tham gia bị "tê liệt" và hình thành "từ chối dịch vụ". Hậu quả trực tiếp là: nếu cuộc tấn công tiếp tục, Edgeware Lockdrop cơ chế sẽ không còn nữa. Tuy nhiên, lỗ hổng này không ảnh hưởng đến tiền của người tham gia. Vì vậy, trong trường hợp nào kết quả sẽ là "address(lockAddr).balance không bằng msg.value"? Nếu kẻ tấn công có thể đoán trước địa chỉ hợp đồng Khóa của người tham gia (điều này được mô tả rõ ràng trong Sách vàng Ethereum), thì kẻ tấn công chỉ cần đến địa chỉ hợp đồng Khóa của người tham gia và chuyển một số ETH theo ý muốn. Mã sửa chữa lỗ hổng này của Edgeware cũng rất đơn giản, xem “Hình 3”, hợp đồng Lockdrop:
assert(address(lockAddr).balance == msg.value);
Đổi thành:
assert(address(lockAddr).balance >= msg.value);
Vậy đó. Có, hợp đồng Lockdrop được phát hành lại với một hợp đồng mới.
Hợp đồng Lockdrop dễ bị tổn thương:
https://etherscan.io/address/0x1b75b90e60070d37cfa9d87affd124bb345bf70a#contracts
Hợp đồng Lockdrop đã được sửa chữa:
https://etherscan.io/address/0xFEC6F679e32D45E22736aD09dFdF6E3368704e31#contracts
Hợp đồng thông minh thực sự không có lỗi. Tài liệu tham khảo liên quan:
https://medium.com/@nmcl/gridlock-a-smart-contract-bug-73b8310608a9
https://blog.edgewa.re/a-denial-of-service-bug- trong-the-edgeware-lockdrop
https://ethereum.github.io/ yellowpaper/paper.pdf
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
Bài viết liên quan
