La dualidad del mecanismo Hook de Uniswap v4: Innovación y riesgos potenciales coexistentes
Uniswap v4 se lanzará pronto, y esta actualización es verdaderamente ambiciosa. La nueva versión introducirá varias funciones nuevas, incluyendo soporte para un número ilimitado de grupos de liquidez por par de negociación y tarifas dinámicas, diseño de instancia única, contabilidad instantánea, mecanismo Hook, así como soporte para el estándar de tokens ERC1155. Utilizando tecnología de almacenamiento transitorio, se espera que Uniswap v4 sea lanzado después de la actualización de Ethereum Cancún.
Entre muchas innovaciones, el mecanismo Hook ha llamado la atención por su gran potencial. Este mecanismo permite ejecutar código personalizado en nodos específicos del ciclo de vida del pool de liquidez, lo que mejora significativamente la escalabilidad y flexibilidad del pool.
Sin embargo, el mecanismo Hook también puede ser un arma de doble filo. A pesar de ser potente y flexible, el uso seguro de Hook enfrenta igualmente desafíos considerables. La complejidad de Hook inevitablemente trae consigo nuevos vectores de ataque potenciales. Por lo tanto, es necesario presentar de manera sistemática los problemas de seguridad y los riesgos potenciales asociados con el mecanismo Hook, para promover el desarrollo seguro de la comunidad; estas ideas ayudarán a construir un Uniswap v4 Hook más seguro.
Este artículo presentará los conceptos relacionados con el mecanismo Hook en Uniswap v4 y resumirá los riesgos de seguridad que existen.
Mecanismo de Uniswap V4
Antes de profundizar, necesitamos tener un entendimiento básico del mecanismo de Uniswap v4. Según el anuncio oficial y el libro blanco, Hook, la arquitectura de instancia única y la contabilidad instantánea son tres funciones importantes para implementar grupos de liquidez personalizados y enrutar de manera eficiente a través de múltiples grupos.
1.1 Gancho
Hook se refiere a contratos que operan en diferentes etapas del ciclo de vida de un fondo de liquidez. El equipo de Uniswap espera que al introducir Hook, cualquier persona pueda tomar decisiones de compensación. Este enfoque permite el soporte nativo de tarifas dinámicas, la adición de órdenes limitadas en cadena, o la dispersión de grandes órdenes a través de un creador de mercado de promedio ponderado por tiempo (TWAMM).
Actualmente hay ocho callbacks Hook, divididos en cuatro grupos ( cada grupo contiene un par de callbacks ):
beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
antesDelIntercambio/despuésDelIntercambio
antesDeDonar/despuésDeDonar
El equipo de Uniswap ha proporcionado algunos ejemplos ( como el método de operación del TWAMM Hook ), y los participantes de la comunidad también han hecho algunas contribuciones. La documentación oficial también enlaza al repositorio Awesome Uniswap v4 Hooks, que recopila más ejemplos de Hooks.
1.2 Singleton, contabilidad relámpago y mecanismo de bloqueo
La arquitectura de singleton y la contabilidad relámpago están diseñadas para mejorar el rendimiento al reducir costos y asegurar eficiencia. Introduce un nuevo contrato singleton, donde todos los pools de liquidez se almacenan en el mismo contrato inteligente. Este diseño de singleton depende de PoolManager para almacenar y gestionar el estado de todos los pools.
La versión v4 de Uniswap introduce la contabilidad relámpago y el mecanismo de bloqueo. El funcionamiento del mecanismo de bloqueo es el siguiente:
El contrato locker solicita lock en PoolManager.
PoolManager agrega la dirección del contrato locker a la cola lockData y llama a su callback lockAcquired.
El contrato locker ejecuta su lógica en la devolución de llamada. Durante el proceso de ejecución, la interacción del contrato locker con el fondo puede llevar a un incremento monetario distinto de cero. Sin embargo, al finalizar la ejecución, todos los incrementos deben liquidarse a cero. Además, si la cola lockData no está vacía, solo el último contrato locker puede realizar operaciones.
PoolManager verifica el estado de la cola lockData y el incremento de moneda. Después de la verificación, PoolManager eliminará el contrato del locker.
En resumen, el mecanismo de bloqueo previene el acceso concurrente y asegura que todas las transacciones puedan ser liquidadas. El contrato de bloqueo solicita el lock en orden, y luego ejecuta la transacción a través de la devolución de llamada lockAcquired. Antes y después de cada operación en el pool se activarán las devoluciones de llamada Hook correspondientes. Por último, el PoolManager verificará el estado.
Este método implica que la operación ajusta el saldo neto interno (, es decir, delta ), en lugar de ejecutar una transferencia instantánea. Cualquier modificación se registrará en el saldo interno del pool, y la transferencia real se llevará a cabo al final de la operación (, es decir, lock ). Este proceso garantiza que no haya tokens no liquidadas, manteniendo así la integridad de los fondos.
Debido a la existencia del mecanismo de bloqueo, todas las cuentas externas (EOA) no pueden interactuar directamente con el PoolManager. En cambio, cualquier interacción debe realizarse a través de un contrato. Este contrato actúa como un intermediario de bloqueo y necesita solicitar un bloqueo antes de realizar cualquier operación en la piscina.
Principalmente existen dos tipos de escenarios de interacción de contratos:
El contrato locker proviene del repositorio de código oficial o es implementado por el usuario. Esta situación puede considerarse como una interacción a través de un enrutador.
El contrato de locker y Hook se integran en el mismo contrato, o son controlados por una entidad externa. Esta situación puede considerarse como una interacción a través de Hook. En este momento, Hook actúa tanto como el contrato de locker como el encargado de manejar las devoluciones de llamada.
Modelo de Amenazas
Antes de discutir los problemas de seguridad relacionados, necesitamos determinar el modelo de amenazas. Las siguientes dos situaciones son las principales que debemos considerar:
Modelo de amenaza I: Hook en sí es benigno, pero tiene vulnerabilidades.
Modelo de amenaza II: Hook es en sí mismo malicioso.
A continuación, se discutirán los problemas de seguridad potenciales según estos dos modelos de amenaza.
2.1 Problemas de seguridad en el modelo de amenaza I
El modelo de amenaza I se centra en las vulnerabilidades relacionadas con el Hook en sí. Este modelo de amenaza asume que el desarrollador y su Hook son benignos. Sin embargo, las vulnerabilidades conocidas existentes en los contratos inteligentes también pueden aparecer en el Hook. Por ejemplo, si el Hook se implementa como un contrato actualizable, podría enfrentar problemas relacionados similares a las vulnerabilidades UUPSUpgradeable de OpenZeppelin.
Dado los factores mencionados, hemos decidido centrarnos en las vulnerabilidades potenciales específicas de la versión v4. En Uniswap v4, el Hook es un contrato inteligente que puede ejecutar lógica personalizada antes o después de realizar operaciones en el pool principal (, incluyendo la inicialización, modificación de posiciones, intercambios y recolección de ). Aunque se espera que el Hook implemente una interfaz estándar, también permite incluir lógica personalizada. Por lo tanto, nuestro alcance de discusión se limitará a la lógica relacionada con la interfaz estándar del Hook. Luego, intentaremos identificar posibles fuentes de vulnerabilidad, por ejemplo, cómo el Hook podría abusar de estas funciones estándar del Hook.
En concreto, nos centraremos en las siguientes dos Hook:
El primer tipo de hook, custodia de los fondos de los usuarios. En este caso, el atacante podría atacar este hook para transferir fondos, causando pérdidas de activos.
Un segundo tipo de hook, que almacena datos de estado críticos que dependen de los usuarios u otros protocolos. En este caso, un atacante podría intentar cambiar el estado crítico. Cuando otros usuarios o protocolos utilizan un estado incorrecto, esto podría conllevar riesgos potenciales.
Por favor, tenga en cuenta que los hooks fuera de estos dos rangos no están dentro del alcance de nuestra discusión.
Tras investigar a fondo el repositorio de Awesome Uniswap v4 Hooks, encontramos varios fallos graves. Estos fallos provienen principalmente de la interacción de riesgos entre hook, PoolManager y terceros externos, y se pueden clasificar en dos categorías: problemas de control de acceso y problemas de validación de entrada.
En general, encontramos 22 proyectos relevantes ( excluyendo los proyectos no relacionados con Uniswap v4 ). De estos proyectos, creemos que 8 (36%) tienen vulnerabilidades. De estos 8 proyectos con vulnerabilidades, 6 tienen problemas de control de acceso y 2 son susceptibles a llamadas externas no confiables.
2.1.1 Problemas de control de acceso
En esta parte de la discusión, nos centramos principalmente en los problemas que pueden surgir con las funciones de callback en v4, incluyendo 8 callbacks de hook y el callback de lock. Por supuesto, también hay otras situaciones que necesitan ser verificadas, pero estas varían según el diseño y no están dentro del alcance de nuestra discusión.
Estas funciones solo deben poder ser llamadas por PoolManager, y no por otras direcciones (, incluidas EOA y contratos ). Por ejemplo, en el caso de que las recompensas sean distribuidas por la clave del fondo de liquidez, si la función correspondiente puede ser llamada por cualquier cuenta, entonces las recompensas podrían ser reclamadas incorrectamente.
Por lo tanto, para los hooks, es crucial establecer un mecanismo de control de acceso sólido, especialmente porque pueden ser llamados por partes ajenas al propio pool. Al gestionar estrictamente los permisos de acceso, el pool de liquidez puede reducir significativamente el riesgo de interacciones no autorizadas o maliciosas con el hook.
2.1.2 Problemas de validación de entrada
En Uniswap v4, debido a la existencia de un mecanismo de bloqueo, los usuarios deben obtener un lock a través del contrato antes de realizar cualquier operación en el pool de liquidez. Esto asegura que el contrato que actualmente participa en la interacción sea el contrato locker más reciente.
A pesar de esto, existe un posible escenario de ataque, que es una llamada externa no confiable debido a una validación de entrada inadecuada en algunas implementaciones de Hook vulnerables:
Primero, el hook no verifica el fondo con el que el usuario pretende interactuar. Esto podría ser un fondo malicioso que contiene tokens falsos y ejecuta lógica dañina.
En segundo lugar, algunas funciones hook clave permiten llamadas externas arbitrarias.
Las llamadas externas no confiables son extremadamente peligrosas, ya que pueden dar lugar a varios tipos de ataques, incluyendo el ataque de reentrada que conocemos bien.
Para atacar estos hooks vulnerables, un atacante puede registrar un fondo malicioso para su token falso y luego invocar el hook para realizar operaciones en el fondo. Al interactuar con el fondo, la lógica del token malicioso secuestra el flujo de control para llevar a cabo comportamientos indebidos.
2.1.3 Medidas de prevención contra el modelo de amenaza I
Para evitar problemas de seguridad relacionados con hooks, es crucial validar las interacciones mediante la implementación adecuada del control de acceso necesario a funciones externas/públicas sensibles y la verificación de los parámetros de entrada. Además, la protección contra reentradas puede ayudar a garantizar que los hooks no se ejecuten repetidamente en el flujo lógico estándar. Al implementar medidas de seguridad adecuadas, el fondo de capital puede reducir los riesgos asociados con tales amenazas.
2.2 Problemas de seguridad en el modelo de amenaza II
En este modelo de amenaza, asumimos que los desarrolladores y su hook son maliciosos. Dado que el alcance es amplio, nos enfocamos únicamente en los problemas de seguridad relacionados con la versión v4. Por lo tanto, la clave está en si el hook proporcionado puede manejar los activos criptográficos de transferencia o autorización de los usuarios.
Dado que el método de acceso al hook determina los permisos que se pueden otorgar al hook, lo dividimos en dos categorías:
Hook gestionado ( Managed Hooks ): el hook no es un punto de entrada. Los usuarios deben interactuar con el hook a través de un enrutador ( que puede ser proporcionado por Uniswap ).
Ganchos Independientes(: el gancho es un punto de entrada que permite a los usuarios interactuar directamente con él.
)# 2.2.1 Hook de custodia
En este caso, los activos criptográficos del usuario ### incluyen tokens nativos y otros tokens ( que se transfieren o autorizan al router. Dado que el PoolManager realiza una verificación de saldo, los hooks maliciosos no pueden robar directamente estos activos con facilidad. Sin embargo, todavía existe una superficie de ataque potencial. Por ejemplo, el mecanismo de gestión de tarifas de la versión v4 podría ser manipulado por un atacante a través de hooks.
)# 2.2.2 Hook independiente
Cuando se utiliza Hook como punto de entrada, la situación se complica aún más. En este caso, dado que los usuarios pueden interactuar directamente con el hook, este obtiene más poder. Teóricamente, el hook puede ejecutar cualquier operación deseada a través de esta interacción.
En la versión v4, la validación de la lógica del código es muy crítica. El problema principal es si se puede manipular la lógica del código. Si el hook es actualizable, esto significa que un hook que parece seguro podría volverse malicioso después de la actualización, lo que representa un riesgo significativo. Estos riesgos incluyen:
El proxy escalable ### puede ser atacado directamente (;
Con lógica de autodestrucción. Puede ser atacado en el caso de una llamada conjunta de selfdestruct y create2.
)# 2.2.3 Medidas de prevención para el modelo de amenaza II
Un punto crucial es evaluar si el hook es malicioso. Específicamente, para los hooks gestionados, debemos prestar atención a las prácticas de gestión de costos; mientras que para los hooks independientes, el enfoque principal está en si son actualizables.
![¿Por qué se dice que Hook es una "espada de doble filo" en Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusión
Este artículo primero resume brevemente los mecanismos centrales relacionados con los problemas de seguridad del Hook en Uniswap v4. A continuación, presentamos dos modelos de amenaza y describimos brevemente los riesgos de seguridad relacionados.
En artículos posteriores, realizaremos un análisis profundo de los problemas de seguridad bajo cada modelo de amenaza.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
17 me gusta
Recompensa
17
5
Compartir
Comentar
0/400
OfflineValidator
· 07-31 11:18
Aún hay que entender bien el V4.
Ver originalesResponder0
MetaMisery
· 07-30 04:35
No es tan estable como v3, ¿quieres volver a jugar con conceptos?
Ver originalesResponder0
SatoshiNotNakamoto
· 07-30 04:24
Esperando a que aparezca el bug en v4
Ver originalesResponder0
TokenGuru
· 07-30 04:17
La versión evolucionada del viejo proyecto, los tontos que entran sin pensar volverán a sufrir.
Análisis de seguridad del mecanismo Hook de Uniswap v4: innovación y riesgo coexistente
La dualidad del mecanismo Hook de Uniswap v4: Innovación y riesgos potenciales coexistentes
Uniswap v4 se lanzará pronto, y esta actualización es verdaderamente ambiciosa. La nueva versión introducirá varias funciones nuevas, incluyendo soporte para un número ilimitado de grupos de liquidez por par de negociación y tarifas dinámicas, diseño de instancia única, contabilidad instantánea, mecanismo Hook, así como soporte para el estándar de tokens ERC1155. Utilizando tecnología de almacenamiento transitorio, se espera que Uniswap v4 sea lanzado después de la actualización de Ethereum Cancún.
Entre muchas innovaciones, el mecanismo Hook ha llamado la atención por su gran potencial. Este mecanismo permite ejecutar código personalizado en nodos específicos del ciclo de vida del pool de liquidez, lo que mejora significativamente la escalabilidad y flexibilidad del pool.
Sin embargo, el mecanismo Hook también puede ser un arma de doble filo. A pesar de ser potente y flexible, el uso seguro de Hook enfrenta igualmente desafíos considerables. La complejidad de Hook inevitablemente trae consigo nuevos vectores de ataque potenciales. Por lo tanto, es necesario presentar de manera sistemática los problemas de seguridad y los riesgos potenciales asociados con el mecanismo Hook, para promover el desarrollo seguro de la comunidad; estas ideas ayudarán a construir un Uniswap v4 Hook más seguro.
Este artículo presentará los conceptos relacionados con el mecanismo Hook en Uniswap v4 y resumirá los riesgos de seguridad que existen.
Mecanismo de Uniswap V4
Antes de profundizar, necesitamos tener un entendimiento básico del mecanismo de Uniswap v4. Según el anuncio oficial y el libro blanco, Hook, la arquitectura de instancia única y la contabilidad instantánea son tres funciones importantes para implementar grupos de liquidez personalizados y enrutar de manera eficiente a través de múltiples grupos.
1.1 Gancho
Hook se refiere a contratos que operan en diferentes etapas del ciclo de vida de un fondo de liquidez. El equipo de Uniswap espera que al introducir Hook, cualquier persona pueda tomar decisiones de compensación. Este enfoque permite el soporte nativo de tarifas dinámicas, la adición de órdenes limitadas en cadena, o la dispersión de grandes órdenes a través de un creador de mercado de promedio ponderado por tiempo (TWAMM).
Actualmente hay ocho callbacks Hook, divididos en cuatro grupos ( cada grupo contiene un par de callbacks ):
El equipo de Uniswap ha proporcionado algunos ejemplos ( como el método de operación del TWAMM Hook ), y los participantes de la comunidad también han hecho algunas contribuciones. La documentación oficial también enlaza al repositorio Awesome Uniswap v4 Hooks, que recopila más ejemplos de Hooks.
1.2 Singleton, contabilidad relámpago y mecanismo de bloqueo
La arquitectura de singleton y la contabilidad relámpago están diseñadas para mejorar el rendimiento al reducir costos y asegurar eficiencia. Introduce un nuevo contrato singleton, donde todos los pools de liquidez se almacenan en el mismo contrato inteligente. Este diseño de singleton depende de PoolManager para almacenar y gestionar el estado de todos los pools.
La versión v4 de Uniswap introduce la contabilidad relámpago y el mecanismo de bloqueo. El funcionamiento del mecanismo de bloqueo es el siguiente:
El contrato locker solicita lock en PoolManager.
PoolManager agrega la dirección del contrato locker a la cola lockData y llama a su callback lockAcquired.
El contrato locker ejecuta su lógica en la devolución de llamada. Durante el proceso de ejecución, la interacción del contrato locker con el fondo puede llevar a un incremento monetario distinto de cero. Sin embargo, al finalizar la ejecución, todos los incrementos deben liquidarse a cero. Además, si la cola lockData no está vacía, solo el último contrato locker puede realizar operaciones.
PoolManager verifica el estado de la cola lockData y el incremento de moneda. Después de la verificación, PoolManager eliminará el contrato del locker.
En resumen, el mecanismo de bloqueo previene el acceso concurrente y asegura que todas las transacciones puedan ser liquidadas. El contrato de bloqueo solicita el lock en orden, y luego ejecuta la transacción a través de la devolución de llamada lockAcquired. Antes y después de cada operación en el pool se activarán las devoluciones de llamada Hook correspondientes. Por último, el PoolManager verificará el estado.
Este método implica que la operación ajusta el saldo neto interno (, es decir, delta ), en lugar de ejecutar una transferencia instantánea. Cualquier modificación se registrará en el saldo interno del pool, y la transferencia real se llevará a cabo al final de la operación (, es decir, lock ). Este proceso garantiza que no haya tokens no liquidadas, manteniendo así la integridad de los fondos.
Debido a la existencia del mecanismo de bloqueo, todas las cuentas externas (EOA) no pueden interactuar directamente con el PoolManager. En cambio, cualquier interacción debe realizarse a través de un contrato. Este contrato actúa como un intermediario de bloqueo y necesita solicitar un bloqueo antes de realizar cualquier operación en la piscina.
Principalmente existen dos tipos de escenarios de interacción de contratos:
El contrato locker proviene del repositorio de código oficial o es implementado por el usuario. Esta situación puede considerarse como una interacción a través de un enrutador.
El contrato de locker y Hook se integran en el mismo contrato, o son controlados por una entidad externa. Esta situación puede considerarse como una interacción a través de Hook. En este momento, Hook actúa tanto como el contrato de locker como el encargado de manejar las devoluciones de llamada.
Modelo de Amenazas
Antes de discutir los problemas de seguridad relacionados, necesitamos determinar el modelo de amenazas. Las siguientes dos situaciones son las principales que debemos considerar:
Modelo de amenaza I: Hook en sí es benigno, pero tiene vulnerabilidades.
Modelo de amenaza II: Hook es en sí mismo malicioso.
A continuación, se discutirán los problemas de seguridad potenciales según estos dos modelos de amenaza.
2.1 Problemas de seguridad en el modelo de amenaza I
El modelo de amenaza I se centra en las vulnerabilidades relacionadas con el Hook en sí. Este modelo de amenaza asume que el desarrollador y su Hook son benignos. Sin embargo, las vulnerabilidades conocidas existentes en los contratos inteligentes también pueden aparecer en el Hook. Por ejemplo, si el Hook se implementa como un contrato actualizable, podría enfrentar problemas relacionados similares a las vulnerabilidades UUPSUpgradeable de OpenZeppelin.
Dado los factores mencionados, hemos decidido centrarnos en las vulnerabilidades potenciales específicas de la versión v4. En Uniswap v4, el Hook es un contrato inteligente que puede ejecutar lógica personalizada antes o después de realizar operaciones en el pool principal (, incluyendo la inicialización, modificación de posiciones, intercambios y recolección de ). Aunque se espera que el Hook implemente una interfaz estándar, también permite incluir lógica personalizada. Por lo tanto, nuestro alcance de discusión se limitará a la lógica relacionada con la interfaz estándar del Hook. Luego, intentaremos identificar posibles fuentes de vulnerabilidad, por ejemplo, cómo el Hook podría abusar de estas funciones estándar del Hook.
En concreto, nos centraremos en las siguientes dos Hook:
El primer tipo de hook, custodia de los fondos de los usuarios. En este caso, el atacante podría atacar este hook para transferir fondos, causando pérdidas de activos.
Un segundo tipo de hook, que almacena datos de estado críticos que dependen de los usuarios u otros protocolos. En este caso, un atacante podría intentar cambiar el estado crítico. Cuando otros usuarios o protocolos utilizan un estado incorrecto, esto podría conllevar riesgos potenciales.
Por favor, tenga en cuenta que los hooks fuera de estos dos rangos no están dentro del alcance de nuestra discusión.
Tras investigar a fondo el repositorio de Awesome Uniswap v4 Hooks, encontramos varios fallos graves. Estos fallos provienen principalmente de la interacción de riesgos entre hook, PoolManager y terceros externos, y se pueden clasificar en dos categorías: problemas de control de acceso y problemas de validación de entrada.
En general, encontramos 22 proyectos relevantes ( excluyendo los proyectos no relacionados con Uniswap v4 ). De estos proyectos, creemos que 8 (36%) tienen vulnerabilidades. De estos 8 proyectos con vulnerabilidades, 6 tienen problemas de control de acceso y 2 son susceptibles a llamadas externas no confiables.
2.1.1 Problemas de control de acceso
En esta parte de la discusión, nos centramos principalmente en los problemas que pueden surgir con las funciones de callback en v4, incluyendo 8 callbacks de hook y el callback de lock. Por supuesto, también hay otras situaciones que necesitan ser verificadas, pero estas varían según el diseño y no están dentro del alcance de nuestra discusión.
Estas funciones solo deben poder ser llamadas por PoolManager, y no por otras direcciones (, incluidas EOA y contratos ). Por ejemplo, en el caso de que las recompensas sean distribuidas por la clave del fondo de liquidez, si la función correspondiente puede ser llamada por cualquier cuenta, entonces las recompensas podrían ser reclamadas incorrectamente.
Por lo tanto, para los hooks, es crucial establecer un mecanismo de control de acceso sólido, especialmente porque pueden ser llamados por partes ajenas al propio pool. Al gestionar estrictamente los permisos de acceso, el pool de liquidez puede reducir significativamente el riesgo de interacciones no autorizadas o maliciosas con el hook.
2.1.2 Problemas de validación de entrada
En Uniswap v4, debido a la existencia de un mecanismo de bloqueo, los usuarios deben obtener un lock a través del contrato antes de realizar cualquier operación en el pool de liquidez. Esto asegura que el contrato que actualmente participa en la interacción sea el contrato locker más reciente.
A pesar de esto, existe un posible escenario de ataque, que es una llamada externa no confiable debido a una validación de entrada inadecuada en algunas implementaciones de Hook vulnerables:
Primero, el hook no verifica el fondo con el que el usuario pretende interactuar. Esto podría ser un fondo malicioso que contiene tokens falsos y ejecuta lógica dañina.
En segundo lugar, algunas funciones hook clave permiten llamadas externas arbitrarias.
Las llamadas externas no confiables son extremadamente peligrosas, ya que pueden dar lugar a varios tipos de ataques, incluyendo el ataque de reentrada que conocemos bien.
Para atacar estos hooks vulnerables, un atacante puede registrar un fondo malicioso para su token falso y luego invocar el hook para realizar operaciones en el fondo. Al interactuar con el fondo, la lógica del token malicioso secuestra el flujo de control para llevar a cabo comportamientos indebidos.
2.1.3 Medidas de prevención contra el modelo de amenaza I
Para evitar problemas de seguridad relacionados con hooks, es crucial validar las interacciones mediante la implementación adecuada del control de acceso necesario a funciones externas/públicas sensibles y la verificación de los parámetros de entrada. Además, la protección contra reentradas puede ayudar a garantizar que los hooks no se ejecuten repetidamente en el flujo lógico estándar. Al implementar medidas de seguridad adecuadas, el fondo de capital puede reducir los riesgos asociados con tales amenazas.
2.2 Problemas de seguridad en el modelo de amenaza II
En este modelo de amenaza, asumimos que los desarrolladores y su hook son maliciosos. Dado que el alcance es amplio, nos enfocamos únicamente en los problemas de seguridad relacionados con la versión v4. Por lo tanto, la clave está en si el hook proporcionado puede manejar los activos criptográficos de transferencia o autorización de los usuarios.
Dado que el método de acceso al hook determina los permisos que se pueden otorgar al hook, lo dividimos en dos categorías:
Hook gestionado ( Managed Hooks ): el hook no es un punto de entrada. Los usuarios deben interactuar con el hook a través de un enrutador ( que puede ser proporcionado por Uniswap ).
Ganchos Independientes(: el gancho es un punto de entrada que permite a los usuarios interactuar directamente con él.
)# 2.2.1 Hook de custodia
En este caso, los activos criptográficos del usuario ### incluyen tokens nativos y otros tokens ( que se transfieren o autorizan al router. Dado que el PoolManager realiza una verificación de saldo, los hooks maliciosos no pueden robar directamente estos activos con facilidad. Sin embargo, todavía existe una superficie de ataque potencial. Por ejemplo, el mecanismo de gestión de tarifas de la versión v4 podría ser manipulado por un atacante a través de hooks.
)# 2.2.2 Hook independiente
Cuando se utiliza Hook como punto de entrada, la situación se complica aún más. En este caso, dado que los usuarios pueden interactuar directamente con el hook, este obtiene más poder. Teóricamente, el hook puede ejecutar cualquier operación deseada a través de esta interacción.
En la versión v4, la validación de la lógica del código es muy crítica. El problema principal es si se puede manipular la lógica del código. Si el hook es actualizable, esto significa que un hook que parece seguro podría volverse malicioso después de la actualización, lo que representa un riesgo significativo. Estos riesgos incluyen:
El proxy escalable ### puede ser atacado directamente (;
Con lógica de autodestrucción. Puede ser atacado en el caso de una llamada conjunta de selfdestruct y create2.
)# 2.2.3 Medidas de prevención para el modelo de amenaza II
Un punto crucial es evaluar si el hook es malicioso. Específicamente, para los hooks gestionados, debemos prestar atención a las prácticas de gestión de costos; mientras que para los hooks independientes, el enfoque principal está en si son actualizables.
![¿Por qué se dice que Hook es una "espada de doble filo" en Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusión
Este artículo primero resume brevemente los mecanismos centrales relacionados con los problemas de seguridad del Hook en Uniswap v4. A continuación, presentamos dos modelos de amenaza y describimos brevemente los riesgos de seguridad relacionados.
En artículos posteriores, realizaremos un análisis profundo de los problemas de seguridad bajo cada modelo de amenaza.