Es uzskatu, ka Uniswap v4 drīz būs pieejams ikvienam!

Šoreiz Uniswap komandai ir ambiciozi mērķi un plāni ieviest daudzas jaunas funkcijas [1], tostarp atbalstu neierobežotam skaitam likviditātes pūlu un dinamiskas maksas par vienu tirdzniecības pāri, singleton dizainu, zibens uzskaiti, Hooks un atbalstu ERC1155 marķiera standartam. . Izmantojot EIP-1153 ieviesto īslaicīgo krātuvi, ir paredzēts, ka Uniswap v4 tiks izlaists pēc Ethereum Cancun jaunināšanas.

Starp daudziem jauninājumiem Hook mehānisms ir piesaistījis plašu uzmanību, pateicoties tā spēcīgajam potenciālam. Hook mehānisms atbalsta noteikta koda izpildi noteiktos likviditātes kopas dzīves cikla punktos, ievērojami uzlabojot pūla mērogojamību un elastību.

Tomēr āķa mehānisms var būt arī abpusgriezīgs zobens. Lai gan tas ir spēcīgs un elastīgs, āķa droša lietošana ir arī liels izaicinājums. Āķu sarežģītība neizbēgami rada jaunus iespējamos uzbrukuma vektorus. Tāpēc mēs ceram uzrakstīt rakstu sēriju, lai sistemātiski iepazīstinātu ar drošības problēmām un iespējamiem riskiem, kas saistīti ar Hook mehānismu, lai veicinātu kopienas drošības attīstību. Mēs uzskatām, ka šie ieskati palīdzēs izveidot drošu Uniswap v4 Hook.

Šīs rakstu sērijas sākumā šis raksts iepazīstina ar jēdzieniem, kas saistīti ar āķa mehānismu Uniswap v4, un izklāsta Hook mehānisma drošības riskus.

Uniswap V4 mehānisms

Pirms ienirt, mums ir jāsaņem pamatzināšanas par Uniswap v4 mehāniku. Saskaņā ar oficiālo paziņojumu [1] un balto grāmatu [2] Hooks, singleton arhitektūra un zibens uzskaite ir trīs svarīgas funkcijas, lai ieviestu pielāgotus likviditātes kopumus un panāktu efektīvu maršrutēšanu vairākos pūlos.

1.1 Āķis

Hooks attiecas uz līgumiem, kas darbojas dažādos likviditātes baseina dzīves cikla posmos. Uniswap komanda cer, ka, ieviešot Hooks, ikviens varēs pieņemt kompromisus. Tādā veidā ir iespējams sākotnēji atbalstīt dinamiskas maksas, pievienot ķēdes cenu griestu pasūtījumus vai sadalīt lielus pasūtījumus, izmantojot laika svērto vidējo tirgus veidotāju (TWAMM).

Pašlaik ir astoņi Hook atzvani, kas sadalīti četrās grupās (katrā grupā ir pāris atzvanīšanas):

• beforeInitialize/afterInitialize

• beforeModifyPosition/afterModifyPosition

• beforeSwap/afterSwap

• pirmsZiedot/pēcZiedot

Tālāk ir aprakstīts Baltajā grāmatā [2] aprakstītais āķu apmaiņas process.

1. attēls: Exchange Hook process

Uniswap komanda iepazīstināja ar dažiem piemēriem, kā to izdarīt (piemēram, TWAMM Hook[3]), un arī kopienas dalībnieki sniedza dažus ieguldījumus. Oficiālajā dokumentācijā[4] ir arī saites uz Awesome Uniswap v4 Hooks[5] krātuvi, kurā apkopoti vairāk Hook piemēru.

1.2 Singleton, zibens uzskaite un bloķēšanas mehānisms

Singleton arhitektūra un zibatmiņas uzskaite ir izstrādāta, lai uzlabotu veiktspēju, samazinot izmaksas un nodrošinot efektivitāti. Tas ievieš jaunu vienotu līgumu, kurā visi likviditātes pūli tiek turēti vienā viedajā līgumā. Šis viengabala dizains balstās uz PoolManager, lai saglabātu un pārvaldītu visu baseinu stāvokli.

Iepriekšējās Uniswap protokola versijās tādas darbības kā likviditātes apmaiņa vai pievienošana ietvēra tiešu marķiera pārsūtīšanu. V4 versija atšķiras ar to, ka tajā ir ieviesta zibens uzskaite un bloķēšanas mehānisms.

Bloķēšanas mehānisms darbojas šādi:

