Smart kontraktrevisionsrapport for Dimo

Ledelsesoversigt

Dimo 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 Dimos smarte kontrakt.

I løbet af forskningsperioden på 40 forskningstimer opdagede vi 14 sårbarheder i kontrakten. Ingen af ​​dem er kritiske.

Som konklusion bør flere rettelser implementeres efter rapporten, men systemets sikkerhedsposition er kompetent.

Efter en gennemgang fra Sayfer-teamet bekræfter vi, at alle sikkerhedsproblemerne nævnt i denne rapport er blevet løst af Dimo-teamet.

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

Protokol introduktion

DIMO er en web3 IoT-virksomhed, der giver brugere og udviklere mulighed for at udnytte den rige strøm af data, der genereres af moderne køretøjer. Dens løsning er et brugerejet økosystem, der giver chauffører mulighed for at høste økonomiske fordele af deres data og muliggøre applikationer som parametrisk forsikring, peer-to-peer bildeling og køretøjsmarkedspladser. Den decentraliserede platform giver også udviklere ro i sindet, idet de ved, at deres adgang til dataene ikke er underlagt en centraliseret gatekeepers luner. Denne løsning er bygget på Polygon.

Revisionsresultater

[H] Ændring af Genesis Time kan potentielt forstyrre belønningsfordelingen

Beskrivelse

Ændring rewardsGenesisTime senere i cyklussen vil senere påvirke de afgørende variabler for nuværende uge og ugegrænse og kan potentielt ødelægge hele belønningsfordelingsordningen og dens forventede tidsplan.

Mitigation

En mulig afbødning er at revidere disse funktioner, således at nulstilling af genesetiden kun er mulig, før belønningsfordelingen er startet:

 function resetRewardsGenesisTime() external onlyRole(ADMIN_ROLE) {
        require(dimoTotalSentOutByContract==0,"Reward Distribution already started");
        rewardsGenesisTime = block.timestamp;
  }

Hvis det er nødvendigt at nulstille eller ændre variablen efter kendsgerningen, kan det måske håndteres på en kontrolleret og forudsigelig måde i kæden i stedet for at tillade administratorer vilkårlig kontrol.

[H] Umarkeret administratortilbagetrækning

Beskrivelse

funktionen adminWithdraw(address, uint256) tillader administratorer at sende kontraktmidler til brugere uden begrænsning. Ifølge dokumentationen bruges dette, hvis brugere sender DIMO til kontrakten uden at satse. Vi mener dog, at denne funktion kan være udsat for misbrug, som forklaret i afsnittet om forretningspåvirkning.

Mitigation

En tænkelig måde at øge sikkerheden på er at indsende en anmodning på vegne af en bruger, måske ved at bruge en konto med orakelrollen. En administrator skal derefter godkende transaktionen. Dette kræver mindst to konti for at godkende sådanne transaktioner, hvilket giver endnu et lag af sikkerhed.

[H] Administratorer kan nulstille registreringsdatabasen efter behag

Beskrivelse

setRegistryContractAddress(address) giver administratorer mulighed for at nulstille registreringsdatabasen adresse efter behag.

Mitigation

En løsning er at sikre, at denne funktion vender tilbage, medmindre registreringsdatabasen ikke er indstillet i første omgang.

  function setRegistryContractAddress(
    address registryContractAddress
  ) external onlyRole(ADMIN_ROLE) {
    require(
        registryContractAddress != address(0),
        "registryContractAddress is an invalid zero address"
    );
    require(address(registry)==address(0)),"already set, cannot be set again")
    registry = IRegistry(registryContractAddress);
  }

En anden løsning er at opsætte en datamigreringsprocedure. Hvis en sådan procedure allerede er på plads, kan denne konstatering med sikkerhed ignoreres.

[I] Deployer har både administrator- og Oracle-roller

Beskrivelse

Under initialiseringen modtager deployeren både admin, standard admin og oracle roller:

_setupRole(DEFAULT_ADMIN_ROLE, msg.sender);

_setupRole(ORACLE_ROLE, msg.sender);
_setupRole(ADMIN_ROLE, msg.sender);

Mitigation

Overvej kun at give standardadministratorrollen, nedarvet fra OA'er AccessControlUpgradeable, til deployeren, så den kan administrere roller for andre brugere.

[M] Brug AccessControlDefaultAdminRulesUpgradeable

Beskrivelse

Reward.sol bruger i øjeblikket AccessControlUpgradable til at give og administrere adgang til kritiske funktioner. I OZ's adgangskontrolskema er den konto, der har DEFAULT_ADMIN_ROLE, i stand til at tildele og trække alle andre roller tilbage. I den nuværende tilstand af kontrakten gives den til installatøren ved initialisering.

