Evaluación de seguridad del HTLC de Garden en Move: Zellic
Técnico
TL;DR, Zellic revisó el contrato HTLC basado en Move de Garden en Sui, centrándose en la corrección de las transiciones de estado, la integridad de las transferencias, la unicidad de las órdenes y la autenticidad de los reembolsos anticipados. Se identificaron dos hallazgos, uno Medium y uno Informational, y ambos se resolvieron en el código.
Introducción
Garden contrató a Zellic para realizar una evaluación de seguridad de la implementación de HTLC basada en Move desplegada en Sui. La revisión fue realizada por Sunwoo Hwang y Varun Verma en mayo de 2025, y el informe se entregó en junio de 2025.
La evaluación cubrió sources/main.move en el repositorio htlc-sui; el único módulo que implementa la lógica de swap atómico de Garden en Sui usando el lenguaje Move. La revisión de Zellic examinó el contrato tanto de forma manual como con herramientas automatizadas, cubriendo errores de codificación, errores de lógica de negocio, riesgos de integración y madurez del código.
La conclusión general de Zellic fue que la lógica central de swap es sólida: los balances se mueven únicamente bajo las transiciones de estado correctas, y los flujos de monedas están fijados en el código a las direcciones initiator o redeemer, sin rutas alternativas de destinatario.
Alcance
La evaluación cubrió:
- sources/main.move: el módulo Move que implementa swaps atómicos basados en HTLC en Sui, incluyendo la iniciación de órdenes, el canje, el reembolso estándar y el reembolso instantáneo con verificación de firma Ed25519
Los objetivos de la evaluación de Zellic se plantearon como cuatro preguntas de seguridad concretas: si los fondos se mueven únicamente bajo transiciones de estado correctas; si se aplica la integridad de las transferencias con todos los flujos de monedas fijados en el código a las direcciones initiator o redeemer; si se aplica la unicidad de las órdenes para evitar órdenes duplicadas o reproducidas; y si los reembolsos anticipados requieren una firma Ed25519 válida del redeemer legítimo.
Hallazgos
Zellic identificó dos hallazgos. Uno de severidad Medium, uno Informational. No se identificaron problemas de severidad Critical, High o Low.
Hallazgo 3.1; Denegación de servicio por órdenes duplicadas mediante front running del order_id determinista | Medium
El order_id se calcula como sha256(secret_hash || initiator || redeemer || timelock). Las cuatro entradas son visibles en la calldata de una transacción pendiente para cualquier oyente del mempool. Además, la función initiate_on_behalf permite que cualquier dirección suministre esos mismos cuatro valores sin demostrar la propiedad de la dirección initiator.
Un atacante puede copiar los cuatro campos de la transacción de swap pendiente de una víctima y enviar initiate_on_behalf con un conjunto de campos idéntico y amount = 1. Si su transacción se confirma primero, el registro almacena una orden dust bajo ese order_id, provocando que la transacción posterior de la víctima aborte con EDuplicateOrder.
La superficie de ataque práctica se da durante periodos de alta volatilidad: un atacante que monitorea el mempool en busca de HTLCs que ejecutan arbitraje puede bloquear el swap de un competidor a un coste insignificante, un depósito dust de 1 unidad, y capturar él mismo la oportunidad de arbitraje. La probabilidad y el impacto se califican ambos como Medium.
Hallazgo 3.2; Un timelock sin límite permite un bloqueo permanente accidental | Informational
El contrato aplica correctamente la expiración como initiated_at + timelock < now, pero el propio timelock no tiene un valor máximo. Un usuario podría pasar accidentalmente un número extremadamente grande como u256::MAX. Esto es un riesgo de experiencia de usuario y de seguridad más que una vulnerabilidad explotable; no hay ángulo adversario, ya que el usuario estaría bloqueando sus propios fondos.
Acción
Ambos hallazgos fueron reconocidos por Garden y resueltos en el código.
- El hallazgo 3.1 se corrigió en el commit e85e06c9 introduciendo el valor amount en la generación de la preimagen del order_id para impedir la iniciación con importes dust, lo que hace inviable el front running.
- El hallazgo 3.2 se corrigió en el commit 4b9c871f aplicando un límite máximo al timelock en safe_params, acotándolo a un tope razonable para evitar bloqueos permanentes accidentales.
Resumen
Dos hallazgos: uno Medium, uno Informational, ambos resueltos en el código. Ningún problema de severidad Critical, High o Low. La evaluación final de Zellic confirmó que la lógica central de swap está limpia y que las propiedades de seguridad fundamentales del contrato, transiciones de estado correctas, integridad de las transferencias, unicidad de las órdenes y reembolsos anticipados autenticados, se verificaron como sólidas.
Garden trata la seguridad como una iniciativa continua y ejecuta bug bounties abiertos y competitivos, como la reciente auditoría de Code4rena, que ofreció $37,500 en recompensas a lo largo de 813 propuestas, dirigida a la arquitectura HTLC en EVM, Solana, Sui y Starknet. La información sobre todas las auditorías se puede encontrar en https://garden.finance/es/security.
Last updated