Het ontwikkelteam van de XRP Ledger (XRPL) maakte op 9 oktober een integer-overloopfout bekend die, onder zorgvuldig geconstrueerde omstandigheden, de creatie van besteedbaar XRP uit het niets mogelijk had kunnen maken. De fix werd op 25 september uitgebracht in xrpld versie 3.4.1, circa twee weken vóór de openbare bekendmaking, en het team meldde geen aanwijzingen te hebben gevonden dat de kwetsbaarheid ooit is misbruikt op een publiek netwerk.

De details werden uiteengezet in het kwetsbaarheidsrapport van XRPL van 9 oktober.

Een betalingsberekening die XRP uit het niets had kunnen produceren

Het rapport beschrijft een integer-overloopfout in de betalingsengine van het grootboek. Onder zorgvuldig geconstrueerde omstandigheden had een betaling die veel orderboekoffers verwerkte rekeningen XRP kunnen bijschrijven die de verzender feitelijk nooit had betaald. Orderboeken zijn een native XRPL-structuur, onderdeel van de ingebouwde exchange van het grootboek, dus de foutieve berekening zit in code die zowel handel als betalingen op het grootboek ondersteunt.

Elke individuele offer in de transactie kon op zichzelf geldig lijken. Het probleem ontstond toen de engine de XRP-bedragen van bij elkaar optelde. Zodra het totaal de maximale grootte van het getal dat voor die berekening werd gebruikt overschreed, kon het omrollen naar een veel kleinere waarde in plaats van een fout te genereren.

In dat scenario zou de engine de offereigenaren nog steeds hun volledige XRP-bedragen bijschrijven, terwijl de koper alleen het omgerolde totaal in rekening werd gebracht. Het verschil vertegenwoordigde nieuw gecreëerd XRP, dat vervolgens verplaatst, verhandeld of naar een exchange gestuurd kon worden als elk ander saldo.

Waarom de fout ernstig was

De aanval vereiste geen groot XRP-saldo. Een aanvaller had de rekeningen die de offers plaatsten kunnen beheren, de nodige accountreserves en transactiekosten kunnen betalen, en vervolgens het gecreëerde XRP over die rekeningen kunnen verdelen.

De kwetsbaarheid zat in de betaalarithmetiek in plaats van in toegang tot wallets, waardoor accountsleutels onaangetast bleven. Om deze te activeren waren honderden doelbewust geprijsde offers en een transactie nodig die ze gezamenlijk verwerkte; een gewone XRP-betaling of -handel zou de waarden die nodig zijn voor de overloop niet benaderen.

Voor een grootboek zijn er weinig defecten zo gevoelig als een defect dat besteedbare units kan creëren, omdat elk saldo ervan afhankelijk is dat nieuw XRP alleen via de gedefinieerde regels van het netwerk in omloop komt.

XRPL verklaarde geen aanwijzingen te hebben gevonden voor misbruik op een publiek netwerk, en er werd geen private-key-compromittering, verlies van fondsen of consensusfalen gemeld. De fout lijkt aanwezig te zijn geweest sinds de huidige betalingsengine in 2015 werd geschreven, en bleef onontdekt omdat normale activiteit de rekenlimiet nooit bereikte.

De bestaande bescherming het grootboek tegen nieuw gecreëerd XRP was ook gebaseerd op dezelfde soort optelling. Deze kon op dezelfde manier omrollen als de betalingsengine, waardoor de transactie normaal leek in plaats van de onverwachte toename van saldi te signaleren.

Waarom ontwikkelaars een nooduitrol gebruikten

Ontwikkelaars brachten de overloopfix uit vóór publicatie van de technische details, omdat een normaal amendementtraject een bekend exploit wekenlang beschikbaar zou hebben gelaten. De patch werd op 25 september uitgebracht in xrpld versie 3.4.1, terwijl de openbare bekendmaking volgde op 9 oktober.

