¿Por qué se dice que Hook es una "espada de doble filo" en Uniswap V4?

Uniswap v4 espera presentarse a todos en un futuro cercano. Esta vez, el equipo de Uniswap ha establecido grandes metas, planeando introducir múltiples nuevas funciones, incluidas el soporte de un número infinito de pools de liquidez por cada par de comercio, tarifas dinámicas, diseño de instancia única, contabilidad relámpago, Hook, y soporte para el estándar de token ERC1155. Utilizando almacenamiento transitorio, se espera que Uniswap v4 se lance después de la actualización de Ethereum Cancún.

Entre tantas innovaciones, el mecanismo Hook ha recibido una amplia atención debido a su gran potencial. Soporta la ejecución de código específico en puntos específicos del ciclo de vida de la piscina de liquidez, lo que mejora enormemente la escalabilidad y flexibilidad de la piscina.

Sin embargo, el mecanismo Hook también puede ser una espada de doble filo. A pesar de ser poderoso y flexible, el uso seguro de Hook también representa un desafío considerable. La complejidad de Hook inevitablemente trae consigo nuevos vectores de ataque potenciales. Por lo tanto, esperamos presentar una serie de artículos que aborden sistemáticamente los problemas de seguridad y los riesgos potenciales asociados con el mecanismo Hook, para fomentar el desarrollo seguro de la comunidad. Creemos que estas ideas ayudarán a construir un Hook seguro para Uniswap v4.

Como la primera entrega de esta serie de artículos, este texto presenta los conceptos relacionados con el mecanismo Hook en Uniswap v4 y describe los riesgos de seguridad asociados con la existencia del mecanismo Hook.

Mecanismo de Uniswap V4

Antes de profundizar en la discusión, necesitamos tener una comprensión básica de los mecanismos de Uniswap v4. Hook, arquitectura de instancia única y contabilidad relámpago son tres funciones importantes para implementar grupos de liquidez personalizados y lograr un enrutamiento eficiente a través de múltiples grupos.

1.1 Gancho

Hook se refiere a un contrato que opera 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. De esta manera, se puede lograr un soporte nativo para tarifas dinámicas, agregar órdenes limitadas en cadena, o dispersar grandes pedidos a través de un creador de mercado de promedio ponderado por tiempo (TWAMM).

Actualmente hay ocho callbacks de Hook, divididos en cuatro grupos (cada grupo contiene un par de callbacks):

• beforeInitialize/afterInitialize

• antesModificarPosición/despuésModificarPosición

• antesDeIntercambiar/despuésDeIntercambiar

• antesDeDonar/despuésDeDonar

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 garantizar la eficiencia. Introduce un nuevo contrato singleton, que almacena todos los pools de liquidez en el mismo contrato inteligente. Este diseño singleton depende de un PoolManager para almacenar y gestionar el estado de todos los pools.

En las primeras versiones del protocolo Uniswap, operaciones como intercambiar o agregar liquidez implicaban transferencias directas de tokens, mientras que la versión v4 es diferente, ya que introduce la contabilidad relámpago y el mecanismo de bloqueo.

El funcionamiento del mecanismo de bloqueo es el siguiente:

1. Un contrato de locker solicita un lock en PoolManager.

2. PoolManager agrega la dirección del contrato locker a la cola lockData y llama a su callback lockAcquired.

3. El contrato del locker ejecuta su lógica en la llamada de retorno. Durante el proceso de ejecución, la interacción del contrato del locker con el fondo puede resultar en un incremento monetario distinto de cero. Sin embargo, al finalizar la ejecución, todos los incrementos deben ser liquidaciones a cero. Además, si la cola de lockData no está vacía, solo el último contrato del locker puede realizar operaciones.

4. PoolManager verifica el estado de la cola lockData y el incremento de moneda. Tras la verificación, PoolManager eliminará el contrato del locker.

En resumen, el mecanismo de bloqueo previene el acceso concurrente y garantiza que todas las transacciones puedan ser liquidadas. El contrato locker solicita un bloqueo 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 del pool, se activan las devoluciones de llamada Hook correspondientes. Finalmente, el PoolManager verificará el estado.

Este método significa que la operación ajusta el saldo neto interno, en lugar de realizar una transferencia instantánea. Cualquier modificación se registrará en el saldo interno del fondo, y la transferencia real se llevará a cabo al final de la operación. Este proceso garantiza que no haya tokens no liquidados, 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 PoolManager. En cambio, cualquier interacción debe realizarse a través de un contrato. Este contrato actúa como un intermediario de bloqueo, y se debe solicitar un bloqueo antes de realizar cualquier operación en el pool.

Principalmente existen dos escenarios de interacción de contratos:

• Un contrato de locker proviene de la biblioteca de código oficial o es desplegado por un usuario. En este caso, podemos considerar la interacción como realizada a través de un enrutador.

• Un contrato de locker se integra en el mismo contrato que Hook, o es controlado por una entidad externa. En este caso, podemos considerar la interacción como realizada a través de Hook. En esta situación, Hook desempeña tanto el papel del contrato de locker como el de manejar la devolución de llamada.

modelo de amenaza

Antes de discutir los problemas de seguridad relacionados, necesitamos definir el modelo de amenaza. Consideramos principalmente las siguientes dos situaciones:

• Modelo de amenaza I: Hook en sí es benigno, pero tiene vulnerabilidades.