1. Skapja līgums pieprasa PoolManager bloķēšanu.

2. PoolManager pievieno skapja līguma adresi lockData rindai un izsauc tā lockAcquired atzvanīšanu.

3. Skapja līgums izpilda savu loģiku atzvanīšanā. Izpildes laikā skapja līguma mijiedarbība ar baseinu var izraisīt valūtas pieaugumu, kas nav nulle. Tomēr izpildes beigās visām deltām ir jānoregulējas uz nulli. Turklāt, ja lockData rinda nav tukša, darbības var veikt tikai pēdējais skapja līgums.

4. PoolManager pārbauda lockData rindas statusu un valūtas pieaugumu. Pēc pārbaudes PoolManager dzēsīs skapja līgumu.

Rezumējot, bloķēšanas mehānisms novērš vienlaicīgu piekļuvi un nodrošina visu darījumu notīrīšanu. Skapja līgums attiecas uz slēdzenēm secīgi, un pēc tam tiek izpildīti darījumi, izmantojot lockAcquired atzvanīšanu. Atbilstošā Hook atzvanīšana tiks aktivizēta pirms un pēc katras pūla darbības. Visbeidzot, PoolManager pārbauda statusu.

Šī pieeja nozīmē, ka operācija pielāgo iekšējo neto bilanci (t.i., delta), nevis veic tūlītēju pārsūtīšanu. Jebkādas izmaiņas tiks ierakstītas baseina iekšējā bilancē, un faktiskā pārskaitīšana tiks veikta operācijas beigās (t.i., bloķēšana). Šis process nodrošina, ka nav neapmaksātu žetonu, tādējādi saglabājot līdzekļu integritāti.

Bloķēšanas mehānisma dēļ ārējie īpašumtiesību konti (EOA) nevar tieši mijiedarboties ar PoolManager. Tā vietā jebkurai mijiedarbībai ir jānotiek, noslēdzot līgumu. Šis līgums darbojas kā starpposma skapītis, un pirms baseina darbību veikšanas ir jāpieprasa bloķēšana.

Ir divi galvenie līguma mijiedarbības scenāriji:

• Noteikts skapja līgums nāk no oficiālās kodu bāzes vai to izvieto lietotāji. Šajā gadījumā mēs varam uzskatīt, ka mijiedarbība notiek caur maršrutētāju.

• Skapja līgums un āķis ir integrēti vienā līgumā vai tos kontrolē trešās puses uzņēmums. Šajā gadījumā mēs varam uzskatīt, ka mijiedarbība notiek caur Hooks. Šajā gadījumā Huks gan pilda skapja līguma lomu, gan ir atbildīgs par atzvanīšanas apstrādi.

Draudu modelis

Pirms apspriest saistītos drošības jautājumus, mums ir jānosaka draudu modelis. Mēs galvenokārt apsveram šādas divas situācijas:

• I draudu modelis: paši āķi ir labdabīgi, taču tiem ir ievainojamība.

• II draudu modelis: āķi pēc savas būtības ir ļaunprātīgi.

Nākamajās sadaļās mēs apspriežam iespējamās drošības problēmas, pamatojoties uz šiem diviem draudu modeļiem.

2.1. Drošības jautājumi I draudu modelī

I draudu modelis koncentrējas uz ievainojamībām, kas saistītas ar pašu Hook. Šis draudu modelis pieņem, ka izstrādātāji un viņu āķi ir nekaitīgi. Tomēr esošās zināmās viedo līgumu ievainojamības var parādīties arī programmā Hooks. Piemēram, ja āķis ir ieviests kā jaunināms līgums, tas var saskarties ar problēmām, kas saistītas ar OpenZeppelin UUPSU jaunināmo ievainojamību.

Ņemot vērā iepriekš minētos faktorus, mēs izvēlējāmies koncentrēties uz iespējamām ievainojamībām, kas raksturīgas tikai v4 versijai. Uniswap v4 āķi ir viedie līgumi, kas spēj izpildīt pielāgotu loģiku pirms vai pēc pamata pūla operācijām, tostarp inicializācijas, pozīcijas modificēšanas, maiņas un apkopošanas. Lai gan ir paredzēts, ka Hooks ieviesīs standarta saskarnes, tie arī ļauj iekļaut pielāgotu loģiku. Tāpēc mūsu diskusija aprobežosies ar loģiku, kas ietver standarta Hook interfeisu. Pēc tam mēs mēģināsim identificēt iespējamos ievainojamību avotus, piemēram, kā Hooks varētu ļaunprātīgi izmantot šīs standarta Hook funkcijas.

