Smart Contract Audit Report for 1 tomme

Ledelsesoversigt

1inch kontaktede Sayfer for at udføre en sikkerhedsrevision af deres smarte kontrakt.

Denne rapport dokumenterer forskningen udført af Sayfer rettet mod de udvalgte ressourcer, der er defineret under forskningsomfanget. Denne rapport viser især gennemgangen af ​​sikkerhedsstilling for 1inch's smarte kontrakt. Vi anvendte en kombination af manuel inspektion og automatiserede scanningsværktøjer

I løbet af undersøgelsesperioden på 15 revisionsdage opdagede vi 3 sårbarheder og 1 informationsnotat i den reviderede kontrakt.
Ingen af ​​disse resultater anses for at være kritiske, kontrakten kan implementeres som den er. Alle resultaterne var adresser og rettet af 1inch's team.

Risikometodologi

Hos Sayfer er vi forpligtet til at levere smart kontraktrevision af højeste kvalitet til vores kunder. Det er derfor, vi har implementeret en omfattende risikovurderingsmodel for at evaluere alvoren af ​​vores resultater og give vores kunder de bedst mulige anbefalinger til afbødning.

Vores risikovurderingsmodel er baseret på to nøglefaktorer: IMPACT og SANDSYNLIGHED. Påvirkning refererer til den potentielle skade, der kan følge af et problem, såsom økonomisk tab, skade på omdømme eller et ikke-operativt system. Sandsynlighed refererer til sandsynligheden for, at et problem vil opstå under hensyntagen til faktorer som kontraktens kompleksitet og antallet af potentielle angribere.

Ved at kombinere disse to faktorer kan vi skabe en omfattende forståelse af den risiko, et bestemt problem udgør, og give vores kunder en klar og handlekraftig vurdering af problemets alvor. Denne tilgang giver os mulighed for at prioritere vores anbefalinger og sikre, at vores kunder får den bedst mulige rådgivning om, hvordan de beskytter deres smarte kontrakter.

Risiko er defineret som følger:

Protokoloversigt

1 tomme, der forbedrer effektiviteten af ​​operationer i Layer 2 blockchain-miljøet. Da operationer med større opkaldsdata har tendens til at være dyrere i lag 2, er det centrale fokus at reducere størrelsen af ​​opkaldsdataene. For at opnå dette anvendes en strategi med opkaldsdatakomprimering, denne strategi involverer primært off-chain operationer og bruger en mekanisme, der omtales som DecompressorExtension, som muliggør gendannelse af de komprimerede opkaldsdata.

Adskillige nøgleteknikker bruges til komprimering af opkaldsdata:

1. Komprimering af på hinanden følgende nulbytes: Denne teknik reducerer den samlede størrelse af opkaldsdataene ved at konsolidere sekventielle nulbytes til et mere kompakt format.
2. Kopiering af fortløbende bytes: I visse tilfælde bruges replikering af sekventielle bytes som en datakomprimeringsstrategi.
3. Ordbogsbaseret erstatning: To forskellige metoder bruges til at erstatte et segment af opkaldsdataene med et indeks hentet fra en foruddefineret ordbog, hvilket fører til mere effektiv datarepræsentation.

Revisionsresultater

Centraliseringsrisiko

Beskrivelse

Hvis _setData funktionen er udsat for kontraktejeren, hvilket synes at være den tilsigtede måde at bruge kontrakten i henhold til README, dette introducerer en centraliseringsrisiko for hvert projekt, der bruger DecompressorExtension.

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

En ejer kunne frontkøre et opkald fra en bruger og ændre den tilsvarende diktattast, før opkaldet udføres, hvilket giver ham mulighed for at ændre opkaldsdataene vilkårligt. Derfor bliver det umuligt for en bruger at verificere de (dekomprimerede) opkaldsdata før et opkald.

Muligheden af ​​diktatposterne betyder også, at andre smarte kontrakter, der kalder dekomprimering, ikke kan lagre de komprimerede opkaldsdata uforanderlige, da fortolkningen kan ændre sig.

Mitigation

En løsning på dette ville være at forbyde ændring af eksisterende ordbogsposter, men der er behov for en bedre forståelse af virksomhedens behov og muligheder.

Ingen egenimplementering

Beskrivelse

README angiver flere gange om implementering Ejelig form OpenZeppelin. I virkeligheden implementerer eller forlænger kontrakten ikke Owneable, hvilket kan være forvirrende og vildledende for projektejere.

Fra README:

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

Dette er farligt, da projektejere kan antage, at der er en adgangskontrolmekanisme på plads, som ikke eksisterer.

Mitigation

Implementer ejerskabsfunktionalitet ved at arve fra Ownable eller opdatere README for at angive, at brugeren er den, der skal tage sig af adgangskontrollen

Gas DoS-angreb

Beskrivelse

Det er meget nemt at sende (korte) input til decompress der resulterer i enorme dekomprimerede opkaldsdata, dvs. svarende til en zip bombe.

For eksempel kan mange 00111111 bytes efterfulgt af nogle andre data indsendes vha case 0, hvilket resulterer i enorme hukommelsesudvidelsesomkostninger:

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

Hvis brugeren selv indsender denne transaktion, er dette ikke et problem, da han bare spilder sine egne midler, derfor den lave risiko, som denne konstatering giver.

Der er dog nogle scenarier, hvor dette kan muliggøre et angreb. For eksempel kan vi have en relayer-kontrakt, der kalder en smart kontrakt, hvor udviklerne sørgede for, at gasforbruget til hver funktion er begrænset. Hvis denne smarte kontrakt nu begynder at bruge forlængelsen, bliver gasforbruget ubegrænset, da data variabel er et brugerstyret input.

Mitigation

Det vil være svært at undgå denne sårbarhed, der er behov for en bedre forståelse af virksomhedens behov.

En løsning er at indføre en valgfri længdegrænse for de dekomprimerede opkaldsdata, selvom dette kan være svært/umuligt at indstille afhængigt af funktionerne.
Bortset fra denne tekniske løsning, mener vi, at dette i det mindste skal dokumenteres på README eller i en inline kommentar.

Inkompatibilitet med ERC-2771/meta-transaktioner

Beskrivelse

Udvidelsen er inkompatibel med ERC-2771-standarden, hvor relayeren tilføjer den oprindelige afsender til opkaldsdataene (da dette ville føre til komprimeringsfejl).

Dette burde ikke være et kæmpe problem, da kontrakterne stadig understøtter normale (ukomprimerede) opkald, men det betyder, at komprimering ikke kan bruges i forbindelse med metatransaktioner.

Vores antagelse er, at denne kontrakt på et tidspunkt vil være en grundlæggende byggeklods for andre protokoller, som disse protokoller kan bruge ERC-2771, som så ikke længere ville fungere ved brug af komprimerede opkaldsdata.

Mitigation

Hvis dette er relevant, implementer ERC-2771