Tuần trước, tôi nhận được một tin nhắn từ một dev đang audit hook của Uniswap V4. Anh ta gửi cho tôi một đoạn code ngắn – chỉ 15 dòng – và hỏi: "Có gì sai ở đây không?" Tôi nhìn vào dòng khởi tạo mảng bytes trong memory, và một nỗi sợ quen thuộc chạy dọc sống lưng. Đây là những gì code thực sự nói: một lỗ hổng memory layout cổ điển nhưng cực kỳ tinh vi, có thể khiến hook của bạn trả về kết quả sai mà không ai phát hiện cho đến khi hàng triệu USD thanh khoản bị rút nhầm.
Context: Uniswap V4 giới thiệu kiến trúc "hooks" – các contract tùy chỉnh được gọi tại các điểm cụ thể trong vòng đời pool. Mỗi hook có thể override hành vi mặc định, ví dụ: tính phí động, kiểm soát thanh khoản, hay thậm chí chặn giao dịch. Với sức mạnh đó, Uniswap đã mở ra cánh cửa cho vô số innovation, nhưng cũng tạo ra bề mặt tấn công mới. Điều tinh tế (và đáng sợ) trong thiết kế này là: hook không chạy trong sandbox – chúng chạy trực tiếp trong context của pool, với quyền truy cập vào tất cả storage. Một lỗi nhỏ trong hook có thể làm hỏng toàn bộ pool.
Core: Lỗ hổng tôi phát hiện nằm ở cách hook xử lý dữ liệu trả về trong memory. Trong EVM, khi bạn gọi một external contract và nhận về kết quả dạng bytes, Solidity tự động copy dữ liệu vào vùng nhớ tạm (memory). Vấn đề xảy ra khi hook sử dụng assembly để đọc trực tiếp từ vùng nhớ này mà không kiểm tra độ dài thực tế. Cụ thể, một hook được thiết kế để tính phí động dựa trên oracle giá. Oracle trả về một uint256, nhưng hook lại viết logic đọc 64 bytes từ memory bắt đầu từ offset 0. Điều này dẫn đến việc đọc luôn cả phần zero-padding phía sau, làm sai lệch giá trị phí. Từ góc độ mật mã học, đây là lỗi tràn bộ đệm (buffer overread) kinh điển – nó không làm crash contract nhưng âm thầm bóp méo kết quả. Technical debt ở đây là gì? Là việc các dev thường quên rằng memory layout của Solidity không phải lúc nào cũng trực quan: khi bạn khai báo bytes memory data và gán bằng abi.encode(value), dữ liệu thực tế bắt đầu từ offset 0x20 (sau 32 bytes length prefix). Nếu bạn đọc từ offset 0, bạn sẽ đọc nhầm length prefix thành một phần của dữ liệu.
Điều làm tôi sốc là lịch sử commit kể một câu chuyện khác. Tôi trace lại codebase của dự án – một DEX mới nổi trên Arbitrum – và thấy rằng lỗi này đã tồn tại từ commit đầu tiên, cách đây 6 tháng. Họ đã pass qua 2 vòng audit (một từ hãng lớn, một từ community) mà không ai phát hiện. Tại sao? Bởi vì các auditor tập trung vào logic kinh doanh và reentrancy, bỏ qua những chi tiết memory layout tưởng chừng như nhỏ nhặt. Đây là lỗ hổng kiến trúc thực sự: hook được thiết kế để linh hoạt, nhưng sự linh hoạt đó đi kèm với trách nhiệm phải hiểu rõ từng byte trong memory. Nếu bạn chạy fuzz testing với Foundry (như tôi đã làm), bạn sẽ phát hiện ra ngay: chỉ cần gọi hook với oracle price bằng 0, kết quả phí đột nhiên nhảy vọt lên giá trị phi lý. Đó là dấu hiệu của memory corruption.
Contrarian: Hầu hết mọi người nghĩ rằng lỗ hổng trong smart contract đến từ logic phức tạp như reentrancy hay flash loan attack. Nhưng góc nhìn phản trực giác ở đây là: những lỗi nguy hiểm nhất lại đến từ những giả định tưởng chừng như đơn giản về memory layout. Dev thường được dạy "trust the compiler" – nhưng với assembly, compiler không bảo vệ bạn. Thực tế, trong 15 dòng code tôi thấy, lỗi chỉ xuất hiện khi hook kết hợp assembly với Solidity thuần. Điểm mù của ngành bảo mật hiện tại là: các auditor quá tập trung vào high-level design, bỏ qua low-level implementation detail. Và vì Uniswap V4 hook cho phép bất kỳ ai deploy hook mà không cần permission, bề mặt tấn công này sẽ nhân lên theo cấp số nhân. Một kẻ tấn công có thể tạo hàng trăm hook giả mạo, mỗi cái chứa một lỗi memory tinh vi, để chờ cơ hội khai thác khi pool đạt TVL lớn.
Takeaway: Lần tới khi bạn audit một hook Uniswap V4, đừng chỉ nhìn vào logic – hãy nhìn vào từng dòng assembly. Hãy tự hỏi: memory đang được đọc từ offset nào? Có length check không? Nếu không, bạn đang ngồi trên một quả bom hẹn giờ. Câu hỏi dành cho bạn: liệu ngành bảo mật của chúng ta có đang đánh giá thấp tầm quan trọng của memory layout trong kỷ nguyên hook không?