Konkrēti, mēs koncentrēsimies uz šādiem diviem āķu veidiem:

• Pirmais āķis ir saglabāt lietotāja līdzekļus. Šādā gadījumā uzbrucējs var uzbrukt šim āķim, lai pārskaitītu līdzekļus, izraisot aktīvu zaudējumu.

• Otrais āķa veids saglabā galveno statusa datus, uz kuriem paļaujas lietotāji vai citi protokoli. Šajā gadījumā uzbrucējs var mēģināt mainīt kritisko stāvokli. Potenciālie riski var rasties, ja citi lietotāji vai protokoli izmanto nepareizu stāvokli.

Lūdzu, ņemiet vērā, ka āķi, kas neietilpst šajās divās jomās, ir ārpus mūsu diskusijas.

Tā kā šī rakstīšanas laikā nav reālu Hooks lietošanas gadījumu, mēs apkoposim informāciju no Awesome Uniswap v4 Hooks krātuves.

Pēc dziļas iedziļināšanās Awesome Uniswap v4 Hooks krātuvē (jāveic 3a0a444922f26605ec27a41929f3ced924af6075) mēs atklājām vairākas kritiskas ievainojamības. Šīs ievainojamības galvenokārt rodas no riskantas mijiedarbības starp āķiem, PoolManager un ārējām trešajām pusēm, un tās galvenokārt var iedalīt divās kategorijās: piekļuves kontroles problēmas un ievades validācijas problēmas. Lūdzu, skatiet tālāk esošo tabulu, lai uzzinātu konkrētus konstatējumus:

Kopumā mēs atradām 22 atbilstošus projektus (izņemot projektus, kas nav saistīti ar Uniswap v4). Mēs uzskatām, ka starp šiem projektiem 8 (36%) projekti ir neaizsargāti. No astoņiem neaizsargātajiem projektiem sešos bija piekļuves kontroles problēmas, un divi bija neaizsargāti pret neuzticamiem ārējiem zvaniem.

2.1.1. Piekļuves kontroles problēmas

Šajā diskusijas daļā mēs galvenokārt koncentrējamies uz problēmām, ko var izraisīt 4. versijas atzvanīšanas funkcijas, tostarp 8 hook atzvani un bloķēšanas atzvani. Protams, ir arī citas situācijas, kas ir jāpārbauda, ​​taču šīs situācijas atšķiras atkarībā no konstrukcijas un ir ārpus mūsu diskusijas jomas.

Šīs funkcijas drīkst izsaukt tikai PoolManager, un tās nevar izsaukt no citām adresēm (tostarp EOA un līgumiem). Piemēram, ja atlīdzības tiek sadalītas pēc kopas atslēgām, atlīdzības var tikt pieprasītas nepareizi, ja atbilstošo funkciju var izsaukt no jebkura konta.

Tāpēc ir ļoti svarīgi izveidot spēcīgus piekļuves kontroles mehānismus āķiem, jo ​​īpaši tāpēc, ka tos var izsaukt arī citas puses, izņemot pašu pūlu. Stingri pārvaldot piekļuves tiesības, likviditātes pūli var ievērojami samazināt nesankcionētas vai ļaunprātīgas mijiedarbības ar āķiem risku.

2.1.2. Ievades pārbaudes problēmas

Programmā Uniswap v4 bloķēšanas mehānisma dēļ lietotājiem ir jāiegūst bloķēšana, izmantojot līgumu, pirms tiek veiktas jebkādas fondu kopas darbības. Tas nodrošina, ka līgums, kas pašlaik piedalās mijiedarbībā, ir jaunākais skapja līgums.

Tomēr ir iespējams uzbrukuma scenārijs, proti, neuzticami ārējie izsaukumi nepareizas ievades validācijas dēļ dažās ievainojamās Hook implementācijās:

• Pirmkārt, āķis nepārbauda līdzekļu kopumu, ar kuru lietotājs plāno mijiedarboties. Tas varētu būt ļaunprātīgs kopums, kurā ir viltoti marķieri un tiek izpildīta kaitīga loģika.

• Otrkārt, dažas galvenās āķa funkcijas ļauj veikt patvaļīgus ārējos zvanus.

Neuzticami ārējie zvani ir ārkārtīgi bīstami, jo tie var izraisīt dažāda veida uzbrukumus, tostarp tos, ko mēs zinām kā atkārtotas ienākšanas uzbrukumus.

