-

RIMANI SEMPRE IN CONTATTO CON LATOOSCURO-TRADING.COM TWITT

martedì 25 settembre 2018

Scoperto un bug nel codice di Bitcoin: quali sono le conseguenze


La recente scoperta di un bug nel codice Bitcoin non è un caso isolato, ma è pur sempre un evento rarissimo, che non capitava da oltre 5 anni. Certamente è un caso eclatante che fa riflettere su alcuni temi.
In passato, in tutta la storia di Bitcoin sono stati scoperti due bug critici, che hanno richiesto un fork della blockchain per essere corretti, rispettivamente il 15 agosto 2010 e l’11 marzo 2013.

I BUG “STORICI” DI BITCOIN

Il 15 agosto 2010 il blocco numero 74638 è stato creato con 184 milioni di bitcoin, versati in 3 distinti indirizzi, di cui due da 92 milioni di btc.

Il codice che controllava la correttezza delle transazioni era buggato poiché non prevedeva un controllo per output così grandi: un po’ come se volessimo controllare una transazione che trasferisce oltre 100 bitcoin, ma ogni volta che arriviamo a 99 il sistema riparte a contare da zero.
Un miner ha sfruttato questa “falla” per creare bitcoin oltre la quantità prevista. Da qui, il nome con cui è conosciuto l’evento: “overflow value incident”. Dopo 5 ore dal fatto, è stata sviluppata una patch e i primi miners ad installarla hanno creato un blocco 74638 alternativo, questa volta “corretto”.

Tecnicamente la patch rappresentava un soft fork, perciò fino al momento in cui i miners con patch non hanno superato (in potenza di calcolo) quelli con il vecchio software, la stragrande maggioranza di nodi della rete ancora riconosceva come la “vera” blockchain Bitcoin quella corrotta, con 184 milioni di bitcoin creati in un solo blocco.
I nodi aggiornati hanno prevalso soltanto al blocco 74691, creando un numero di blocchi maggiore rispetto alla catena concorrente. In totale, dalla scoperta del bug, erano passate 8 ore e mezza prima che la situazione fosse ritornata alla normalità.
La patch era stata rilasciata direttamente da Satoshi Nakamoto con un post su bitcoin talk seguito dalla traduzione in ogni lingua (la prima, come sempre, in italiano dal nostro Franco Cimatti).
Relativamente a quell’evento del 2010 non si hanno notizie di danni economici riportati dagli utenti, anche perché a quel tempo non esisteva un’economia intorno a Bitcoin.

Ricordiamo che le prime quotazioni di Bitcoin che lo davano a 0,007 dollari risalgono al marzo 2010. Nonostante il prezzo abbia avuto un incremento del 900% nel luglio dello stesso anno, passando in soli 5 giorni a circa 0,08 dollari (8 cent di dollaro), le transazioni erano estremamente rare, quindi sarebbe stato molto difficile per un attaccante sfruttare il momento di confusione del fork, per tentare di vendere i propri bitcoin (spendendoli sulla catena corrotta), e trasferirli al contempo in un proprio wallet nella blockchain sana.

Non essendoci replay protection fra i due fork, non c’è nemmeno certezza che il tentativo di frode andasse a buon fine.
Nel 2013 invece c’era già un’economia piuttosto viva intorno a Bitcoin. Il fork dell’11 marzo è stato risolto entro 6 ore circa dalla scoperta del problema, ne ho parlato estensivamente qui.
In quella situazione si ha notizia di un solo caso in cui un utente abbia effettuato un double spending (ai danni del servizio OKPay) e non fu tanto un tentativo di frode, quanto piuttosto un test da parte di quell’utente che si accorgeva in quel momento dell’anomalia.

LA SCOPERTA DEL 17 SETTEMBRE 2018

Pochi giorni fa, uno sviluppatore (sotto pseudonimo) che stava lavorando sul codice di Bitcoin Cash ha scoperto un bug critico.

Inizialmente, pensava fosse soltanto un bug del software Bitcoin ABC, ovvero il full node di riferimento di Bitcoin Cash. In realtà, si è presto accorto che ABC aveva ereditato quelle linee di codice direttamente da Bitcoin Core, il principale full node di Bitcoin. Un miner malevolo quindi avrebbe potuto sfruttare il bug per tentare un attacco su Bitcoin, non soltanto su Bitcoin Cash.
Fortunatamente la notizia dell’esistenza del bug è arrivata prima agli sviluppatori che a possibili hacker malintenzionati. In una giornata la rete è stata messa in sicurezza, prima che chiunque altro potesse anche solo pensare a un attacco.
Ma di che bug si tratta? E cosa sarebbe potuto succedere se il bug fosse stato scoperto prima da un attore malevolo? E a quel punto che contromisure avremmo dovuto prendere? Come si possono prevenire altre situazioni simili in futuro? Vediamo passo a passo la risposta a queste domande.

DAL BUG AL FIX IN 5 ORE

Alle 14.57 del 17 settembre lo sviluppatore di Bitcoin Cash contatta alcuni dei principali dev del software Bitcoin Core (Pieter Wuille, Gregory Maxwell, Wladimir Van Der Laan) e il principale dev di Bitcoin ABC (Amauri Sechet) per comunicare la sua scoperta.

