Hinikayat ni Ripple Director of Engineering Vijay Khanna ang mga operator ng XRP Ledger node noong Agosto 2 na i-install ang xrpld bersyon 3.2.1 matapos maobserbahan ng mga developer ang pagbaha ng validator manifest noong Hulyo 31.
Nililimitahan ng hotfix kung paano pinoproseso, iniimbak, at ibinabahagi ng mga node ang data na natanggap mula sa hindi kilalang mga identidad ng validator.
Ang XRP Ledger ay patuloy na nagsasara ng mga ledger nang normal sa panahon ng insidente, ayon sa XRP Ledger Operations. Ang magagamit na ebidensya samakatuwid ay tumutukoy sa pressure sa mga resources ng node at komunikasyon ng peer-to-peer sa halip na isang kumpirmadong pagkawala ng pondo, binagong transaksyon o pagkabigo ng ledger consensus. Hindi pa naglalathala ang mga developer ng isang CVE identifier o pagtatantya ng pagkalugi sa pananalapi na konektado sa insidente.
Ang mga validator manifest ay cryptographically signed na mga record na nagkokonekta sa stable master identity ng isang validator sa temporary key na ginagamit nito para sa pang-araw-araw na mensahe ng validasyon. Kapag binago ng mga operator ang mga temporary key na iyon, naglalathala sila ng bagong manifest na nilagdaan ng master key upang mapatunayan ng ibang mga node ang pagbabago.
Bago ang hotfix, maaaring tumanggap, mag-cache, at muling mag-broadcast ang mga node ng validly structured manifests na nauugnay sa mga validator key na hindi nila kinikilala. Maaaring samantalahin ng isang attacker ang gawi na iyon sa pamamagitan ng paggawa ng maraming hindi kilalang identidad at puwersahin ang mga kapareha na gumastos ng memory, storage, bandwidth, at processing capacity sa paghawak ng data. Inilalarawan ng pampublikong code record ang flaw bilang problema sa manifest propagation.
Ang opisyal na xrpld 3.2.1 release ay may petsang Hulyo 31 at inilathala bilang pinakabagong signed release noong Agosto 1. Naglalaman ito ng anim na commit sa 13 nabagong file, kabilang ang apat na commit na direktang naglilimita sa paghawak ng untrusted manifest.
Ang unang pananggalang ay tinatanggihan ang isang oversized validator manifest bago pa ganap na ma-decode ito ng node. Binabawasan nito ang gawaing pagpoproseso na maaaring i-trigger ng isang attacker sa pamamagitan ng pagpapadala ng mga indibidwal na object na mas malaki kaysa sa inaasahan ng software.
Ang pangalawa ay naglilimita sa bilang ng mga untrusted manifest na dala sa isang network message. Ang limitasyon ay nalalapat kapag nakatanggap ang mga node ng data at kapag naghahanda sila ng mga manifest message para sa mga kapareha. Ang mga oversized batch ay ibinababa nang hindi awtomatikong dinidiskonekta ang isang unpatched peer, na tumutulong sa mga na-upgrade at mas lumang node na manatiling konektado sa panahon ng rollout.
Ang ikatlong pagbabago ay naglilimita sa bilang ng mga hindi kilalang identidad ng validator na nasa manifest cache ng isang node. Itinakda ng huling code ang maximum sa 100. Kapag naabot na ang kapasidad na iyon, tinatanggihan ng software ang mga manifest na konektado sa mga bagong unlisted key habang patuloy na pinoproseso ang mga pinagkakatiwalaan o dating kinilalang validator.
Binabago rin ng patch kung paano pinapanatili at ikinakalat ang impormasyon ng untrusted manifest. Ang data ng trusted validator ay nananatiling magagamit dahil ang mga restriksyon ay target ang unlisted peer gossip sa halip na mga manifest mula sa configured o naaprubahang validator. Ang pagtukoy na ito ay nagbibigay-daan sa normal na pag-ikot ng validator key na magpatuloy habang hinaharangan ang unchecked cache growth.
Pinayuhan ni Khanna ang mga validator at iba pang operator ng imprastraktura na mag-upgrade sa bersyon 3.2.1 “sa lalong madaling panahon.” Ang kanyang mga tagubilin ay nananawagan para sa isang normal na pag-update ng software, na susundan ng paghihintay ng isa hanggang dalawang minuto at pag-check na tumatakbo ang xrpld. Pagkatapos ay dapat muling i-restart ng mga operator ang serbisyo.
Ang pangalawang restart ay mahalaga para sa mga node na maaaring nagpanatili ng hindi kilalang mga manifest bago i-install ang fix. Ang pag-update ay nagbabago ng future handling, habang ang pag-restart ng corrected server ay tumutulong na matiyak na ang lumang in-memory o dating napanatiling data ay hindi patuloy na makakaapekto sa mga operasyon.
Maaaring kailanganin din ng mga operator na kumpirmahin na pinagkakatiwalaan ng kanilang mga sistema ang kasalukuyang package-signing key ng Ripple. Nakasaad sa release notes na pinalitan ng Ripple ang GPG key na ginamit upang pirmahan ang mga xrpld package noong Pebrero 18. Ang mga kasalukuyang installation na hindi pinagkakatiwalaan ang kapalit na key ay maaaring hindi matagumpay na makatanggap ng mga awtomatikong pag-upgrade.
Ang update ay nalalapat sa mga provider ng imprastraktura sa halip na sa mga ordinaryong may hawak ng XRP. Hindi kailangang ilipat ng mga user ang XRP, palitan ang mga wallet key, o lumikha ng mga bagong account dahil sa isyu ng manifest. Ang mga palitan, custodians, wallet back ends, data providers, at mga negosyong nagpapatakbo ng sarili nilang XRPL server ay dapat kumpirmahin ang kanilang mga bersyon ng node at status ng restart.
Sinabi ng XRP Ledger Operations na isang teknikal na “post-mortem ang susunod kaagad.” Noong Agosto 2, hindi pa nailalathala ng proyekto ang ulat na iyon, kaya ang identidad ng nagpadala, ang volume ng mga manifest na naipadala at ang eksaktong paggamit ng resource sa mga apektadong node ay nananatiling hindi isinisiwalat.
Dapat ding linawin ng ulat kung kailan unang natuklasan ng mga developer ang aktibidad, kung mayroong naging unavailable na mga node at gaano kabilis inampon ng mga operator ang bersyon 3.2.1. Bagaman patuloy na nagsasara ang mga ledger, ang mabagal na pag-adopt ng patch ay maaaring mag-iwan sa mga indibidwal na server na nakalantad sa muling pagbaha kahit na ang shared ledger ay nananatiling operational.
Dumating ang hotfix kaagad pagkatapos ng mas malaking rollout ng XRPL bersyon 3.2.0. Ang release na iyon, na inilabas noong Hunyo 15, ay nagpalit ng pangalan ng reference server mula rippled patungong xrpld at nagpakilala ng mga pagbabago sa imprastraktura na nangangailangan ng mga operator na i-update ang software at service configuration.
Gaya ng naunang naiulat, ang bersyon 3.2.0 ay unang kumalat nang mas mabilis sa mga validator kaysa sa mas malawak na network ng node. Nagdaragdag ang manifest flood ng bagong dahilan para sa mga natitirang operator na lumampas sa release na iyon at i-install ang hotfix.
Samantala, sa kaugnay na balita, inilipat ni David Schwartz ang kanyang imprastraktura ng XRPL sa bersyon 3.2.0 habang inihahanda ng mga developer ang network para sa bagong pagpapangalan ng server at mga feature ng protocol. Mas maaga, gaya ng naiulat ng crypto.news, naharap din ang mga operator ng node sa deadline ng bersyon 3.1.3 na konektado sa pag-activate ng amendment.
Ang susunod na na-verify na mga update ay ang ipinangakong post-mortem at bagong data ng software-adoption. Hanggang doon, ang kumpirmadong tugon ay nananatiling limitado sa 3.2.1 release, ang apat na manifest control nito, at ang kahilingan para sa mga operator na kumpletuhin ang proseso ng pag-upgrade at restart.