• Modelo de amenaza II: El Hook en sí mismo es malicioso.

En la siguiente sección, discutiremos los problemas de seguridad potenciales según estos dos modelos de amenazas.

2.1 Problemas de seguridad en el modelo de amenazas I

El modelo de amenaza I se centra en las vulnerabilidades relacionadas con el Hook en sí. Este modelo de amenaza asume que los desarrolladores y su Hook son benevolentes. 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 con vulnerabilidades similares a las de UUPSUpgradeable de OpenZeppelin.

Dado los factores anteriores, elegimos centrarnos en las vulnerabilidades potenciales específicas de la versión v4. En Uniswap v4, un Hook es un contrato inteligente que puede ejecutar lógica personalizada antes o después de las operaciones del núcleo del grupo (incluyendo inicialización, modificación de posiciones, intercambios y recolección). 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 que involucra la interfaz estándar del Hook. A continuación, intentaremos identificar posibles fuentes de vulnerabilidades, como por ejemplo, cómo un Hook podría abusar de estas funciones estándar del Hook.

En concreto, nos centraremos en los siguientes dos Hook:

• Primer tipo de hook, custodia de fondos de usuarios. En este caso, un atacante podría atacar este hook para transferir fondos, causando pérdidas de activos.

• Segundo tipo de hook, almacena datos de estado clave que dependen del usuario u otros protocolos. En este caso, un atacante podría intentar cambiar el estado clave. 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 de nuestro alcance de discusión.

En general, encontramos 22 proyectos relevantes (excluyendo aquellos que no están relacionados con Uniswap v4). De estos proyectos, consideramos que 8 (36%) tienen vulnerabilidades. De estos 8 proyectos con vulnerabilidades, 6 presentan 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 retorno en v4, incluidos los 8 callbacks hook y el callback de lock. Por supuesto, 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 ser llamadas por el PoolManager y no por otras direcciones (incluyendo EOA y contratos). Por ejemplo, en el caso de que las recompensas se distribuyan mediante la clave del fondo, si la función correspondiente puede ser llamada por cualquier cuenta, es posible que las recompensas sean reclamadas incorrectamente.

Por lo tanto, para el hook, es crucial establecer un mecanismo de control de acceso sólido, especialmente porque puede ser llamado por partes distintas del 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 fondo. Esto asegura que el contrato que participa actualmente en la interacción sea el contrato de bloqueo más reciente.

Sin embargo, sigue existiendo un posible escenario de ataque, que se debe a llamadas externas no confiables provocadas por la falta de validación de entrada en algunas implementaciones de Hook vulnerables:

• En primer lugar, el hook no ha verificado el fondo con el que el usuario tiene la intención de interactuar. Este 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 tan bien.

Para atacar estos hooks vulnerables, un atacante puede registrar un pool de liquidez malicioso para su token falso y luego llamar al hook para ejecutar operaciones en el pool. Al interactuar con el pool, la lógica del token malicioso secuestra el flujo de control para llevar a cabo acciones malintencionadas.

2.1.3 Medidas de prevención contra el modelo de amenazas I

Para evitar problemas de seguridad relacionados con hooks, es crucial validar las interacciones mediante la implementación de controles de acceso necesarios a funciones externas/públicas sensibles y la verificación de los parámetros de entrada. Además, la protección contra reinicios puede ayudar a asegurar que los hooks no se ejecuten repetidamente en el flujo lógico estándar. Al implementar medidas de seguridad adecuadas, el fondo puede reducir los riesgos asociados con tales amenazas.

2.2 Problemas de seguridad en el modelo de amenazas II

En este modelo de amenaza, asumimos que el desarrollador 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 la transferencia o autorización de activos criptográficos por parte del usuario.

Dado que el método de acceso al hook determina los permisos que se pueden otorgar al hook, lo clasificamos en dos categorías:

• Hook de custodia: 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).

• Hook independiente: el hook es el 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 (incluidos los tokens nativos y otros tokens) se transfieren o autorizan al router. Dado que PoolManager realiza una verificación de saldo, no es fácil para un hook malicioso robar directamente estos activos. Sin embargo, aún existe una posible superficie de ataque. 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 un hook.

2.2.2 Hook independiente

Cuando el Hook se utiliza como punto de entrada, la situación se vuelve más compleja. En este caso, dado que los usuarios pueden interactuar directamente con el hook, este obtiene más poder. Teóricamente, el hook puede realizar 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 radica en si se puede manipular la lógica del código. Si el hook es actualizable, esto significa que un hook que parece seguro puede volverse malicioso después de una actualización, lo que representa un riesgo significativo. Estos riesgos incluyen:

• Agente escalable (puede ser atacado directamente);

• Lógica de autodestrucción. Puede ser atacado en el caso de llamar conjuntamente a selfdestruct y create2.

2.2.3 Medidas de prevención contra el modelo de amenaza II

Un punto crucial es evaluar si el hook es malicioso. En concreto, para los hooks administrados, debemos prestar atención al comportamiento de gestión de tarifas; mientras que para los hooks independientes, el enfoque principal está en si son actualizables.

Conclusión

En este artículo, primero resumimos los mecanismos centrales relacionados con los problemas de seguridad de Hook en Uniswap v4. Luego, presentamos dos modelos de amenaza y resumimos los riesgos de seguridad asociados.

En los próximos artículos, abordaremos cada modelo de amenaza