Rapport d'audit de contrat intelligent pour 1 pouce

Résumé de gestion

1inch a contacté Sayfer pour réaliser un audit de sécurité sur son contrat intelligent.

Ce rapport documente les recherches effectuées par Sayfer ciblant les ressources sélectionnées définies dans le cadre de la recherche. En particulier, ce rapport affiche l'examen de la posture de sécurité du contrat intelligent de 1inch. Nous avons appliqué une combinaison d'outils d'inspection manuelle et d'analyse automatisée

Au cours de la période de recherche de 15 jours d'audit, nous avons découvert 3 vulnérabilités et 1 note d'information dans le contrat audité.
Aucun de ces constats n’est considéré comme critique, le contrat peut être déployé tel quel. Toutes les découvertes ont été adressées et corrigées par l'équipe de 1inch.

Méthodologie des risques

Chez Sayfer, nous nous engageons à fournir à nos clients des audits de contrats intelligents de la plus haute qualité. C'est pourquoi nous avons mis en œuvre un modèle complet d'évaluation des risques pour évaluer la gravité de nos constatations et fournir à nos clients les meilleures recommandations possibles pour les atténuer.

Notre modèle d’évaluation des risques repose sur deux facteurs clés : IMPACT ainsi que PROBABILITÉ. L'impact fait référence au préjudice potentiel qui pourrait résulter d'un problème, tel qu'une perte financière, une atteinte à la réputation ou un système non opérationnel. La probabilité fait référence à la probabilité qu'un problème se produise, en tenant compte de facteurs tels que la complexité du contrat et le nombre d'attaquants potentiels.

En combinant ces deux facteurs, nous pouvons créer une compréhension globale du risque posé par un problème particulier et fournir à nos clients une évaluation claire et exploitable de la gravité du problème. Cette approche nous permet de prioriser nos recommandations et de garantir que nos clients reçoivent les meilleurs conseils possibles sur la façon de protéger leurs contrats intelligents.

Le risque est défini comme suit :

Présentation du protocole

1 pouce améliorant l’efficacité des opérations dans l’environnement blockchain de couche 2. Étant donné que les opérations avec des données d'appel plus volumineuses ont tendance à être plus coûteuses dans la couche 2, l'objectif central est de réduire la taille des données d'appel. Pour ce faire, une stratégie de compression des données d'appel est utilisée. Cette stratégie implique principalement des opérations hors chaîne et utilise un mécanisme appelé DecompressorExtension, qui permet la récupération des données d'appel compressées.

Plusieurs techniques clés sont utilisées pour la compression des données d'appel :

1. Compression des octets zéro consécutifs : cette technique réduit la taille globale des données d'appel en consolidant les octets zéro séquentiels dans un format plus compact.
2. Copie d'octets consécutifs : dans certains cas, la réplication d'octets séquentiels est utilisée comme stratégie de compression de données.
3. Remplacement basé sur un dictionnaire : deux méthodes distinctes sont utilisées pour remplacer un segment des données d'appel par un index tiré d'un dictionnaire prédéfini, conduisant à une représentation plus efficace des données.

Constatations des audits

Risque de centralisation

Description

Si la _setData La fonction est exposée au propriétaire du contrat, ce qui semble être la manière prévue d'utiliser le contrat selon le README, cela introduit un risque de centralisation pour chaque projet qui utilise DecompressorExtension.

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

Un propriétaire peut lancer un appel d'un utilisateur et modifier la clé de dict correspondante avant l'exécution de l'appel, ce qui lui permet de modifier arbitrairement les données d'appel. Par conséquent, il devient impossible pour un utilisateur de vérifier les données d'appel (décompressées) avant un appel.

La mutabilité des entrées dict signifie également que les autres contrats intelligents qui appellent la décompression ne peuvent pas stocker les données d'appel compressées de manière immuable, car leur interprétation peut changer.

Atténuation

Une solution à ce problème serait d’interdire la modification des entrées de dictionnaire existantes, mais une meilleure compréhension des besoins et des options de l’entreprise est nécessaire.

Aucune implémentation propriétaire

Description

Le README indique à plusieurs reprises la mise en œuvre Forme propriétaire OpenZeppelin. En réalité, le contrat ne met pas en œuvre ni n’étend Owneable, ce qui pourrait prêter à confusion et induire en erreur les propriétaires de projets.

Extrait du README :

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

Ceci est dangereux car les propriétaires du projet pourraient supposer qu'il existe un mécanisme de contrôle d'accès, ce qui n'existe pas.

Atténuation

Implémentez la fonctionnalité de propriété en héritant d'Ownable ou mettez à jour le README pour indiquer que l'utilisateur est celui qui doit s'occuper du contrôle d'accès.

Attaque DoS au gaz

Description

Il est très facile de soumettre une (courte) contribution à decompress cela se traduit par d'énormes données d'appel décompressées, c'est à dire l'équivalent d'un bombe zippée.

Par exemple, de nombreux octets 00111111 suivis de quelques autres données peuvent être soumis en utilisant case 0, ce qui entraîne d'énormes coûts d'extension de mémoire :

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

Si l'utilisateur effectue lui-même cette transaction, cela ne pose pas de problème, car il gaspille simplement ses propres fonds, d'où le faible risque accordé à cette conclusion.

Cependant, il existe certains scénarios dans lesquels cela pourrait permettre une attaque. Par exemple, nous pourrions avoir un contrat de relais qui appelle un contrat intelligent dans lequel les développeurs veillent à ce que la consommation de gaz de chaque fonction soit limitée. Si ce contrat intelligent commence maintenant à utiliser l'extension, la consommation de gaz devient illimitée, car le data La variable est une entrée contrôlée par l'utilisateur.

Atténuation

Il sera difficile d’éviter cette vulnérabilité ; il est nécessaire de mieux comprendre les besoins de l’entreprise.

Une solution consiste à introduire une limite de longueur facultative pour les données d'appel décompressées, bien que cela puisse être difficile/impossible à définir en fonction des fonctions.
Outre cette solution technique, nous pensons que cela devrait au moins être documenté dans le README ou dans un commentaire en ligne.

Incompatibilité avec ERC-2771/méta transactions

Description

L'extension est incompatible avec la norme ERC-2771 où le relais ajoute l'expéditeur d'origine aux données d'appel (car cela entraînerait des erreurs de compression).

Cela ne devrait pas poser de gros problème car les contrats prennent toujours en charge les appels normaux (non compressés), mais cela signifie que la compression ne peut pas être utilisée conjointement avec les méta-transactions.

Notre hypothèse est qu'à un moment donné, ce contrat constituera un élément de base pour d'autres protocoles, que ces protocoles pourraient utiliser ERC-2771, qui ne fonctionnerait alors plus lors de l'utilisation de données d'appel compressées.

Atténuation

Si cela est pertinent, implémentez ERC-2771