Direktur Teknik Ripple Vijay Khanna mendesak operator node XRP Ledger pada 2 Agustus untuk menginstal xrpld versi 3.2.1 setelah para pengembang mengamati banjir manifest validator pada 31 Juli.
Hotfix ini membatasi bagaimana node memproses, menyimpan, dan berbagi data yang diterima dari identitas validator yang tidak dikenal.
XRP Ledger terus menutup ledger secara normal selama kejadian tersebut, menurut Operasi XRP Ledger. Oleh karena itu, bukti yang tersedia menunjukkan tekanan pada sumber daya node dan komunikasi peer-to-peer daripada kerugian dana yang terkonfirmasi, transaksi yang diubah, atau kegagalan konsensus ledger. Para pengembang belum memublikasikan pengidentifikasi CVE atau perkiraan kerugian finansial yang terkait dengan insiden ini.
Manifest validator adalah catatan yang ditandatangani secara kriptografis yang menghubungkan identitas master stabil validator dengan kunci sementara yang digunakannya untuk pesan validasi harian. Ketika operator memutar kunci sementara tersebut, mereka memublikasikan manifest baru yang ditandatangani oleh kunci master agar node lain dapat memverifikasi perubahan tersebut.
Sebelum hotfix, node dapat menerima, menyimpan (cache), dan menyiarkan ulang manifest yang terstruktur dengan valid yang terkait dengan kunci validator yang tidak mereka kenali. Seorang penyerang dapat mengeksploitasi perilaku tersebut dengan menghasilkan banyak identitas yang tidak dikenal dan memaksa peer untuk menghabiskan memori, penyimpanan, bandwidth, dan kapasitas pemrosesan untuk menangani data. Catatan kode publik menggambarkan kelemahan ini sebagai masalah dengan penyebaran manifest.
Rilis resmi xrpld 3.2.1 bertanggal 31 Juli dan diterbitkan sebagai rilis bertanda tangan terbaru pada awal 1 Agustus. Ini berisi enam commit di 13 file yang diubah, termasuk empat commit yang secara langsung membatasi penanganan manifest yang tidak tepercaya.
Pengamanan pertama menolak manifest validator yang kebesaran sebelum node sepenuhnya mendekodenya. Hal itu mengurangi pekerjaan pemrosesan yang dapat dipicu oleh penyerang dengan mengirimkan objek individual yang lebih besar dari yang diharapkan perangkat lunak.
Yang kedua membatasi jumlah manifest yang tidak tepercaya yang dibawa dalam satu pesan jaringan. Batas ini berlaku saat node menerima data dan saat mereka menyiapkan pesan manifest untuk peer. Batch yang kebesaran dibatalkan tanpa secara otomatis memutuskan koneksi peer yang belum diperbarui, yang membantu node yang telah ditingkatkan dan yang lebih lama tetap terhubung selama peluncuran.
Perubahan ketiga membatasi jumlah identitas validator tidak dikenal yang disimpan dalam cache manifest node. Kode akhir menetapkan maksimum pada 100. Setelah kapasitas tersebut tercapai, perangkat lunak menolak manifest yang terikat pada kunci baru yang tidak terdaftar sambil terus memproses validator yang tepercaya atau yang sebelumnya dikenali.
Patch ini juga mengubah cara informasi manifest yang tidak tepercaya dipertahankan dan disebarkan. Data validator yang tepercaya tetap tersedia karena pembatasan ini menargetkan gosip peer yang tidak terdaftar daripada manifest dari validator yang dikonfigurasi atau disetujui. Perbedaan ini memungkinkan rotasi kunci validator normal berlanjut sambil memblokir pertumbuhan cache yang tidak terkendali.
Khanna menyarankan validator dan operator infrastruktur lainnya untuk meningkatkan ke versi 3.2.1 “sesegera mungkin.” Instruksinya menyerukan pembaruan perangkat lunak normal, diikuti dengan menunggu satu hingga dua menit dan memeriksa apakah xrpld berjalan. Operator kemudian harus memulai ulang layanan tersebut.
Restart kedua penting bagi node yang mungkin telah menyimpan manifest yang tidak dikenal sebelum menginstal perbaikan. Memperbarui mengubah penanganan di masa mendatang, sementara memulai ulang server yang dikoreksi membantu memastikan data lama dalam memori atau yang sebelumnya disimpan tidak terus memengaruhi operasi.
Operator mungkin juga perlu memastikan bahwa sistem mereka memercayai kunci penandatanganan paket Ripple saat ini. Catatan rilis menyatakan bahwa Ripple merotasi kunci GPG yang digunakan untuk menandatangani paket xrpld pada 18 Februari. Instalasi yang ada yang belum memercayai kunci pengganti mungkin tidak berhasil menerima pembaruan otomatis.
Pembaruan ini berlaku untuk penyedia infrastruktur daripada pemegang XRP biasa. Pengguna tidak perlu memindahkan XRP, mengubah kunci dompet, atau membuat akun baru karena masalah manifest ini. Bursa, kustodian, back end dompet, penyedia data, dan bisnis yang menjalankan server XRPL mereka sendiri harus memeriksa versi node dan status restart mereka.
Operasi XRP Ledger mengatakan bahwa "post-mortem" teknis akan segera menyusul. Hingga 2 Agustus, proyek tersebut belum memublikasikan laporan itu, sehingga identitas pengirim, volume manifest yang ditransmisikan, dan penggunaan sumber daya yang tepat di seluruh node yang terpengaruh masih dirahasiakan.
Laporan itu juga harus menjelaskan kapan para pengembang pertama kali mendeteksi aktivitas tersebut, apakah ada node yang menjadi tidak tersedia dan seberapa cepat operator mengadopsi versi 3.2.1. Meskipun ledger terus ditutup, adopsi patch yang lambat dapat membuat server individual terpapar banjir ulang bahkan ketika ledger bersama tetap beroperasi.
Hotfix ini tiba tak lama setelah peluncuran XRPL versi 3.2.0 yang lebih besar. Rilis itu, yang dikeluarkan pada 15 Juni, mengganti nama server referensi dari rippled menjadi xrpld dan memperkenalkan perubahan infrastruktur yang mengharuskan operator untuk memperbarui konfigurasi perangkat lunak dan layanan.
Seperti yang dilaporkan sebelumnya, versi 3.2.0 awalnya menyebar lebih cepat di antara validator daripada di seluruh jaringan node yang lebih luas. Banjir manifest menambahkan alasan baru bagi operator yang tersisa untuk beralih dari rilis tersebut dan menginstal hotfix.
Sementara itu, dalam liputan terkait, David Schwartz memindahkan infrastruktur XRPL-nya ke versi 3.2.0 saat para pengembang menyiapkan jaringan untuk fitur penamaan server dan protokol baru. Sebelumnya, seperti yang dilaporkan crypto.news, operator node juga menghadapi tenggat waktu versi 3.1.3 yang terkait dengan aktivasi amandemen.
Pembaruan terverifikasi berikutnya adalah post-mortem yang dijanjikan dan data adopsi perangkat lunak yang baru. Hingga saat itu, respons yang terkonfirmasi tetap terbatas pada rilis 3.2.1, empat kontrol manifest-nya, dan permintaan agar operator menyelesaikan proses peningkatan dan restart.