Gregory Maxwell condivide il report con altri Core developers, fra cui Matt Corallo, che aveva scritto le righe di codice incriminate. Matt Corallo stesso si accorge che il bug è anche più grave di quanto riportato. In breve tempo viene scritta una patch che viene inviata ad una mining pool, la prima contattata (Slushpool), la quale effettua l’upgrade alle ore 20.48.
Un’ora circa dopo (21.57) la patch viene resa pubblica, sia per Bitcoin Core che Bitcoin ABC. Nel frattempo vengono contattate alcune persone chiave nell’ecosistema Bitcoin al fine di assicurarsi che tutti i principali miners o mining pools venissero a conoscenza degli eventi ed effettuassero l’upgrade al più presto.

Dalla sera del giorno dopo (18 settembre) la situazione è ritenuta ormai sicura, poiché la maggior parte dell’hashrate della rete ha aggiornato alla nuova versione del software, e la notizia viene comunicata sui principali canali come bitcointalk e reddit, così da raggiungere un vasto pubblico di utenti.
Pieter Wuille il 19 settembre scrive nella mailing list ufficiale, sollecitando a tutti l’upgrade.

IL CODICE FALLATO RISALE AL 10 NOVEMBRE 2016

Il 10 novembre 2016 è stata approvata una modifica al codice di Bitcoin Core che ottimizza i tempi che i nodi impiegano per validare le transazioni, rimuovendo alcuni “controlli” ridondanti (che fanno perdere al nodo circa 0.6 millisecondi durante la validazione del blocco ricevuto dal miner).
Ciò di cui nessuno si era accorto è che questa modifica non era stata fatta compiutamente: in particolare, non prevedeva che un miner malevolo con buone capacità di hacking avrebbe potuto modificare il proprio software bitcoin con l’intento di creare blocchi che includessero transazioni anomale.

Nello specifico, il miner avrebbe potuto includere una propria transazione nel blocco, replicandola all’infinito, inviando a un proprio wallet più e più volte l’output (effettuando quindi double spending). Bisogna specificare che un qualsiasi miner bitcoin ha sempre potuto (e sempre potrà in futuro) manipolare e modificare il codice di Bitcoin, al fine di produrre un blocco in cui è presente un double spending, ma questo fatto non è certamente un bug.

Il fatto che chiunque possa modificare il codice del proprio software bitcoin non è un problema finché i nodi “sani” risultano incompatibili con la modifica e quindi rifiutano le informazioni corrotte provenienti da nodi manipolati. Tuttavia, mancando dal novembre 2016 quel controllo aggiuntivo su Bitcoin Core (versione 0.14 e successive), una transazione anomala come quella descritta non viene espressamente rifiutata dai nuovi nodi Bitcoin Core.

COSA SAREBBE SUCCESSO IN CASO DI ATTACCO?

I nodi Bitcoin Core 0.14 che avessero ricevuto il nuovo blocco propagato dal miner malevolo avrebbero notato che c’era qualcosa di strano, senza però riuscire a individuare cosa, perciò si sarebbero fermati, andando in crash.

Insomma l’attaccante sarebbe riuscito a far crashare un certo numero di nodi, inviando nella rete una sorta di “blocco velenoso”. Un attacco di questo tipo è detto Denial of Service (DOS) poiché inabilita i nodi della rete ad operare e prestare servizio.
Bitcoin Core 0.14 non era però l’ultima release di Core, poiché circa un anno fa, il 14 settembre 2017, è uscita la versione 0.15, in cui è stato fatto un ulteriore cambiamento al codice che permane fino alla vesione 0.16.2.

Questi nodi più recenti non sarebbero affato crashati, bensì avrebbero accettato il blocco “velenoso”, permettendo a tutti gli effetti una inflazione infinita. Di questo particolare se ne è accorto Matt Corallo non appena è stato avvisato del bug. Insomma, per assurdo il protocollo di Bitcoin Core poteva ammettere (almeno sotto particolari condizioni) una supply illimitata di Bitcoin, anziché il famoso tetto di 21 milioni che spesso si dice essere “garantito” da arcane leggi matematiche.

Insomma il bug poteva essere per molti nodi ben più grave che un semplice crash temporaneo del nodo, che si risolve aggiornando il software e riavviando. Bisogna notare che i nodi bitcoin con versioni 0.14 e successive erano, fino a pochi giorni fa, quelle presenti in maggior numero nel network Bitcoin (ad oggi la versione 0.16.3 patchata è quella preponderante), mentre le versioni del tutto immuni all’attacco (0.13 e inferiori) sono un numero decisamente minore.
Ci sono altri nodi immuni, ovvero tutti quelli con implementazioni diverse da Bitcoin Core (scritte anche in altri linguaggi, ad esempio btcd, bcoin e Bitcoin Unlimited), tuttavia si può stimare che i nodi immuni ammontassero a circa il 10% del totale, mentre il 90% della rete di full nodes era costituito da nodi Bitcoin Core co Autore: Alberto De Luigi Fonte: News Trend Online

Nessun commento:

Posta un commento

LA SETTIMANA CALENDARIO RISULTATI UTILI SOCIETA' QUOTATE

Calendario Utili fornito da Investing.com Italia - Il Portale di Trading sul Forex e sui titoli di borsa.