Tính hai mặt của cơ chế Hook của Uniswap v4: Đổi mới và rủi ro tiềm ẩn đồng tồn tại
Uniswap v4 sắp ra mắt, bản nâng cấp này thật sự đầy tham vọng. Phiên bản mới sẽ giới thiệu nhiều tính năng hoàn toàn mới, bao gồm hỗ trợ số lượng không giới hạn các bể thanh khoản cho mỗi cặp giao dịch và phí động, thiết kế đơn thể, kế toán chớp nhoáng, cơ chế Hook, cũng như hỗ trợ tiêu chuẩn token ERC1155. Sử dụng công nghệ lưu trữ tạm thời, Uniswap v4 dự kiến sẽ được phát hành sau khi nâng cấp Ethereum Cancun.
Giữa nhiều đổi mới, cơ chế Hook thu hút sự chú ý nhờ tiềm năng mạnh mẽ của nó. Cơ chế này cho phép thực hiện mã tùy chỉnh tại các nút cụ thể trong vòng đời của bể thanh khoản, làm tăng đáng kể khả năng mở rộng và linh hoạt của bể.
Tuy nhiên, cơ chế Hook cũng có thể là một con dao hai lưỡi. Mặc dù mạnh mẽ và linh hoạt, việc sử dụng Hook một cách an toàn cũng đối mặt với không ít thách thức. Độ phức tạp của Hook không thể tránh khỏi đã mang lại các vector tấn công tiềm ẩn mới. Do đó, cần thiết phải giới thiệu hệ thống các vấn đề an ninh và rủi ro tiềm ẩn liên quan đến cơ chế Hook, nhằm thúc đẩy sự phát triển an toàn của cộng đồng, những hiểu biết này sẽ giúp xây dựng một Hook Uniswap v4 an toàn hơn.
Bài viết này sẽ giới thiệu các khái niệm liên quan đến cơ chế Hook trong Uniswap v4 và tóm tắt các rủi ro an ninh mà nó tồn tại.
Cơ chế của Uniswap V4
Trước khi đi sâu vào thảo luận, chúng ta cần có hiểu biết cơ bản về cơ chế của Uniswap v4. Theo thông báo chính thức và tài liệu trắng, Hook, kiến trúc đơn lẻ và kế toán chớp nhoáng là ba chức năng quan trọng để thực hiện các bể thanh khoản tùy chỉnh và định tuyến hiệu quả qua nhiều bể.
1.1 Móc
Hook đề cập đến hợp đồng hoạt động ở các giai đoạn khác nhau trong vòng đời của bể thanh khoản. Nhóm Uniswap muốn thông qua việc giới thiệu Hook để bất kỳ ai cũng có thể đưa ra quyết định cân nhắc. Cách này có thể hỗ trợ nguyên bản các khoản phí động, thêm lệnh giới hạn trên chuỗi, hoặc phân tán các đơn hàng lớn thông qua các nhà tạo lập thị trường trung bình trọng số theo thời gian (TWAMM).
Hiện tại có tám callback Hook, được chia thành bốn nhóm ( mỗi nhóm chứa một cặp callback ):
trướcKhởiTạo/sauKhởiTạo
trướcSửaĐổiVịTrí/sauSửaĐổiVịTrí
trướcHoán đổi/sauHoán đổi
beforeDonate/afterDonate
Nhóm Uniswap đã cung cấp một số ví dụ ( như cách giới thiệu hoạt động của TWAMM Hook ), và các thành viên trong cộng đồng cũng đã đóng góp một số nội dung. Tài liệu chính thức còn liên kết đến kho Awesome Uniswap v4 Hooks, kho này thu thập thêm nhiều ví dụ về Hook.
1.2 Mô hình đơn, ghi sổ nhanh và cơ chế khóa
Kiến trúc đơn thể và ghi sổ chớp nhoáng nhằm nâng cao hiệu suất bằng cách giảm chi phí và đảm bảo hiệu quả. Nó giới thiệu một hợp đồng singleton mới, tức là tất cả các bể thanh khoản được lưu trữ trong cùng một hợp đồng thông minh. Thiết kế đơn thể này dựa vào PoolManager để lưu trữ và quản lý trạng thái của tất cả các bể.
Phiên bản Uniswap v4 giới thiệu cơ chế kế toán chớp nhoáng và cơ chế khóa. Cách thức hoạt động của cơ chế khóa như sau:
hợp đồng locker yêu cầu lock trên PoolManager.
PoolManager thêm địa chỉ hợp đồng locker vào hàng đợi lockData và gọi lại lockAcquired.
Hợp đồng locker thực hiện logic của nó trong callback. Trong quá trình thực hiện, sự tương tác giữa hợp đồng locker và bể có thể dẫn đến sự gia tăng tiền tệ không bằng 0. Tuy nhiên, khi kết thúc thực hiện, tất cả các gia tăng phải được thanh toán về 0. Ngoài ra, nếu hàng đợi lockData không trống, chỉ hợp đồng locker cuối cùng mới có thể thực hiện thao tác.
PoolManager kiểm tra trạng thái của hàng đợi lockData và sự gia tăng tiền tệ. Sau khi xác minh, PoolManager sẽ xóa hợp đồng locker đó.
Tóm lại, cơ chế khóa ngăn chặn việc truy cập đồng thời và đảm bảo tất cả giao dịch đều được thanh toán. Hợp đồng locker sẽ yêu cầu khóa theo thứ tự, sau đó thực hiện giao dịch thông qua callback lockAcquired. Mỗi lần thao tác trong pool trước và sau sẽ kích hoạt các callback Hook tương ứng. Cuối cùng, PoolManager sẽ kiểm tra trạng thái.
Phương pháp này có nghĩa là việc điều chỉnh hoạt động là số dư ròng nội bộ ( tức là delta ), chứ không phải thực hiện chuyển khoản ngay lập tức. Mọi sửa đổi sẽ được ghi lại trong số dư nội bộ của bể, và việc chuyển khoản thực tế sẽ diễn ra khi hoạt động ( tức là lock ) kết thúc. Quy trình này đảm bảo rằng không có mã thông báo nào chưa thanh toán, từ đó duy trì tính toàn vẹn của quỹ.
Do cơ chế khóa tồn tại, tất cả các tài khoản bên ngoài (EOA) không thể tương tác trực tiếp với PoolManager. Thay vào đó, mọi tương tác phải thông qua hợp đồng. Hợp đồng này hoạt động như một locker trung gian, cần yêu cầu khóa trước khi thực hiện bất kỳ thao tác nào với pool.
Chủ yếu có hai tình huống tương tác hợp đồng:
hợp đồng locker đến từ kho mã chính thức hoặc được người dùng triển khai. Tình huống này có thể được coi là tương tác thông qua bộ định tuyến.
Hợp đồng locker và Hook được tích hợp vào cùng một hợp đồng, hoặc được kiểm soát bởi một thực thể bên thứ ba. Tình huống này có thể được coi là tương tác thông qua Hook. Lúc này, Hook vừa đóng vai trò của hợp đồng locker, vừa chịu trách nhiệm xử lý các callback.
Mô hình đe dọa
Trước khi thảo luận về các vấn đề an ninh liên quan, chúng ta cần xác định mô hình mối đe dọa. Chúng ta chủ yếu xem xét hai trường hợp sau:
Mô hình đe dọa I: Hook bản thân là thiện lành, nhưng có lỗ hổng.
Mô hình đe dọa II: Hook bản thân nó là độc hại.
Tiếp theo sẽ thảo luận về các vấn đề an ninh tiềm ẩn dựa trên hai mô hình mối đe dọa này.
2.1 Vấn đề an ninh trong mô hình đe dọa I
Mô hình đe dọa I tập trung vào các lỗ hổng liên quan đến chính Hook. Mô hình đe dọa này giả định rằng nhà phát triển và Hook của họ không có ác ý. Tuy nhiên, các lỗ hổng đã biết hiện có trong hợp đồng thông minh cũng có thể xuất hiện trong Hook. Ví dụ, nếu Hook được triển khai dưới hình thức hợp đồng có thể nâng cấp, thì nó có thể gặp phải các vấn đề liên quan tương tự như lỗ hổng UUPSUpgradeable của OpenZeppelin.
Xét đến các yếu tố trên, chúng tôi chọn tập trung vào các lỗ hổng tiềm tàng đặc trưng của phiên bản v4. Trong Uniswap v4, Hook là một hợp đồng thông minh có thể thực hiện logic tùy chỉnh trước hoặc sau khi thao tác trên hồ chứa chính ( bao gồm khởi tạo, thay đổi vị trí, trao đổi và thu thập ). Mặc dù Hook dự kiến sẽ thực hiện giao diện tiêu chuẩn, nhưng cũng cho phép bao gồm logic tùy chỉnh. Do đó, phạm vi thảo luận của chúng tôi sẽ giới hạn trong logic liên quan đến giao diện Hook tiêu chuẩn. Sau đó, chúng tôi sẽ cố gắng tìm ra các nguồn gốc lỗ hổng có thể, chẳng hạn như Hook có thể lạm dụng các hàm Hook tiêu chuẩn này như thế nào.
Cụ thể, chúng ta sẽ tập trung vào hai loại Hook sau:
Loại hook đầu tiên, giữ tiền của người dùng. Trong trường hợp này, kẻ tấn công có thể tấn công hook này để chuyển tiền, gây ra tổn thất tài sản.
Loại hook thứ hai, lưu trữ dữ liệu trạng thái quan trọng mà người dùng hoặc các giao thức khác phụ thuộc vào. Trong trường hợp này, kẻ tấn công có thể cố gắng thay đổi trạng thái quan trọng. Khi người dùng hoặc giao thức khác sử dụng trạng thái sai, điều này có thể mang lại rủi ro tiềm ẩn.
Xin lưu ý, các hook nằm ngoài hai phạm vi này không nằm trong phạm vi thảo luận của chúng tôi.
Sau khi nghiên cứu sâu về kho Awesome Uniswap v4 Hooks, chúng tôi đã phát hiện ra một số lỗ hổng nghiêm trọng. Những lỗ hổng này chủ yếu phát sinh từ sự tương tác rủi ro giữa hook, PoolManager và bên thứ ba bên ngoài, chủ yếu có thể được chia thành hai loại: vấn đề kiểm soát truy cập và vấn đề xác thực đầu vào.
Nói chung, chúng tôi đã phát hiện 22 dự án liên quan ( loại trừ các dự án không liên quan đến Uniswap v4 ). Trong số các dự án này, chúng tôi cho rằng có 8 dự án (36%) có lỗ hổng. Trong 8 dự án có lỗ hổng này, 6 dự án gặp vấn đề về kiểm soát truy cập, 2 dự án dễ bị tấn công từ các cuộc gọi bên ngoài không đáng tin cậy.
2.1.1 Vấn đề kiểm soát truy cập
Trong phần thảo luận này, chúng tôi chủ yếu tập trung vào các vấn đề có thể phát sinh từ các hàm gọi lại trong v4, bao gồm 8 hàm hook và hàm lock. Tất nhiên, còn có những trường hợp khác cần được xác thực, nhưng những trường hợp này khác nhau do thiết kế và không nằm trong phạm vi thảo luận của chúng tôi.
Các hàm này chỉ nên được gọi bởi PoolManager, không thể được gọi bởi địa chỉ khác ( bao gồm EOA và hợp đồng ). Ví dụ, trong trường hợp phần thưởng được phân phối bởi khóa quỹ, nếu hàm tương ứng có thể được gọi bởi bất kỳ tài khoản nào, thì phần thưởng có thể bị nhận sai.
Do đó, đối với hook, việc thiết lập cơ chế kiểm soát truy cập mạnh mẽ là rất quan trọng, đặc biệt là khi chúng có thể bị gọi bởi các bên khác ngoài chính bể thanh khoản. Bằng cách quản lý quyền truy cập một cách nghiêm ngặt, bể thanh khoản có thể giảm đáng kể rủi ro liên quan đến việc tương tác không được phép hoặc tương tác ác ý với hook.
2.1.2 Vấn đề xác thực đầu vào
Trong Uniswap v4, do có cơ chế khóa, người dùng phải nhận được một lock từ hợp đồng trước khi thực hiện bất kỳ thao tác nào với quỹ. Điều này đảm bảo rằng hợp đồng đang tham gia tương tác hiện tại là hợp đồng khóa mới nhất.
Mặc dù vậy, vẫn tồn tại một kịch bản tấn công có thể xảy ra, đó là các cuộc gọi bên ngoài không đáng tin cậy do xác thực đầu vào không đúng cách trong một số triển khai Hook dễ bị tấn công:
Đầu tiên, hook không xác minh quỹ mà người dùng dự định tương tác. Đây có thể là một quỹ độc hại chứa token giả mạo và thực hiện logic có hại.
Thứ hai, một số hàm hook quan trọng cho phép gọi từ bên ngoài tùy ý.
Các cuộc gọi bên ngoài không đáng tin cậy cực kỳ nguy hiểm, vì chúng có thể dẫn đến nhiều loại tấn công khác nhau, bao gồm cả cuộc tấn công tái nhập mà chúng ta đã biết.
Để tấn công những hook dễ bị tổn thương này, kẻ tấn công có thể đăng ký một bể tiền tệ độc hại cho các token giả của mình, sau đó gọi hook để thực hiện các thao tác trong bể tiền tệ. Khi tương tác với bể tiền tệ, logic của token độc hại chiếm quyền kiểm soát dòng chảy để thực hiện các hành vi xấu.
2.1.3 Các biện pháp phòng ngừa đối với mô hình đe dọa I
Để tránh các vấn đề bảo mật liên quan đến hook, việc thực hiện kiểm soát truy cập cần thiết đối với các hàm bên ngoài/công cộng nhạy cảm một cách thích hợp và xác minh các tham số đầu vào, từ đó xác thực các tương tác là vô cùng quan trọng. Hơn nữa, bảo vệ chống tái nhập có thể giúp đảm bảo rằng hook sẽ không được thực thi lại trong quy trình logic tiêu chuẩn. Bằng cách thực hiện các biện pháp bảo vệ an toàn thích hợp, quỹ có thể giảm thiểu rủi ro liên quan đến các mối đe dọa như vậy.
2.2 Vấn đề bảo mật trong mô hình đe dọa II
Trong mô hình đe dọa này, chúng tôi giả định rằng nhà phát triển và hook của họ là độc hại. Do phạm vi liên quan rất rộng, chúng tôi chỉ tập trung vào các vấn đề bảo mật liên quan đến phiên bản v4. Do đó, điều quan trọng là hook được cung cấp có thể xử lý tài sản mã hóa trong các giao dịch chuyển tiền hoặc ủy quyền của người dùng hay không.
Do việc truy cập phương thức hook quyết định quyền có thể được cấp cho hook, chúng tôi đã phân loại hook thành hai loại:
Hook ( được quản lý: hook không phải là điểm vào. Người dùng phải tương tác với hook thông qua router ) có thể được cung cấp bởi Uniswap.
Hook độc lập ( Standalone Hooks ): hook là điểm vào, cho phép người dùng tương tác trực tiếp.
(# 2.2.1 Hook kiểu ủy thác
Trong trường hợp này, tài sản tiền điện tử của người dùng ) bao gồm token gốc và các token khác ### được chuyển giao hoặc ủy quyền cho router. Do PoolManager thực hiện kiểm tra số dư, các hook độc hại không dễ dàng trực tiếp đánh cắp những tài sản này. Tuy nhiên, vẫn tồn tại những điểm tấn công tiềm ẩn. Ví dụ, cơ chế quản lý phí phiên bản v4 có thể bị kẻ tấn công thao túng thông qua hook.
(# 2.2.2 Hook độc lập
Khi Hook được sử dụng như một điểm vào, tình hình trở nên phức tạp hơn. Trong trường hợp này, do người dùng có thể tương tác trực tiếp với hook, hook đã có được nhiều quyền lực hơn. Về lý thuyết, hook có thể thực hiện bất kỳ thao tác nào mong muốn thông qua sự tương tác này.
Trong phiên bản v4, việc xác minh logic mã là vô cùng quan trọng. Vấn đề chính là liệu có thể thao túng logic mã hay không. Nếu hook có thể nâng cấp, điều này có nghĩa là một hook có vẻ an toàn có thể trở thành độc hại sau khi nâng cấp, từ đó tạo ra rủi ro lớn. Những rủi ro này bao gồm:
Đại lý có thể nâng cấp ) có thể bị tấn công trực tiếp ###;
Có logic tự hủy. Có thể bị tấn công trong trường hợp gọi chung selfdestruct và create2.
(# 2.2.3 Biện pháp phòng ngừa đối với mô hình đe dọa II
Điều quan trọng là đánh giá xem hook có phải là độc hại hay không. Cụ thể, đối với hook được quản lý, chúng ta nên chú ý đến hành vi quản lý phí; trong khi đó, đối với hook độc lập, điểm chú ý chính là liệu chúng có thể được nâng cấp hay không.
![Tại sao Hook được gọi là "con dao hai lưỡi" của Uniswap V4?])https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp###
Kết luận
Bài viết này trước tiên tóm tắt các cơ chế cốt lõi liên quan đến các vấn đề an ninh của Hook trong Uniswap v4. Sau đó, chúng tôi đưa ra hai mô hình mối đe dọa và tóm tắt ngắn gọn các rủi ro an ninh liên quan.
Trong các bài viết tiếp theo, chúng tôi sẽ phân tích sâu về các vấn đề an ninh trong từng mô hình đe dọa.
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.
17 thích
Phần thưởng
17
5
Chia sẻ
Bình luận
0/400
OfflineValidator
· 07-31 11:18
Còn phải là V4 chơi hiểu rõ.
Xem bản gốcTrả lời0
MetaMisery
· 07-30 04:35
Còn không bằng v3 ổn định, lại muốn đầu cơ khái niệm rồi phải không?
Xem bản gốcTrả lời0
SatoshiNotNakamoto
· 07-30 04:24
Ngồi đợi bug xuất hiện trong v4
Xem bản gốcTrả lời0
TokenGuru
· 07-30 04:17
Dự án cũ phiên bản nâng cấp, đồ ngốc lên xe lại phải chịu khổ.
Phân tích an toàn cơ chế Hook của Uniswap v4: Đổi mới và rủi ro song hành
Tính hai mặt của cơ chế Hook của Uniswap v4: Đổi mới và rủi ro tiềm ẩn đồng tồn tại
Uniswap v4 sắp ra mắt, bản nâng cấp này thật sự đầy tham vọng. Phiên bản mới sẽ giới thiệu nhiều tính năng hoàn toàn mới, bao gồm hỗ trợ số lượng không giới hạn các bể thanh khoản cho mỗi cặp giao dịch và phí động, thiết kế đơn thể, kế toán chớp nhoáng, cơ chế Hook, cũng như hỗ trợ tiêu chuẩn token ERC1155. Sử dụng công nghệ lưu trữ tạm thời, Uniswap v4 dự kiến sẽ được phát hành sau khi nâng cấp Ethereum Cancun.
Giữa nhiều đổi mới, cơ chế Hook thu hút sự chú ý nhờ tiềm năng mạnh mẽ của nó. Cơ chế này cho phép thực hiện mã tùy chỉnh tại các nút cụ thể trong vòng đời của bể thanh khoản, làm tăng đáng kể khả năng mở rộng và linh hoạt của bể.
Tuy nhiên, cơ chế Hook cũng có thể là một con dao hai lưỡi. Mặc dù mạnh mẽ và linh hoạt, việc sử dụng Hook một cách an toàn cũng đối mặt với không ít thách thức. Độ phức tạp của Hook không thể tránh khỏi đã mang lại các vector tấn công tiềm ẩn mới. Do đó, cần thiết phải giới thiệu hệ thống các vấn đề an ninh và rủi ro tiềm ẩn liên quan đến cơ chế Hook, nhằm thúc đẩy sự phát triển an toàn của cộng đồng, những hiểu biết này sẽ giúp xây dựng một Hook Uniswap v4 an toàn hơn.
Bài viết này sẽ giới thiệu các khái niệm liên quan đến cơ chế Hook trong Uniswap v4 và tóm tắt các rủi ro an ninh mà nó tồn tại.
Cơ chế của Uniswap V4
Trước khi đi sâu vào thảo luận, chúng ta cần có hiểu biết cơ bản về cơ chế của Uniswap v4. Theo thông báo chính thức và tài liệu trắng, Hook, kiến trúc đơn lẻ và kế toán chớp nhoáng là ba chức năng quan trọng để thực hiện các bể thanh khoản tùy chỉnh và định tuyến hiệu quả qua nhiều bể.
1.1 Móc
Hook đề cập đến hợp đồng hoạt động ở các giai đoạn khác nhau trong vòng đời của bể thanh khoản. Nhóm Uniswap muốn thông qua việc giới thiệu Hook để bất kỳ ai cũng có thể đưa ra quyết định cân nhắc. Cách này có thể hỗ trợ nguyên bản các khoản phí động, thêm lệnh giới hạn trên chuỗi, hoặc phân tán các đơn hàng lớn thông qua các nhà tạo lập thị trường trung bình trọng số theo thời gian (TWAMM).
Hiện tại có tám callback Hook, được chia thành bốn nhóm ( mỗi nhóm chứa một cặp callback ):
Nhóm Uniswap đã cung cấp một số ví dụ ( như cách giới thiệu hoạt động của TWAMM Hook ), và các thành viên trong cộng đồng cũng đã đóng góp một số nội dung. Tài liệu chính thức còn liên kết đến kho Awesome Uniswap v4 Hooks, kho này thu thập thêm nhiều ví dụ về Hook.
1.2 Mô hình đơn, ghi sổ nhanh và cơ chế khóa
Kiến trúc đơn thể và ghi sổ chớp nhoáng nhằm nâng cao hiệu suất bằng cách giảm chi phí và đảm bảo hiệu quả. Nó giới thiệu một hợp đồng singleton mới, tức là tất cả các bể thanh khoản được lưu trữ trong cùng một hợp đồng thông minh. Thiết kế đơn thể này dựa vào PoolManager để lưu trữ và quản lý trạng thái của tất cả các bể.
Phiên bản Uniswap v4 giới thiệu cơ chế kế toán chớp nhoáng và cơ chế khóa. Cách thức hoạt động của cơ chế khóa như sau:
hợp đồng locker yêu cầu lock trên PoolManager.
PoolManager thêm địa chỉ hợp đồng locker vào hàng đợi lockData và gọi lại lockAcquired.
Hợp đồng locker thực hiện logic của nó trong callback. Trong quá trình thực hiện, sự tương tác giữa hợp đồng locker và bể có thể dẫn đến sự gia tăng tiền tệ không bằng 0. Tuy nhiên, khi kết thúc thực hiện, tất cả các gia tăng phải được thanh toán về 0. Ngoài ra, nếu hàng đợi lockData không trống, chỉ hợp đồng locker cuối cùng mới có thể thực hiện thao tác.
PoolManager kiểm tra trạng thái của hàng đợi lockData và sự gia tăng tiền tệ. Sau khi xác minh, PoolManager sẽ xóa hợp đồng locker đó.
Tóm lại, cơ chế khóa ngăn chặn việc truy cập đồng thời và đảm bảo tất cả giao dịch đều được thanh toán. Hợp đồng locker sẽ yêu cầu khóa theo thứ tự, sau đó thực hiện giao dịch thông qua callback lockAcquired. Mỗi lần thao tác trong pool trước và sau sẽ kích hoạt các callback Hook tương ứng. Cuối cùng, PoolManager sẽ kiểm tra trạng thái.
Phương pháp này có nghĩa là việc điều chỉnh hoạt động là số dư ròng nội bộ ( tức là delta ), chứ không phải thực hiện chuyển khoản ngay lập tức. Mọi sửa đổi sẽ được ghi lại trong số dư nội bộ của bể, và việc chuyển khoản thực tế sẽ diễn ra khi hoạt động ( tức là lock ) kết thúc. Quy trình này đảm bảo rằng không có mã thông báo nào chưa thanh toán, từ đó duy trì tính toàn vẹn của quỹ.
Do cơ chế khóa tồn tại, tất cả các tài khoản bên ngoài (EOA) không thể tương tác trực tiếp với PoolManager. Thay vào đó, mọi tương tác phải thông qua hợp đồng. Hợp đồng này hoạt động như một locker trung gian, cần yêu cầu khóa trước khi thực hiện bất kỳ thao tác nào với pool.
Chủ yếu có hai tình huống tương tác hợp đồng:
hợp đồng locker đến từ kho mã chính thức hoặc được người dùng triển khai. Tình huống này có thể được coi là tương tác thông qua bộ định tuyến.
Hợp đồng locker và Hook được tích hợp vào cùng một hợp đồng, hoặc được kiểm soát bởi một thực thể bên thứ ba. Tình huống này có thể được coi là tương tác thông qua Hook. Lúc này, Hook vừa đóng vai trò của hợp đồng locker, vừa chịu trách nhiệm xử lý các callback.
Mô hình đe dọa
Trước khi thảo luận về các vấn đề an ninh liên quan, chúng ta cần xác định mô hình mối đe dọa. Chúng ta chủ yếu xem xét hai trường hợp sau:
Mô hình đe dọa I: Hook bản thân là thiện lành, nhưng có lỗ hổng.
Mô hình đe dọa II: Hook bản thân nó là độc hại.
Tiếp theo sẽ thảo luận về các vấn đề an ninh tiềm ẩn dựa trên hai mô hình mối đe dọa này.
2.1 Vấn đề an ninh trong mô hình đe dọa I
Mô hình đe dọa I tập trung vào các lỗ hổng liên quan đến chính Hook. Mô hình đe dọa này giả định rằng nhà phát triển và Hook của họ không có ác ý. Tuy nhiên, các lỗ hổng đã biết hiện có trong hợp đồng thông minh cũng có thể xuất hiện trong Hook. Ví dụ, nếu Hook được triển khai dưới hình thức hợp đồng có thể nâng cấp, thì nó có thể gặp phải các vấn đề liên quan tương tự như lỗ hổng UUPSUpgradeable của OpenZeppelin.
Xét đến các yếu tố trên, chúng tôi chọn tập trung vào các lỗ hổng tiềm tàng đặc trưng của phiên bản v4. Trong Uniswap v4, Hook là một hợp đồng thông minh có thể thực hiện logic tùy chỉnh trước hoặc sau khi thao tác trên hồ chứa chính ( bao gồm khởi tạo, thay đổi vị trí, trao đổi và thu thập ). Mặc dù Hook dự kiến sẽ thực hiện giao diện tiêu chuẩn, nhưng cũng cho phép bao gồm logic tùy chỉnh. Do đó, phạm vi thảo luận của chúng tôi sẽ giới hạn trong logic liên quan đến giao diện Hook tiêu chuẩn. Sau đó, chúng tôi sẽ cố gắng tìm ra các nguồn gốc lỗ hổng có thể, chẳng hạn như Hook có thể lạm dụng các hàm Hook tiêu chuẩn này như thế nào.
Cụ thể, chúng ta sẽ tập trung vào hai loại Hook sau:
Loại hook đầu tiên, giữ tiền của người dùng. Trong trường hợp này, kẻ tấn công có thể tấn công hook này để chuyển tiền, gây ra tổn thất tài sản.
Loại hook thứ hai, lưu trữ dữ liệu trạng thái quan trọng mà người dùng hoặc các giao thức khác phụ thuộc vào. Trong trường hợp này, kẻ tấn công có thể cố gắng thay đổi trạng thái quan trọng. Khi người dùng hoặc giao thức khác sử dụng trạng thái sai, điều này có thể mang lại rủi ro tiềm ẩn.
Xin lưu ý, các hook nằm ngoài hai phạm vi này không nằm trong phạm vi thảo luận của chúng tôi.
Sau khi nghiên cứu sâu về kho Awesome Uniswap v4 Hooks, chúng tôi đã phát hiện ra một số lỗ hổng nghiêm trọng. Những lỗ hổng này chủ yếu phát sinh từ sự tương tác rủi ro giữa hook, PoolManager và bên thứ ba bên ngoài, chủ yếu có thể được chia thành hai loại: vấn đề kiểm soát truy cập và vấn đề xác thực đầu vào.
Nói chung, chúng tôi đã phát hiện 22 dự án liên quan ( loại trừ các dự án không liên quan đến Uniswap v4 ). Trong số các dự án này, chúng tôi cho rằng có 8 dự án (36%) có lỗ hổng. Trong 8 dự án có lỗ hổng này, 6 dự án gặp vấn đề về kiểm soát truy cập, 2 dự án dễ bị tấn công từ các cuộc gọi bên ngoài không đáng tin cậy.
2.1.1 Vấn đề kiểm soát truy cập
Trong phần thảo luận này, chúng tôi chủ yếu tập trung vào các vấn đề có thể phát sinh từ các hàm gọi lại trong v4, bao gồm 8 hàm hook và hàm lock. Tất nhiên, còn có những trường hợp khác cần được xác thực, nhưng những trường hợp này khác nhau do thiết kế và không nằm trong phạm vi thảo luận của chúng tôi.
Các hàm này chỉ nên được gọi bởi PoolManager, không thể được gọi bởi địa chỉ khác ( bao gồm EOA và hợp đồng ). Ví dụ, trong trường hợp phần thưởng được phân phối bởi khóa quỹ, nếu hàm tương ứng có thể được gọi bởi bất kỳ tài khoản nào, thì phần thưởng có thể bị nhận sai.
Do đó, đối với hook, việc thiết lập cơ chế kiểm soát truy cập mạnh mẽ là rất quan trọng, đặc biệt là khi chúng có thể bị gọi bởi các bên khác ngoài chính bể thanh khoản. Bằng cách quản lý quyền truy cập một cách nghiêm ngặt, bể thanh khoản có thể giảm đáng kể rủi ro liên quan đến việc tương tác không được phép hoặc tương tác ác ý với hook.
2.1.2 Vấn đề xác thực đầu vào
Trong Uniswap v4, do có cơ chế khóa, người dùng phải nhận được một lock từ hợp đồng trước khi thực hiện bất kỳ thao tác nào với quỹ. Điều này đảm bảo rằng hợp đồng đang tham gia tương tác hiện tại là hợp đồng khóa mới nhất.
Mặc dù vậy, vẫn tồn tại một kịch bản tấn công có thể xảy ra, đó là các cuộc gọi bên ngoài không đáng tin cậy do xác thực đầu vào không đúng cách trong một số triển khai Hook dễ bị tấn công:
Đầu tiên, hook không xác minh quỹ mà người dùng dự định tương tác. Đây có thể là một quỹ độc hại chứa token giả mạo và thực hiện logic có hại.
Thứ hai, một số hàm hook quan trọng cho phép gọi từ bên ngoài tùy ý.
Các cuộc gọi bên ngoài không đáng tin cậy cực kỳ nguy hiểm, vì chúng có thể dẫn đến nhiều loại tấn công khác nhau, bao gồm cả cuộc tấn công tái nhập mà chúng ta đã biết.
Để tấn công những hook dễ bị tổn thương này, kẻ tấn công có thể đăng ký một bể tiền tệ độc hại cho các token giả của mình, sau đó gọi hook để thực hiện các thao tác trong bể tiền tệ. Khi tương tác với bể tiền tệ, logic của token độc hại chiếm quyền kiểm soát dòng chảy để thực hiện các hành vi xấu.
2.1.3 Các biện pháp phòng ngừa đối với mô hình đe dọa I
Để tránh các vấn đề bảo mật liên quan đến hook, việc thực hiện kiểm soát truy cập cần thiết đối với các hàm bên ngoài/công cộng nhạy cảm một cách thích hợp và xác minh các tham số đầu vào, từ đó xác thực các tương tác là vô cùng quan trọng. Hơn nữa, bảo vệ chống tái nhập có thể giúp đảm bảo rằng hook sẽ không được thực thi lại trong quy trình logic tiêu chuẩn. Bằng cách thực hiện các biện pháp bảo vệ an toàn thích hợp, quỹ có thể giảm thiểu rủi ro liên quan đến các mối đe dọa như vậy.
2.2 Vấn đề bảo mật trong mô hình đe dọa II
Trong mô hình đe dọa này, chúng tôi giả định rằng nhà phát triển và hook của họ là độc hại. Do phạm vi liên quan rất rộng, chúng tôi chỉ tập trung vào các vấn đề bảo mật liên quan đến phiên bản v4. Do đó, điều quan trọng là hook được cung cấp có thể xử lý tài sản mã hóa trong các giao dịch chuyển tiền hoặc ủy quyền của người dùng hay không.
Do việc truy cập phương thức hook quyết định quyền có thể được cấp cho hook, chúng tôi đã phân loại hook thành hai loại:
Hook ( được quản lý: hook không phải là điểm vào. Người dùng phải tương tác với hook thông qua router ) có thể được cung cấp bởi Uniswap.
Hook độc lập ( Standalone Hooks ): hook là điểm vào, cho phép người dùng tương tác trực tiếp.
(# 2.2.1 Hook kiểu ủy thác
Trong trường hợp này, tài sản tiền điện tử của người dùng ) bao gồm token gốc và các token khác ### được chuyển giao hoặc ủy quyền cho router. Do PoolManager thực hiện kiểm tra số dư, các hook độc hại không dễ dàng trực tiếp đánh cắp những tài sản này. Tuy nhiên, vẫn tồn tại những điểm tấn công tiềm ẩn. Ví dụ, cơ chế quản lý phí phiên bản v4 có thể bị kẻ tấn công thao túng thông qua hook.
(# 2.2.2 Hook độc lập
Khi Hook được sử dụng như một điểm vào, tình hình trở nên phức tạp hơn. Trong trường hợp này, do người dùng có thể tương tác trực tiếp với hook, hook đã có được nhiều quyền lực hơn. Về lý thuyết, hook có thể thực hiện bất kỳ thao tác nào mong muốn thông qua sự tương tác này.
Trong phiên bản v4, việc xác minh logic mã là vô cùng quan trọng. Vấn đề chính là liệu có thể thao túng logic mã hay không. Nếu hook có thể nâng cấp, điều này có nghĩa là một hook có vẻ an toàn có thể trở thành độc hại sau khi nâng cấp, từ đó tạo ra rủi ro lớn. Những rủi ro này bao gồm:
Đại lý có thể nâng cấp ) có thể bị tấn công trực tiếp ###;
Có logic tự hủy. Có thể bị tấn công trong trường hợp gọi chung selfdestruct và create2.
(# 2.2.3 Biện pháp phòng ngừa đối với mô hình đe dọa II
Điều quan trọng là đánh giá xem hook có phải là độc hại hay không. Cụ thể, đối với hook được quản lý, chúng ta nên chú ý đến hành vi quản lý phí; trong khi đó, đối với hook độc lập, điểm chú ý chính là liệu chúng có thể được nâng cấp hay không.
![Tại sao Hook được gọi là "con dao hai lưỡi" của Uniswap V4?])https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp###
Kết luận
Bài viết này trước tiên tóm tắt các cơ chế cốt lõi liên quan đến các vấn đề an ninh của Hook trong Uniswap v4. Sau đó, chúng tôi đưa ra hai mô hình mối đe dọa và tóm tắt ngắn gọn các rủi ro an ninh liên quan.
Trong các bài viết tiếp theo, chúng tôi sẽ phân tích sâu về các vấn đề an ninh trong từng mô hình đe dọa.