Slijede razlike između dviju inačica stranice.
| Starije izmjene na obje strane Starija izmjena Novija izmjena | Starija izmjena | ||
|
racfor_wiki:razno:sigurnosne_prijetnje_solidity [2020/01/10 02:52] kcavar [Uvod] |
racfor_wiki:razno:sigurnosne_prijetnje_solidity [2024/12/05 12:24] (trenutno) |
||
|---|---|---|---|
| Redak 22: | Redak 22: | ||
| Najpopularnije primjene pametnih ugovora programiranih u Solidity-ju su implementacije glasovanja, grupnog financiranja (crowdfunding), | Najpopularnije primjene pametnih ugovora programiranih u Solidity-ju su implementacije glasovanja, grupnog financiranja (crowdfunding), | ||
| - | Iako je široko raširen, Solidity je još uvijek u ranoj razvojnoj fazi (trenutna najnovija verzija je 0.6.1), a to ukazuje na puno prostora za sigurnosne prijetnje. Ovaj će seminar razmotriti nekoliko zanimljiviih otkrivenih sigurnosnih propusta te službena ili potencijalna rješenja za sprječavanje istih. | + | Iako je široko raširen, Solidity je još uvijek u ranoj razvojnoj fazi (trenutna najnovija verzija je 0.6.1), a to ukazuje na puno prostora za sigurnosne prijetnje. Ovaj će seminar razmotriti nekoliko zanimljiviih otkrivenih sigurnosnih propusta te službena ili potencijalna rješenja za sprječavanje istih. Logo Solidity-ja vidljiv je na sljedećoj slici. |
| {{ : | {{ : | ||
| Redak 31: | Redak 31: | ||
| Za razumijevanje ovog napada, potrebno se upoznati s pojmom fallback funkcije. Fallback funkcija je funkcija koja se izvršava kada neki ugovor primi ethere bez ikakvih drugih podataka povezanih s tom transakcijom. Također, izvršavaju se kad identifikator funkcije ne odgovara niti jednoj funkciji dostupnoj u pametnom ugovoru ili kada nikakvi podatci nisu dani pri pozivu funkcije. Fallback funkcije nemaju ime, ne mogu primati argumente, ne mogu vraćati ništa te u jednom ugovoru postoji najviše jedna fallback funkcija. | Za razumijevanje ovog napada, potrebno se upoznati s pojmom fallback funkcije. Fallback funkcija je funkcija koja se izvršava kada neki ugovor primi ethere bez ikakvih drugih podataka povezanih s tom transakcijom. Također, izvršavaju se kad identifikator funkcije ne odgovara niti jednoj funkciji dostupnoj u pametnom ugovoru ili kada nikakvi podatci nisu dani pri pozivu funkcije. Fallback funkcije nemaju ime, ne mogu primati argumente, ne mogu vraćati ništa te u jednom ugovoru postoji najviše jedna fallback funkcija. | ||
| - | Ovaj je napad omogućen kada pametni ugovor šalje | + | Ovaj je napad omogućen kada pametni ugovor šalje |
| - | Pogledajmo | + | Na sljedećim slikama nalazi se primjer. U primjeru su dva pametna ugovora - napadnuti ugovor EtherStore te ugovor napadača Attack. Detaljna objašnjenja nalaze se ispod slika. |
| {{: | {{: | ||
| Redak 41: | Redak 41: | ||
| U ovom primjeru EtherStore je napadnuti ugovor, a Attack je ugovor napadač.Originalna željena funkcionalnost ugovora EtherStore je da pohranjuje riječnik stanja računa svojih klijenata. Neki klijent može pohraniti određenu količinu valute (wei-ja) koji će se dodati na njegovo stanje računa, te može podizati wei-je sa svog računa. Naravno, u metodi za podizanje novaca, pametni ugovor EtherStore provjerava je li iznos koji se pokušava podići manji od stanja računa klijenta (naravno, nije moguće podići više sredstava nego što postoji na računu) te postoji ograničenje da svaki klijent može podići sredstva maksimalno jednom u tjedan dana. Ova su ograničenja vidljiva u linijama 14 i 16 pametnog ugovora EtherStore. U liniji 17, EtherStore šalje sredstva klijentu te u linijama 18 i 19 osvježava stanje računa i vremensku oznaku zadnjeg podizanja novca. | U ovom primjeru EtherStore je napadnuti ugovor, a Attack je ugovor napadač.Originalna željena funkcionalnost ugovora EtherStore je da pohranjuje riječnik stanja računa svojih klijenata. Neki klijent može pohraniti određenu količinu valute (wei-ja) koji će se dodati na njegovo stanje računa, te može podizati wei-je sa svog računa. Naravno, u metodi za podizanje novaca, pametni ugovor EtherStore provjerava je li iznos koji se pokušava podići manji od stanja računa klijenta (naravno, nije moguće podići više sredstava nego što postoji na računu) te postoji ograničenje da svaki klijent može podići sredstva maksimalno jednom u tjedan dana. Ova su ograničenja vidljiva u linijama 14 i 16 pametnog ugovora EtherStore. U liniji 17, EtherStore šalje sredstva klijentu te u linijama 18 i 19 osvježava stanje računa i vremensku oznaku zadnjeg podizanja novca. | ||
| - | Pogledajmo sada napadača. | + | Napadač prvo pohranjuje određena sredstva (1 wei) na svoj račun u EtherStore, a zatim pokreće funkciju za podizanje tih sredstava - također 1 wei. Zahtjev za podizanje sredstava uspješno prolazi sve provjere te se u liniji 17 ugovora EtherStore sredstva (1 wei) šalju napadaču. Upravo ovdje događa se sigurnosni propust. Linija 17 zapravo pokreće fallback funkciju ugovora Attack, a u fallback funkciji nalazi se zloćudni kod. Taj kod ponovno poziva funkciju EtherStore-a za podizanje sredstava (ponovno jednog wei-a). Problem je u činjenici što su sredstva prethodnog poziva već na računu napadača, a novi poziv funkcije withrawFunds kreće se izvršavati prije nego što je prethodni poziv stigao osvježiti potrebne varijable stanja na računu i vremenske oznake podizanja novca. Tu zapravo ulazimo u petlju koja, wei po wei, potpuno prazni ukupan račun ugovora EtherStore, uz uspješne provjere svih varijabli u svakom pozivu. |
| - | Ovo je jedan od većih i važnijih sigurnosnih prijetnji koje treba imati na umu pri dizajniranju pametnih ugovora. Ovakvo neželjeno ponašanje može se spriječiti na više načina. Jedno od rješenja je korištenje funkcije transfer() pri slanju sredstava vanjskim ugovorima. Funkcija transfer sa svojim pozivom šalje dovoljno gas-a (platne jedinice za izvršavanje funkcija) da bi se sredstva poslala, ali nedovoljno da bi vanjski ugovor izveo operaciju poput zvanja nekog drugog ugovora - to automatski sprječava ponovno pozivanje napadnutog ugovora. Još jedno rješenje je koristiti " | + | Ovo je jedan od većih i važnijih sigurnosnih prijetnji koje treba imati na umu pri dizajniranju pametnih ugovora. Ovakvo neželjeno ponašanje može se spriječiti na više načina. Jedno od rješenja je korištenje funkcije transfer() pri slanju sredstava vanjskim ugovorima. Funkcija transfer sa svojim pozivom šalje dovoljno gas-a (platne jedinice za izvršavanje funkcija) da bi se sredstva poslala, ali nedovoljno da bi vanjski ugovor izveo operaciju poput zvanja nekog drugog ugovora - to automatski sprječava ponovno pozivanje napadnutog ugovora. Još jedno rješenje je koristiti " |
| Najpoznatiji napad ove vrste je napad na The DAO organizaciju (Decentralized autonomous organization). U tom trenutku, njihov pametni ugovor držao je na sebi više od 150 milijuna dolara. Ovakvim napadom napadač je uspio trećinu svih sredstava prebaciti na vanjski račun. Kako bi ispravili grešku, Ethereum zajednica odlučila se na kontroverzno rješenje - napraviti granu na Ethereum blockchainu i virtualno vratiti sva sredstva na originalni ugovor. Kao posljedica, dan danas postoje dva službena Ethereum blockchaina - Ethereum i Ethereum Classic (na Ethereum classic još se vidi posljedica napada). | Najpoznatiji napad ove vrste je napad na The DAO organizaciju (Decentralized autonomous organization). U tom trenutku, njihov pametni ugovor držao je na sebi više od 150 milijuna dolara. Ovakvim napadom napadač je uspio trećinu svih sredstava prebaciti na vanjski račun. Kako bi ispravili grešku, Ethereum zajednica odlučila se na kontroverzno rješenje - napraviti granu na Ethereum blockchainu i virtualno vratiti sva sredstva na originalni ugovor. Kao posljedica, dan danas postoje dva službena Ethereum blockchaina - Ethereum i Ethereum Classic (na Ethereum classic još se vidi posljedica napada). | ||
| Redak 52: | Redak 52: | ||
| Ovaj se napad bazira na postojanju overflowa i underflowa. Overflow i underflow javljaju se kao posljedica načina na koji računalo zapisuje brojeve u memoriju. Za zapis svakog tipa podatka rezerviran je određen broj bitova u memoriji. Primjerice za tip podatka uint8 rezervirano je 8 bitova te je posljedično u taj tip podatka moguće zapisati samo brojeve u rasponu [0,255]. Kada bi u varijabli tipa uint8 bio zapisan broj 255 i kada bismo mu pribrojili 1, umjesto 256 u varijabli bi bila zapisana vrijednost 0. Analogno, kada bismo varijabli sa vrijednošću 0 pokušali oduzeti 1, dobili bismo 255, a ne -1. Ova je pojava dovela do nekih ozbiljnih sigurnosnih prijetnji u razvoju pametnih ugovora. | Ovaj se napad bazira na postojanju overflowa i underflowa. Overflow i underflow javljaju se kao posljedica načina na koji računalo zapisuje brojeve u memoriju. Za zapis svakog tipa podatka rezerviran je određen broj bitova u memoriji. Primjerice za tip podatka uint8 rezervirano je 8 bitova te je posljedično u taj tip podatka moguće zapisati samo brojeve u rasponu [0,255]. Kada bi u varijabli tipa uint8 bio zapisan broj 255 i kada bismo mu pribrojili 1, umjesto 256 u varijabli bi bila zapisana vrijednost 0. Analogno, kada bismo varijabli sa vrijednošću 0 pokušali oduzeti 1, dobili bismo 255, a ne -1. Ova je pojava dovela do nekih ozbiljnih sigurnosnih prijetnji u razvoju pametnih ugovora. | ||
| - | Pogledajmo primjere. | + | Na sljedećoj slici nalazi se primjer objašnjen u tekstu ispod slike. |
| {{: | {{: | ||
| Redak 58: | Redak 58: | ||
| Zamišljena funkcionalnost prikazanog pametnog ugovora TimeLock je pohrana novca te mogućnost podizanja uz minimalnu vremensku odgodu od jednog tjedna. Uporabom funkcije increaseLockTime, | Zamišljena funkcionalnost prikazanog pametnog ugovora TimeLock je pohrana novca te mogućnost podizanja uz minimalnu vremensku odgodu od jednog tjedna. Uporabom funkcije increaseLockTime, | ||
| - | Sličan bi problem nastao kada bismo recimo | + | Sličan bi problem nastao kada bi se primjerice |
| Trenutno rješenje za sprječavanje ovakvih napada je korištenje (ili razvoj) matematičkih paketa koji bi zamijenili standardne matematičke operacije te koji bi provjerama sprječavali pojavu overflowa i underflowa. Primjer takve knjižnice je Safe Math Library kojeg razvija OppenZeppelin. | Trenutno rješenje za sprječavanje ovakvih napada je korištenje (ili razvoj) matematičkih paketa koji bi zamijenili standardne matematičke operacije te koji bi provjerama sprječavali pojavu overflowa i underflowa. Primjer takve knjižnice je Safe Math Library kojeg razvija OppenZeppelin. | ||
| - | Primjer ovog napada u stvarnom svijetu je konstrukcija ponzijeve sheme na Ethereumu (PoWHC - Proof of Weak Hands Coin), čiji su kreatori zaboravili na problem overflowa i underflowa te posljedično izgubili 866 ethera | + | Primjer ovog napada u stvarnom svijetu je konstrukcija ponzijeve sheme na Ethereumu (PoWHC - Proof of Weak Hands Coin), čiji su kreatori zaboravili na problem overflowa i underflowa te posljedično izgubili 866 Ethera |
| Redak 77: | Redak 77: | ||
| Svrha ovog ugovora je dodijeliti nagradu sretnim dobitnicima - korisnicima sa adresom čijih su zadnjih 8 hex znakova nule. Ukoliko se provjera uspješno izvrši, poziva se funkcija _sendWinnings koja šalje pobjedniku novčanu nagradu. Problem je u tome što je autor ugovora HashForEther zaboravio specificirati vidljivost funkcije _sendWinnings na privatnu te bilo tko može jednostavno pozvati izravno tu funkciju i dobiti novčanu nagradu. | Svrha ovog ugovora je dodijeliti nagradu sretnim dobitnicima - korisnicima sa adresom čijih su zadnjih 8 hex znakova nule. Ukoliko se provjera uspješno izvrši, poziva se funkcija _sendWinnings koja šalje pobjedniku novčanu nagradu. Problem je u tome što je autor ugovora HashForEther zaboravio specificirati vidljivost funkcije _sendWinnings na privatnu te bilo tko može jednostavno pozvati izravno tu funkciju i dobiti novčanu nagradu. | ||
| - | Kako bi se izbjegla ova neugodnost, dobra je praksa uvijek specificirati vidljivost svim funkcijama, čak i javnim funkcijama, kako bismo uvijek | + | Kako bi se izbjegla ova neugodnost, dobra je praksa uvijek specificirati vidljivost svim funkcijama, čak i javnim funkcijama, kako bi programer |
| Primjer iz stvarnog svijeta je napadač koji je uočio ovakav propust u Parity multi-signature novčaniku na Ethereum platformi te iskoristivši tu ranjivost prebacio vrtoglavih 31 milijun dolara vrijednosti u Etheru na svoj račun u samo nekoliko minuta. Da napad nije vrlo brzo uočen i da je napadač imao još nekoliko sati, uspio bi otići sa 180 milijuna dolara vrijednosti sa svih ranjivih novčanika na mreži. Napad je spriječen tako da je grupa dobroćudnih hakera, uočivši napad, brzo analizirala isti te su brzom reakcijom sami hakirali preostale novčanike s navedenom ranjivošću i sami ukrali preostalih 150 milijuna dolara prije nego što je to uspio učiniti napadač. Nakon reorganizacije ranjivog koda i uklanjanja sigurnosne prijetnje, dobroćudni su napadači vratili ukradene iznose prethodnim vlasnicima. Nažalost, preostalih 31 milijun dolara nije se mogao vratiti prvobitnim vlasnicima. | Primjer iz stvarnog svijeta je napadač koji je uočio ovakav propust u Parity multi-signature novčaniku na Ethereum platformi te iskoristivši tu ranjivost prebacio vrtoglavih 31 milijun dolara vrijednosti u Etheru na svoj račun u samo nekoliko minuta. Da napad nije vrlo brzo uočen i da je napadač imao još nekoliko sati, uspio bi otići sa 180 milijuna dolara vrijednosti sa svih ranjivih novčanika na mreži. Napad je spriječen tako da je grupa dobroćudnih hakera, uočivši napad, brzo analizirala isti te su brzom reakcijom sami hakirali preostale novčanike s navedenom ranjivošću i sami ukrali preostalih 150 milijuna dolara prije nego što je to uspio učiniti napadač. Nakon reorganizacije ranjivog koda i uklanjanja sigurnosne prijetnje, dobroćudni su napadači vratili ukradene iznose prethodnim vlasnicima. Nažalost, preostalih 31 milijun dolara nije se mogao vratiti prvobitnim vlasnicima. | ||