Informe de auditoría de contrato inteligente para 1 pulgada

Resumen de gestión

1inch se puso en contacto con Sayfer para realizar una auditoría de seguridad en su contrato inteligente.

Este informe documenta la investigación realizada por Sayfer dirigida a los recursos seleccionados definidos bajo el alcance de la investigación. En particular, este informe muestra la revisión de la postura de seguridad para el contrato inteligente de 1inch. Aplicamos una combinación de inspección manual y herramientas de escaneo automatizadas.

Durante el período de investigación de 15 días de auditoría, descubrimos 3 vulnerabilidades y 1 nota informativa en el contrato auditado.
Ninguno de estos hallazgos se considera crítico; el contrato se puede implementar tal como está. Todos los hallazgos fueron abordados y arreglados por el equipo de 1inch.

Metodología de Riesgo

En Sayfer, estamos comprometidos a ofrecer auditorías de contratos inteligentes de la más alta calidad a nuestros clientes. Es por eso que hemos implementado un modelo integral de evaluación de riesgos para evaluar la gravedad de nuestros hallazgos y brindar a nuestros clientes las mejores recomendaciones posibles para la mitigación.

Nuestro modelo de evaluación de riesgos se basa en dos factores clave: IMPACTO y PROBABILIDAD. El impacto se refiere al daño potencial que podría resultar de un problema, como pérdidas financieras, daños a la reputación o un sistema no operativo. La probabilidad se refiere a la probabilidad de que ocurra un problema, teniendo en cuenta factores como la complejidad del contrato y la cantidad de atacantes potenciales.

Al combinar estos dos factores, podemos crear una comprensión integral del riesgo que plantea un problema en particular y brindar a nuestros clientes una evaluación clara y procesable de la gravedad del problema. Este enfoque nos permite priorizar nuestras recomendaciones y garantizar que nuestros clientes reciban el mejor asesoramiento posible sobre cómo proteger sus contratos inteligentes.

El riesgo se define de la siguiente manera:

Descripción general del protocolo

1inch mejora la eficiencia de las operaciones dentro del entorno blockchain de Capa 2. Dado que las operaciones con datos de llamadas más grandes tienden a ser más costosas en la Capa 2, el enfoque central es reducir el tamaño de los datos de llamadas. Para lograr esto, se emplea una estrategia de compresión de datos de llamadas, esta estrategia implica principalmente operaciones fuera de la cadena y utiliza un mecanismo denominado DecompressorExtension, que permite la recuperación de los datos de llamadas comprimidos.

Se utilizan varias técnicas clave para la compresión de los datos de llamada:

1. Compresión de bytes cero consecutivos: esta técnica reduce el tamaño total de los datos de llamada al consolidar los bytes cero secuenciales en un formato más compacto.
2. Copiar bytes consecutivos: en ciertos casos, la replicación de bytes secuenciales se emplea como estrategia de compresión de datos.
3. Reemplazo basado en diccionario: se utilizan dos métodos distintos para reemplazar un segmento de datos de llamada con un índice extraído de un diccionario predefinido, lo que lleva a una representación de datos más eficiente.

Resultados de la auditoría

Riesgo de centralización

Descripción

Si _setData La función está expuesta al propietario del contrato, que parece ser la forma prevista de utilizar el contrato según el README, esto introduce un riesgo de centralización para cada proyecto que utiliza DecompressorExtension.

function _setData(uint256 offset, bytes32 data) internal
validDictAccess(offset) {
    unchecked {
        _dict[offset] = data;
    }
}

Un propietario podría adelantar una llamada de un usuario y cambiar la clave de dictado correspondiente antes de que se ejecute la llamada, lo que le permite cambiar los datos de la llamada de forma arbitraria. Por lo tanto, resulta imposible para un usuario verificar los datos de llamada (descomprimidos) antes de realizar una llamada.

La mutabilidad de las entradas del dict también significa que otros contratos inteligentes que llaman a descomprimir no pueden almacenar los datos de llamada comprimidos de forma inmutable, ya que su interpretación puede cambiar.

Mitigación

Una solución para esto sería no permitir cambiar las entradas del diccionario existente, pero se necesita una mejor comprensión de las necesidades y opciones del negocio.

Sin implementación propia

Descripción

El README indica varias veces acerca de la implementación Forma propia OpenZeppelin. En realidad, el contrato no implementa ni amplía Owneable, lo que podría resultar confuso y engañoso para los propietarios del proyecto.

Del README:

This contract provides a `DecompressorExtension` abstract
contract that extends `Ownable` from the OpenZeppelin
library.

Esto es peligroso ya que los propietarios del proyecto podrían asumir que existe un mecanismo de control de acceso, que no existe.

Mitigación

Implemente la funcionalidad de propiedad heredando de Ownable o actualice el archivo README para indicar que el usuario es quien debe encargarse del control de acceso.

Ataque DoS de gas

Descripción

Es muy fácil enviar comentarios (breves) a decompress eso da como resultado enormes datos de llamadas descomprimidos, es decir, el equivalente a un bomba zip.

Por ejemplo, muchos bytes 00111111 seguidos de algunos otros datos se pueden enviar usando case 0, lo que genera enormes costos de expansión de memoria:

case 0 {
    let size := add(byte(0, data), 1)
    calldatacopy(outptr, calldatasize(), size)
    inptr := add(inptr, 1)
    outptr := add(outptr, size)
    continue
}

Si el usuario realiza esta transacción él mismo, esto no es un problema, ya que simplemente desperdicia sus propios fondos, de ahí el bajo riesgo que conlleva este hallazgo.

Sin embargo, existen algunos escenarios en los que esto podría permitir un ataque. Por ejemplo, podríamos tener un contrato de retransmisión que se denomina contrato inteligente en el que los desarrolladores se encargaron de que el uso de gas de cada función esté limitado. Si este contrato inteligente ahora comienza a utilizar la extensión, el uso de gas se vuelve ilimitado, ya que el data La variable es una entrada controlada por el usuario.

Mitigación

Evitar esta vulnerabilidad será difícil; es necesario comprender mejor las necesidades empresariales.

Una solución es introducir un límite de longitud opcional para los datos de llamada descomprimidos, aunque esto podría ser difícil o imposible de establecer dependiendo de las funciones.
Aparte de esta solución técnica, creemos que esto debería al menos documentarse en el archivo README o en un comentario en línea.

Incompatibilidad con ERC-2771/metatransacciones

Descripción

La extensión es incompatible con el estándar ERC-2771 donde el repetidor agrega el remitente original a los datos de la llamada (ya que esto provocaría errores de compresión).

Esto no debería ser un gran problema ya que los contratos aún admiten llamadas normales (sin comprimir), pero significa que la compresión no se puede usar junto con metatransacciones.

Nuestra suposición es que en algún momento este contrato será un componente básico para otros protocolos, que pueden usar ERC-2771, que luego ya no funcionará cuando se usen datos de llamada comprimidos.

Mitigación

Si esto es relevante, implemente ERC-2771