Trong Nhật ký săn lỗi mới nhất, tôi phát hiện thứ trông như một lỗi làm tròn nghiêm trọng trong sản phẩm lợi suất dựa trên tranche: mất 100,000,000,000 wei mỗi lần redeem. Sai số bị cắt cụt cộng dồn qua hai lớp chuyển đổi. Bản nháp báo cáo mức độ nghiêm trọng “Cao” đã sẵn sàng để gửi. Nhưng quy tắc xác minh của tôi là: phải tái hiện trên bản fork của mainnet trước khi tin vào bất kỳ con số nào. Và đây là điều bất ngờ:
Pool mô phỏng giả định token có 18 chữ số thập phân và hệ số chia là 1e30.
Token thật có 6 chữ số thập phân và hệ số chia là 1e18.
Sai lệch tỷ lệ 1e12 đó khiến pool mô phỏng trả về zero mỗi lần redeem, nên loss == amount requested. Đây không phải lỗi giao thức — bộ kiểm thử của tôi bị hỏng. Trên mainnet, mức hao hụt thực tế chỉ khoảng 2–3 wei mỗi lần redeem, nằm trong ngân sách làm tròn 100 wei mà nhà phát triển đã dự trù. Đúng như thiết kế. Bài học rút ra:
Một phát hiện chỉ được xác thực bằng mô phỏng là giả thuyết, không phải lỗi.
uint256 không có đơn vị: sai lệch thang đo 12 chữ số vẫn biên dịch trơn tru và vượt qua mọi trình phân tích.
Nếu “khoản thất thoát” bạn nêu bằng toàn bộ số tiền, thì vấn đề nằm ở thang đo của bạn, không phải hợp đồng.
Hãy đọc các nhận xét của nhà phát triển về biên độ/sai số epsilon trước khi đánh giá mức độ nghiêm trọng. Kết quả: 0 báo cáo, 4 ứng viên bị loại trong quá trình xác thực, một buổi chiều trung thực, danh tiếng vẫn nguyên vẹn. Trước khi gửi báo cáo tiếp theo về “tổn thất làm tròn không giới hạn”, hãy chạy một đơn vị qua hợp đồng thực trên một fork. Nếu khoản thất thoát của bạn nằm trong phạm vi epsilon của nhà phát triển, thì bạn không có phát hiện nào — bạn chỉ đang gặp vấn đề với mô phỏng.
#Web3Security #BugBounty #SmartContracts #solidity #CyberSecurity
(An toàn theo NDA: nhật ký chung, không có tên giao thức, địa chỉ, kho mã hay PoC đang hoạt động.)
Đọc bài phân tích kỹ thuật đầy đủ trên Blog của tôi (liên kết ở bình luận đầu tiên) 👇