AccessControlDefaultAdminRulesUpgradeable udvider AccessControlUpgradable med to afgørende sikkerhedsfunktioner:

• Kun én konto kan holde DEFAULT_ADMIN_ROLE.
• DEFAULT_ADMIN_ROLE kan kun overføres ved hjælp af en to-trins proces. En konfigurerbar forsinkelse mellem de to trin, changeDefaultAdminDelay, håndhæves.

Mitigation

Skift fra AccessControlUpgradable til AccessControlDefaultAdminRulesUpgradeable.

[L] Utilstrækkelig inputvalidering i manuallySetRewardsGenesisTime(uint256)

Beskrivelse

Udover at udgøre en centraliseringsrisiko, som beskrevet ovenfor, manuallySetRewardsGenesisTime(uint256) heller ikke validere tidsstemplet givet af administratoren. Det ville med glæde acceptere en fremtidig tid, der fører til _getNumberOfWeeksSinceGenesis() at vende tilbage:

  function _getNumberOfWeeksSinceGenesis()
    private
    view
    returns (uint256 unixTimeDiff)
  {
    unixTimeDiff = (block.timestamp - rewardsGenesisTime) / 7 days;
  }

Mitigation

Sørg for, at input er lig med eller mindre end det aktuelle tidsstempel.

[L] Utilstrækkelig inputvalidering i setMinimumTimeForRewards(uint256)

Beskrivelse

Dette fund minder i substans meget om det direkte over det. For høj værdi vil gøre brugerne ude af stand til at gøre krav på deres belønninger. Dette i takt med, at belønninger formindskes på ugentlig basis med _limitForWeek(uint256), vil neutralisere fordelen ved tidlig adoption.

Mitigation

Definer et acceptabelt interval af værdier for minimumTimeForRewards og håndhæve det gennem funktionen. På grund af den direkte indflydelse, denne værdi har på platformens hele belønningsstruktur, er det altafgørende at administrere den omhyggeligt.

[L] Ubrugt fejl

Beskrivelse

Fejlen InvalidArrayLegnth() er deklareret på linje 12, men aldrig brugt.

Mitigation

Vi antager, at denne fejl skulle være smidt ind batchTransfer(TransferInfo[]) hvis det leverede array ikke har otte medlemmer:

if(transferInfos.length != 8) revert InvalidArrayLength();

[L] Ikke markeret returværdi

Beskrivelse

På den angivne linje foretages en dimoToken-overførsel, men returværdien forbliver umarkeret.

Mitigation

Gå tilbage med en fejl, hvis overførslen mislykkes:

if (!dimoToken.transfer(user, amount)) revert TokenTransferFailed();

[L] Forældet API-kald

Beskrivelse

funktionen _setupRole(bytes32, address), brugt på den angivne placering, er blevet forældet i OpenZepplin 5.0. Ringer grantRole(bytes32, address) i stedet anbefales nu.

Mitigation

Erstat opkald til _setupRole(bytes32, address) med grantRole(bytes32, address).

[I] Utilstrækkelig hændelsesemission

Beskrivelse

De førnævnte funktioner udsender ikke hændelser for vigtige tilstandsopdateringer.

Mitigation

Tilføj begivenhedsemissioner.

[I] Soliditetsversionering

Beskrivelse

Kontrakten specificerer sin pragma som pragma solidity ^0.8.13;. Dette tillader brug af enhver version af solidity fra 0.8.13. Desuden er 0.8.13 ikke den seneste version.

Mitigation

Beslut dig for en enkelt version af solidity at bruge. Den seneste stabile (og derfor anbefalede) udgivelse er 0.8.19.

[I] Indekser ugeparameteren i TokensTransferredForConnectionStreak()

Beskrivelse

Ugeparameteren repræsenterer den aktuelle uge, hvor luftdråben blev distribueret. Da indeksering gør det nemmere for frontend-applikationer at filtrere specifikke hændelser, vil indeksering af denne parameter gøre det nemt at filtrere efter brugere, der har modtaget airdrops i en given uge.

Mitigation

Overvej at indeksere den angivne parameter.

[I] Overholdelse af Solidity Style Guide

Beskrivelse

TransferInfo[], en struktur, er defineret på linje 36, direkte efter tilstandsvariablerne. Solidity-stilguiden anbefaler at placere struct-deklarationer før.

Mitigation

Flyt erklæringen af ​​strukturen direkte til begyndelsen af ​​kontrakten før tilstandsvariabler.