XRPL wijzigt transactieregels gewoonlijk via amendementen. Validators upgraden eerst hun software, onderhouden vervolgens de vereiste steun gedurende een bepaalde periode, voordat de nieuwe regel op hetzelfde grootboekpunt in het hele netwerk activeert. Dat proces voorkomt situaties waarin verschillende servers tot verschillende conclusies komen over dezelfde transactie.

Wachten op dat proces zou in dit geval een moeilijk probleem hebben gecreëerd. Omdat xrpld open source is, zou het publiceren van de reparatie aanvallers kunnen tonen waar ze moeten zoeken, terwijl oudere software het kwetsbare transactiepad nog accepteerde. Het team zorgde er daarom voor dat de nieuwe overloopcontrole inging zodra een individuele server upgradeerde.

Die snellere aanpak hield een tijdelijk compatibiliteitsrisico in: een ongepatchte server zou een exploit-transactie kunnen accepteren die een geüpgradete server afwees. Ontwikkelaars vonden dat minder gevaarlijk dan toestaan dat gecreëerd XRP de markt bereikte. Volgens het rapport had meer dan 80% van de validators op de standaard UNL geüpgraded op de dag dat versie 3.4.1 werd uitgebracht.

De bekendmaking betrof ook een tweede, afzonderlijke fout

Het rapport beschreef ook een validatieprobleem in de komende Batch-functie van XRPL, waarmee gebruikers meerdere transacties als één eenheid kunnen indienen. De fout had kunnen veroorzaken dat servers met verschillende softwareversies van mening verschillen over een misvormde Batch-transactie, wat grootboekvalidatie onderbreken of applicaties kon breken die transactiegegevens parsen.

De Batch-fout werd ontdekt voordat de functie het mainnet bereikte. Het overloopprobleem daarentegen betrof bestaande betalingsengine-code, waardoor de patch niet kon wachten op een standaard activeringscyclus. Nu de functie zelf nog komende is, ligt de komst ervan naar het mainnet met de validatiefix al op zijn plaats nog vooruit.

Het rapport verscheen terwijl XRPL ook nieuwe accountbeheertools voor bedrijven activeerde. De wijzigingen behandelen verschillende delen van het grootboek, maar beide zijn afhankelijk van node-operatoren, wallet-aanbieders en ontwikkelaars die dezelfde huidige regels volgen.

Wat gebruikers en operators moeten doen

Gewone XRP-houders hoeven geen fondsen te verplaatsen, geen wallet te vervangen en geen tokens te wisselen. De update betreft de software die transacties valideert, niet accountsaldi, walletsleutels of het XRP-aanbod dat gebruikers aanhouden.

• XRP-houders: Geen actie vereist.
• Exchange-gebruikers: Volg mededelingen van het platform als een exchange onderhoud uitvoert aan zijn eigen XRPL-infrastructuur.
• Node-operatoren: Upgrade naar xrpld 3.4.1 of later om synchroon te blijven met het netwerk. Oudere servers zijn nu amendment-geblokkeerd na de activering van de Batch-fix, wat betekent dat ze de huidige grootboekregels niet kunnen blijven volgen totdat ze bijwerken.

De fix beschermde de aanbodregels van XRP voordat ze werden getest

De bekendmaking toont hoe dicht het grootboek bij een integriteitsfalen van het aanbod kwam en waarom validators snel handelden. De fout werd gefixt voordat de details openbaar werden, er werd geen exploit gevonden, en de betalingsengine gebruikt nu controles die zijn ontworpen om dezelfde klasse van rekenfouten te stoppen voordat deze een gevalideerd grootboek bereikt. Van buitenaf resteert de vraag hoe snel de rest van het netwerk convergeert naar xrpld 3.4.1 of later, nu ongepatchte servers al-geblokkeerd zijn voor het volgen van het huidige grootboek.

Dit artikel is uitsluitend bedoeld ter informatie en vormt geen beleggings- of technisch advies. Node-operatoren dienen de actuele XRPL-releasedocumentatie te raadplegen voordat zij productie-infrastructuur bijwerken.

Dit artikel is gebaseerd op berichtgeving die oorspronkelijk is gepubliceerd door Coindoo.