10 jaar oude fout in XRP-ledger kon XRP uit het niets creëren

Wat was er nu eigenlijk mis?

Het probleem zat in de code die betalingen afhandelt via de ingebouwde gedecentraliseerde beurs (DEX) van het XRP Ledger. Volgens het officiële rapport over de kwetsbaarheid dat gisteren werd gepubliceerd, telde de engine de bedragen bij elkaar op met behulp van ongecontroleerde 64-bits rekenkunde wanneer één enkele betaling veel aanbiedingen omvatte.

Door dat totaal hoog genoeg op te drijven, vond er een „wrap-around“ plaats, wat het gevolg is van een integer-overflow. Een gigantisch getal werd vervolgens een klein getal en de verkopers aan de andere kant van de transactie werden volledig uitbetaald, maar de koper kreeg slechts het „gewrapte“, minuscule totaal in rekening gebracht. Het verschil bestond uit XRP die nooit eerder had bestaan.

Het grootboek voert wel een veiligheidscontrole uit, een zogenaamde ‘invariant’, die moet bevestigen dat er nooit XRP wordt gecreëerd. Die controle maakte gebruik van dezelfde ongecontroleerde wiskunde, waardoor ze blind was voor precies die fout die ze juist moest opsporen. Het rapport herleidt de fout tot de huidige betalingsengine, die in 2015 is geschreven.

Hoe goedkoop zou een aanval zijn geweest?

Volgens het rapport bedroegen de kosten enkele honderden XRP die als reserves waren geblokkeerd – deze worden teruggegeven zodra de objecten worden verwijderd – plus de gebruikelijke transactiekosten. Een aanvaller zou honderden opzettelijk verkeerd geprijsde aanbiedingen hebben moeten plaatsen en vervolgens één betaling via deze aanbiedingen moeten leiden.

De opbrengst was het angstaanjagende deel: RippleX noemde de bug kritiek omdat er in één gevalde transactie meer besteedbare XRP had kunnen worden gecreëerd dan de totale voorraad. De hele pitch van XRP berust op een harde limiet van 100 miljard tokens, dus een stille uitgifte zou de kernbelofte van het activum hebben ondermijnd. Daarom werd het in berichten zoals die van Whale Insider gepresenteerd als een bug die „miljarden” XRP had kunnen voortbrengen.

Wie heeft het ontdekt en hoe snel werd het verholpen?

Het tijdsverloop was vrij kort en verliep als volgt:

• 22 september: Cayden Liao en Veria AI dienden hun bevindingen in via het XRPL Bug Bounty-programma en gaven het de ernstgraad „Major“.
• 23 september: RippleX reproduceerde het, verhoogde de ernst naar ‘kritiek’ en de oplossing werd geïmplementeerd.
• 25 september: Xrpld 3.4.1 werd uitgebracht en meer dan 80% van de standaard Unique Node List (UNL)-validators draaide deze versie die dag.
• 9 oktober: Openbare bekendmaking.

De patch werd niet onderworpen aan de gebruikelijke stemming over wijzigingen, maar werd in plaats daarvan als directe codewijziging in release 3.4.1 uitgebracht en trad in werking naarmate elke server werd geüpgraded. De broncode werd pas na de implementatie gepubliceerd, een standaardprocedure om te voorkomen dat aanvallers een routekaart in handen krijgen. Het XRPL Operations-account heeft sindsdien 3.4.1 tot de minimaal vereiste versie gemaakt en voegde hieraan toe:

We hebben geen aanwijzingen gevonden dat dit probleem op enig openbaar netwerk is misbruikt.

Een tweede, minder ernstige bug werd in dezelfde release verholpen. Deze had betrekking op de manier waarop batchtransacties worden verpakt, en de oplossing hiervoor zit vervat in het amendement fixBatchV1_2, dat op 9 oktober samen met BatchV1_1 live ging op het Mainnet. Volgens het rapport is ook hierdoor geen geld verloren gegaan.

De bekendmaking kwam op een slechte week voor de beveiliging van cryptovaluta, aangezien de verliezen aan Ledger-apparaten, zoals gemeld door Bitcoin.com News, naar schatting 93,4 miljoen dollar bedroegen. Ten slotte bereidt het door Ripple gesteunde Evernorth zich voor om maandag onder de ticker XRPN op de Nasdaq te gaan handelen, met ongeveer 473 miljoen XRP in zijn bezit. XRP breidt zich ook uit naar gedecentraliseerde financiering (DeFi), waarbij Firelight onlangs kluisbeveiliging op het netwerk heeft geactiveerd.