Lai uzbruktu šiem neaizsargātajiem āķiem, uzbrucējs var reģistrēt ļaunprātīgu fondu kopu saviem viltotajiem marķieriem un pēc tam izsaukt āķi, lai veiktu darbības fondu pūlā. Mijiedarbojoties ar kopu, ļaunprātīgā marķiera loģika nolaupa vadības plūsmu, lai iesaistītos nevēlamā darbībā.

2.1.3. Preventīvie pasākumi pret draudu modeli I

Lai apietu šādas ar āķiem saistītas drošības problēmas, ir ļoti svarīgi autentificēt mijiedarbību, pareizi ieviešot nepieciešamās piekļuves kontroles jutīgām ārējām/publiskām funkcijām un apstiprinot ievades parametrus. Turklāt atkārtotas ieejas aizsardzība var palīdzēt nodrošināt, ka āķis netiek atkārtoti izpildīts standarta loģikas plūsmā. Ieviešot atbilstošus drošības pasākumus, pūli var samazināt ar šādiem draudiem saistītos riskus.

2.2. drošības problēmas II draudu modelī

Šajā draudu modelī mēs pieņemam, ka izstrādātājs un viņa āķis ir ļaunprātīgi. Plašās darbības jomas dēļ mēs koncentrējamies tikai uz drošības jautājumiem, kas saistīti ar v4 versiju. Tāpēc galvenais ir tas, vai nodrošinātais āķis var apstrādāt lietotāja pārsūtītos vai autorizētos kriptovalūtus.

Tā kā āķa piekļuves metode nosaka atļaujas, kas var tikt piešķirtas āķim, mēs sadalām āķi divās kategorijās:

• Pārvaldītie āķi: āķi nav ieejas punkti. Lietotājiem ir jāsazinās ar āķi, izmantojot maršrutētāju (iespējams, to nodrošina Uniswap).

• Savrupie āķi: āķi ir ieejas punkti, kas ļauj lietotājiem ar tiem sazināties tieši.

2. attēls. Ļaunprātīga āķa piemērs

2.2.1. Pārvaldīts āķis

Šajā gadījumā lietotāja kriptogrāfijas līdzekļi (tostarp vietējie marķieri un citi marķieri) tiek pārsūtīti vai autorizēti maršrutētājam. Tā kā PoolManager veic bilances pārbaudes, ļaunprātīgiem āķiem nav viegli tieši nozagt šos līdzekļus. Tomēr joprojām pastāv potenciāla uzbrukuma virsma. Piemēram, uzbrucēji var manipulēt ar v4 versijas izdevumu pārvaldības mehānismu, izmantojot āķus.

2.2.2. Neatkarīgs āķis

Situācija ir vēl sarežģītāka, ja āķi tiek izmantoti kā ieejas punkti. Šajā gadījumā āķis iegūst lielāku jaudu, jo lietotājs var ar to mijiedarboties tieši. Teorētiski āķis ar šo mijiedarbību var darīt visu, ko vēlas.

V4 versijā koda loģikas pārbaude ir ļoti svarīga. Galvenā problēma ir tā, vai ar koda loģiku var manipulēt. Ja āķis ir jaunināms, tas nozīmē, ka šķietami drošs āķis pēc jaunināšanas var kļūt par ļaunprātīgu, radot ievērojamu risku. Šie riski ietver:

• Uzlabojami aģenti (var tieši uzbrukt);

• Ar pašiznīcināšanās loģiku. Tas var tikt uzbrukts, ja pašiznīcināšanās un create2 tiek izsaukti kopā.

2.2.3. Preventīvie pasākumi pret draudu modeli II

Ir ļoti svarīgi novērtēt, vai āķis ir ļaunprātīgs. Konkrēti, attiecībā uz pārvaldītajiem āķiem mums ir jākoncentrējas uz maksu pārvaldības darbību, savukārt atsevišķiem āķiem galvenā uzmanība ir jāpievērš tam, vai tie ir jaunināmi.

noslēgumā

Šajā rakstā mēs vispirms sniedzam īsu pārskatu par galvenajiem mehānismiem, kas saistīti ar Uniswap v4 Hook drošības problēmām. Pēc tam mēs piedāvājam divus draudu modeļus un īsi raksturojam saistītos drošības riskus.

Nākamajos rakstos mēs veiksim padziļinātu drošības problēmu analīzi saskaņā ar katru draudu modeli.