Uniswap v4 sắp ra mắt, cơ chế Hook tiềm ẩn nguy cơ an toàn
Uniswap v4 sắp được phát hành, bản cập nhật này 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 vô hạn các pool 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. Dự kiến v4 sẽ được phát hành sau khi nâng cấp Ethereum Cancun.
Trong số nhiều đổi mới, cơ chế Hook được chú ý vì tiềm năng mạnh mẽ của nó. Nó cho phép thực thi mã tùy chỉnh tại các thời điểm cụ thể trong vòng đời của bể thanh khoản, tăng cường đáng kể khả năng mở rộng và tính 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ù chức năng mạnh mẽ và linh hoạt, nhưng việc sử dụng Hook một cách an toàn cũng gặp phải những thách thức. Sự phức tạp của Hook không thể tránh khỏi việc mang lại những vectơ tấn công tiềm năng mới. Do đó, việc hệ thống hóa giới thiệu các vấn đề an ninh và rủi ro tiềm ẩn liên quan đến cơ chế Hook là vô cùng quan trọng, điều này sẽ giúp xây dựng một Uniswap v4 Hook an toàn hơn.
Bài viết này sẽ giới thiệu về cơ chế Hook trong Uniswap v4 và tóm tắt các rủi ro an ninh mà nó có thể gặp phả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 thể và kế toán chớp nhoáng là ba chức năng quan trọng để hiện thực hóa các bể thanh khoản tùy chỉnh và định tuyến hiệu quả qua nhiều bể.
Hook
Hook chỉ các hợp đồng hoạt động ở các giai đoạn khác nhau của vòng đời của quỹ thanh khoản, nhóm Uniswap hy vọng 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 cho phí động, thêm lệnh giới hạn trên chuỗi, hoặc thông qua việc trung bình theo trọng số thời gian để tạo thị trường (TWAMM) phân tán các đơn hàng lớn.
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ước khi hoán đổi/sau khi hoán đổi
trướcDonate/sauDonate
Mô hình đơn, ghi sổ nhanh và cơ chế khóa
Kiến trúc đơn thể và ghi chép 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 một PoolManager để lưu trữ và quản lý trạng thái của tất cả các bể.
Phiên bản v4 đã giới thiệu tính năng ghi sổ nhanh và cơ chế khóa. Cách 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 quá trình callback. Trong quá trình thực hiện, sự tương tác giữa hợp đồng locker và pool có thể dẫn đến sự gia tăng tiền tệ khác không bằng không. Tuy nhiên, vào cuối quá trình thực hiện, tất cả các gia tăng phải được thanh toán về không. Ngoài ra, nếu hàng đợi lockData không rỗng, chỉ có hợp đồng locker cuối cùng 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 thực, 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ả các giao dịch đều có thể được thanh toán. Hợp đồng locker 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 sẽ kích hoạt callback Hook tương ứng trước và sau. 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 là 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ể, việc chuyển khoản thực tế sẽ diễn ra vào thời điểm kết thúc hoạt động ( tức là lock ). Quá trình này đảm bảo rằng không có token nào chưa được thanh lý, do đó duy trì tính toàn vẹn của quỹ.
Do bởi cơ chế khóa, 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 một hợp đồng. Hợp đồng này hoạt động như một cái khóa trung gian, yêu cầu phải có yêu cầu khóa trước khi thực hiện bất kỳ thao tác nào với bể.
Có hai kịch bản tương tác hợp đồng chính:
hợp đồng locker đến từ kho mã chính thức, hoặc được người dùng triển khai. Trong trường hợp này, chúng ta có thể coi việc tương tác như là 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. Đối với trường hợp này, chúng ta có thể coi việc tương tác là thông qua Hook. Trong trường hợp này, Hook vừa đóng vai trò của hợp đồng locker, vừa chịu trách nhiệm xử lý 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 đe dọa. Hai tình huống chính cần xem xét là:
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.
Trong phần tiếp theo, chúng tôi sẽ thảo luận về các vấn đề an ninh tiềm ẩn dựa trên hai mô hình đe dọa này.
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ó ý xấu. 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.
Chúng tôi chọn tập trung vào các lỗ hổng tiềm ẩn đặ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 thực hiện các thao tác chính trên hồ bơi (, 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 nó 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 các 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 có thể gây ra lỗ hổng, chẳng hạn như cách Hook có thể lạm dụng các hàm Hook tiêu chuẩn này.
Cụ thể, chúng tôi sẽ tập trung vào hai loại Hook sau:
Loại hook đầu tiên, quản lý quỹ 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 thiệt hại 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.
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 xuất phát từ sự tương tác rủi ro giữa hook, PoolManager và các bên thứ ba bên ngoài, chủ yếu có thể 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ị gọi từ bên ngoài không đáng tin cậy.
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 callback trong v4, bao gồm 8 hàm hook callback và lock callback. Những hàm này chỉ nên được gọi bởi PoolManager, không được gọi bởi các đị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át bởi khóa quỹ, nếu các 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 đó, việc thiết lập một cơ chế kiểm soát truy cập mạnh mẽ là rất quan trọng đối với hook, đặc biệt là khi chúng có thể được gọi bởi các bên ngoài 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 thiểu đáng kể rủi ro liên quan đến việc tương tác trái phép hoặc ác ý với hook.
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 khóa thông qua 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 hiện tại tham gia tương tác 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 khả thi, đó 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ả 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 bên ngoài tùy ý.
Các cuộc gọi bên ngoài không đáng tin cậy là vô cùng 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ả tấn công tái nhập mà chúng ta đã biết.
Để tấn công các hook dễ bị tổn thương này, kẻ tấn công có thể đăng ký một hồ bơi 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 hồ bơi tiền tệ. Khi tương tác với hồ bơi tiền tệ, logic của token độc hại chiếm quyền điều khiển luồng để thực hiện hành vi xấu.
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 khai nhạy cảm một cách thích hợp và xác thực các tham số đầu vào để xác minh các tương tác là rất quan trọng. Ngoài ra, bảo vệ tái nhập có thể giúp đảm bảo rằng hook không bị thực hiện lại trong quy trình logic tiêu chuẩn. Thông qua việc 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.
Vấn đề an ninh 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 các 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 của người dùng trong việc chuyển tiền hoặc ủy quyền.
Do việc truy cập vào phương thức hook quyết định quyền có thể được cấp cho hook, chúng tôi chia hook thành hai loại:
Hook ủy thác ( Managed Hooks ): 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 truy cập, cho phép người dùng tương tác trực tiếp.
Hook ủ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 nhượng hoặc ủy quyền cho router. Do PoolManager thực hiện kiểm tra số dư, hook độc hại khó có thể trực tiếp đánh cắp những tài sản này. Tuy nhiên, vẫn tồn tại các bề mặt tấn công tiềm ẩn. Ví dụ, cơ chế quản lý phí của phiên bản v4 có thể bị kẻ tấn công thao túng thông qua hook.
Hook độc lập
Khi Hook được sử dụng làm điểm vào, tình huống trở nên phức tạp hơn. Trong trường hợp này, vì người dùng có thể tương tác trực tiếp với hook, hook đã có thêm quyền lực. 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 thực logic mã là rất 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ừ đó gây 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 kết hợp selfdestruct và create2.
Các biện pháp phòng ngừa đối với mô hình mối đe dọa II
Một điểm 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 quan tâm chính là liệu chúng có thể nâng cấp hay không.
Kết luận
Bài viết này tóm tắt các cơ chế cốt lõi liên quan đến vấn đề an toàn của Hook trong Uniswap v4, đưa ra hai mô hình đe dọa và tóm tắt các rủi ro an toàn 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 mỗi 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.
Cơ chế Hook của Uniswap v4 có nguy cơ an ninh, chuyên gia cảnh báo cần thận trọng khi sử dụng
Uniswap v4 sắp ra mắt, cơ chế Hook tiềm ẩn nguy cơ an toàn
Uniswap v4 sắp được phát hành, bản cập nhật này 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 vô hạn các pool 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. Dự kiến v4 sẽ được phát hành sau khi nâng cấp Ethereum Cancun.
Trong số nhiều đổi mới, cơ chế Hook được chú ý vì tiềm năng mạnh mẽ của nó. Nó cho phép thực thi mã tùy chỉnh tại các thời điểm cụ thể trong vòng đời của bể thanh khoản, tăng cường đáng kể khả năng mở rộng và tính 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ù chức năng mạnh mẽ và linh hoạt, nhưng việc sử dụng Hook một cách an toàn cũng gặp phải những thách thức. Sự phức tạp của Hook không thể tránh khỏi việc mang lại những vectơ tấn công tiềm năng mới. Do đó, việc hệ thống hóa giới thiệu các vấn đề an ninh và rủi ro tiềm ẩn liên quan đến cơ chế Hook là vô cùng quan trọng, điều này sẽ giúp xây dựng một Uniswap v4 Hook an toàn hơn.
Bài viết này sẽ giới thiệu về cơ chế Hook trong Uniswap v4 và tóm tắt các rủi ro an ninh mà nó có thể gặp phả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 thể và kế toán chớp nhoáng là ba chức năng quan trọng để hiện thực hóa các bể thanh khoản tùy chỉnh và định tuyến hiệu quả qua nhiều bể.
Hook
Hook chỉ các hợp đồng hoạt động ở các giai đoạn khác nhau của vòng đời của quỹ thanh khoản, nhóm Uniswap hy vọng 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 cho phí động, thêm lệnh giới hạn trên chuỗi, hoặc thông qua việc trung bình theo trọng số thời gian để tạo thị trường (TWAMM) phân tán các đơn hàng lớn.
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 ):
Mô hình đơn, ghi sổ nhanh và cơ chế khóa
Kiến trúc đơn thể và ghi chép 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 một PoolManager để lưu trữ và quản lý trạng thái của tất cả các bể.
Phiên bản v4 đã giới thiệu tính năng ghi sổ nhanh và cơ chế khóa. Cách 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 quá trình callback. Trong quá trình thực hiện, sự tương tác giữa hợp đồng locker và pool có thể dẫn đến sự gia tăng tiền tệ khác không bằng không. Tuy nhiên, vào cuối quá trình thực hiện, tất cả các gia tăng phải được thanh toán về không. Ngoài ra, nếu hàng đợi lockData không rỗng, chỉ có hợp đồng locker cuối cùng 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 thực, 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ả các giao dịch đều có thể được thanh toán. Hợp đồng locker 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 sẽ kích hoạt callback Hook tương ứng trước và sau. 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 là 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ể, việc chuyển khoản thực tế sẽ diễn ra vào thời điểm kết thúc hoạt động ( tức là lock ). Quá trình này đảm bảo rằng không có token nào chưa được thanh lý, do đó duy trì tính toàn vẹn của quỹ.
Do bởi cơ chế khóa, 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 một hợp đồng. Hợp đồng này hoạt động như một cái khóa trung gian, yêu cầu phải có yêu cầu khóa trước khi thực hiện bất kỳ thao tác nào với bể.
Có hai kịch bản tương tác hợp đồng chính:
hợp đồng locker đến từ kho mã chính thức, hoặc được người dùng triển khai. Trong trường hợp này, chúng ta có thể coi việc tương tác như là 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. Đối với trường hợp này, chúng ta có thể coi việc tương tác là thông qua Hook. Trong trường hợp này, Hook vừa đóng vai trò của hợp đồng locker, vừa chịu trách nhiệm xử lý 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 đe dọa. Hai tình huống chính cần xem xét là:
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.
Trong phần tiếp theo, chúng tôi sẽ thảo luận về các vấn đề an ninh tiềm ẩn dựa trên hai mô hình đe dọa này.
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ó ý xấu. 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.
Chúng tôi chọn tập trung vào các lỗ hổng tiềm ẩn đặ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 thực hiện các thao tác chính trên hồ bơi (, 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 nó 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 các 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 có thể gây ra lỗ hổng, chẳng hạn như cách Hook có thể lạm dụng các hàm Hook tiêu chuẩn này.
Cụ thể, chúng tôi sẽ tập trung vào hai loại Hook sau:
Loại hook đầu tiên, quản lý quỹ 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 thiệt hại 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.
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 xuất phát từ sự tương tác rủi ro giữa hook, PoolManager và các bên thứ ba bên ngoài, chủ yếu có thể 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ị gọi từ bên ngoài không đáng tin cậy.
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 callback trong v4, bao gồm 8 hàm hook callback và lock callback. Những hàm này chỉ nên được gọi bởi PoolManager, không được gọi bởi các đị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át bởi khóa quỹ, nếu các 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 đó, việc thiết lập một cơ chế kiểm soát truy cập mạnh mẽ là rất quan trọng đối với hook, đặc biệt là khi chúng có thể được gọi bởi các bên ngoài 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 thiểu đáng kể rủi ro liên quan đến việc tương tác trái phép hoặc ác ý với hook.
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 khóa thông qua 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 hiện tại tham gia tương tác 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 khả thi, đó 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ả 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 bên ngoài tùy ý.
Các cuộc gọi bên ngoài không đáng tin cậy là vô cùng 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ả tấn công tái nhập mà chúng ta đã biết.
Để tấn công các hook dễ bị tổn thương này, kẻ tấn công có thể đăng ký một hồ bơi 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 hồ bơi tiền tệ. Khi tương tác với hồ bơi tiền tệ, logic của token độc hại chiếm quyền điều khiển luồng để thực hiện hành vi xấu.
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 khai nhạy cảm một cách thích hợp và xác thực các tham số đầu vào để xác minh các tương tác là rất quan trọng. Ngoài ra, bảo vệ tái nhập có thể giúp đảm bảo rằng hook không bị thực hiện lại trong quy trình logic tiêu chuẩn. Thông qua việc 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.
Vấn đề an ninh 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 các 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 của người dùng trong việc chuyển tiền hoặc ủy quyền.
Do việc truy cập vào phương thức hook quyết định quyền có thể được cấp cho hook, chúng tôi chia hook thành hai loại:
Hook ủy thác ( Managed Hooks ): 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 truy cập, cho phép người dùng tương tác trực tiếp.
Hook ủ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 nhượng hoặc ủy quyền cho router. Do PoolManager thực hiện kiểm tra số dư, hook độc hại khó có thể trực tiếp đánh cắp những tài sản này. Tuy nhiên, vẫn tồn tại các bề mặt tấn công tiềm ẩn. Ví dụ, cơ chế quản lý phí của phiên bản v4 có thể bị kẻ tấn công thao túng thông qua hook.
Hook độc lập
Khi Hook được sử dụng làm điểm vào, tình huống trở nên phức tạp hơn. Trong trường hợp này, vì người dùng có thể tương tác trực tiếp với hook, hook đã có thêm quyền lực. 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 thực logic mã là rất 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ừ đó gây 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 kết hợp selfdestruct và create2.
Các biện pháp phòng ngừa đối với mô hình mối đe dọa II
Một điểm 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 quan tâm chính là liệu chúng có thể nâng cấp hay không.
Kết luận
Bài viết này tóm tắt các cơ chế cốt lõi liên quan đến vấn đề an toàn của Hook trong Uniswap v4, đưa ra hai mô hình đe dọa và tóm tắt các rủi ro an toàn 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 mỗi mô hình đe dọa.