“Celah XRP selama sepuluh tahun” ramai diperbincangkan: patch sudah dirilis, yang benar-benar perlu dicermati adalah tiga perbedaan waktu ini
“XRP bisa dibuat begitu saja” terdengar seperti insiden yang sedang berlangsung. Mari luruskan waktunya: yang dipublikasikan pada 9 Oktober adalah pengungkapan celah keamanan; perbaikan pada mesin pembayaran sudah dirilis sebelumnya bersama xrpld 3.4.1. Pada 10 Oktober, GitHub juga memublikasikan kode sumber versi tersebut beserta petunjuk peningkatannya. Pengungkapan, perbaikan perangkat lunak, dan aktivasi aturan di mainnet menjawab pertanyaan yang berbeda.
Pertama, celah pada mesin pembayaran berdampak pada versi 3.4.0 dan yang lebih lama. Pada 22 September, peneliti melaporkannya melalui program bug bounty. Setelah mereproduksi masalah tersebut, tim menaikkan tingkat keparahannya, lalu merilis perbaikan pada 25 September. Investigasi resmi menduga masalah ini dapat ditelusuri ke kode dari 2015. Laporan itu menyatakan belum ditemukan bukti bahwa jaringan publik telah dieksploitasi. Ini adalah kesimpulan investigasi; hal itu tidak bisa diperluas menjadi klaim bahwa semua aktivitas di masa lalu telah terbukti bebas dari kejanggalan, apalagi langsung ditulis sebagai serangan penerbitan XRP tambahan yang sudah terjadi.
Kedua, laporan yang sama juga mencakup masalah validasi transaksi internal Batch. Saat aturan ini ditemukan, aturan tersebut belum diaktifkan di mainnet. Perbaikan lebih dulu disertakan dalam perangkat lunak, sementara fixBatchV1_2 baru diaktifkan di mainnet pada 9 Oktober; perbaikan mesin pembayaran langsung berlaku setelah node diperbarui. Mencampuradukkan kedua jalur perbaikan itu dengan mengatakan “semua celah baru ditutup pada 9 Oktober” akan menggambarkan periode risiko secara keliru.
Ketiga, pertimbangan pemegang aset biasa dan operator node tidak boleh dicampuradukkan. GitHub saat ini mewajibkan server ditingkatkan ke 3.4.1, dan menjelaskan bahwa versi lama telah diblokir oleh amendemen baru sehingga tidak dapat terus melakukan sinkronisasi dengan normal. Persyaratan peningkatan ini berlaku untuk perangkat lunak server, bukan berarti pemegang aset perlu memindahkan aset ke situs asing untuk “memperbaiki dompet”. Jika ada tautan yang memanfaatkan isu keamanan untuk meminta frasa pemulihan atau meminta otorisasi, periksa dulu melalui kanal resmi.
Pelajaran yang saya ambil dari kejadian ini adalah bahwa pertahanan keamanan tidak boleh hanya mengulang asumsi yang sama: jika perhitungan pembayaran bermasalah, lapisan pemeriksaan yang menggunakan asumsi aritmetika serupa juga bisa luput mendeteksinya. Karena itu, patch dan proses peninjauan ulang setelahnya patut terus dipantau. Kesimpulan ini berasal dari mekanisme pengungkapan tersebut dan bukan berarti menyimpulkan adanya celah pada protokol lain.
Saya akan terus memantau apakah pihak resmi memberikan hasil investigasi tambahan, perkembangan peningkatan node lama, dan peninjauan keamanan lanjutan. Hal-hal itu dapat mengubah penilaian terhadap risiko teknis; sementara itu, untuk menilai apakah harga akan terus naik, tetap diperlukan bukti dari transaksi dan dukungan permintaan. Celah keamanan yang telah diperbaiki tidak dengan sendirinya menjadi sinyal beli.
Sumber: Pengungkapan celah keamanan resmi XRPL pada 9 Oktober, catatan rilis XRPLF/rippled 3.4.1. Diverifikasi pada 10 Oktober pukul 22.36 waktu Beijing.
“XRP bisa dibuat begitu saja” terdengar seperti insiden yang sedang berlangsung. Mari luruskan waktunya: yang dipublikasikan pada 9 Oktober adalah pengungkapan celah keamanan; perbaikan pada mesin pembayaran sudah dirilis sebelumnya bersama xrpld 3.4.1. Pada 10 Oktober, GitHub juga memublikasikan kode sumber versi tersebut beserta petunjuk peningkatannya. Pengungkapan, perbaikan perangkat lunak, dan aktivasi aturan di mainnet menjawab pertanyaan yang berbeda.
Pertama, celah pada mesin pembayaran berdampak pada versi 3.4.0 dan yang lebih lama. Pada 22 September, peneliti melaporkannya melalui program bug bounty. Setelah mereproduksi masalah tersebut, tim menaikkan tingkat keparahannya, lalu merilis perbaikan pada 25 September. Investigasi resmi menduga masalah ini dapat ditelusuri ke kode dari 2015. Laporan itu menyatakan belum ditemukan bukti bahwa jaringan publik telah dieksploitasi. Ini adalah kesimpulan investigasi; hal itu tidak bisa diperluas menjadi klaim bahwa semua aktivitas di masa lalu telah terbukti bebas dari kejanggalan, apalagi langsung ditulis sebagai serangan penerbitan XRP tambahan yang sudah terjadi.
Kedua, laporan yang sama juga mencakup masalah validasi transaksi internal Batch. Saat aturan ini ditemukan, aturan tersebut belum diaktifkan di mainnet. Perbaikan lebih dulu disertakan dalam perangkat lunak, sementara fixBatchV1_2 baru diaktifkan di mainnet pada 9 Oktober; perbaikan mesin pembayaran langsung berlaku setelah node diperbarui. Mencampuradukkan kedua jalur perbaikan itu dengan mengatakan “semua celah baru ditutup pada 9 Oktober” akan menggambarkan periode risiko secara keliru.
Ketiga, pertimbangan pemegang aset biasa dan operator node tidak boleh dicampuradukkan. GitHub saat ini mewajibkan server ditingkatkan ke 3.4.1, dan menjelaskan bahwa versi lama telah diblokir oleh amendemen baru sehingga tidak dapat terus melakukan sinkronisasi dengan normal. Persyaratan peningkatan ini berlaku untuk perangkat lunak server, bukan berarti pemegang aset perlu memindahkan aset ke situs asing untuk “memperbaiki dompet”. Jika ada tautan yang memanfaatkan isu keamanan untuk meminta frasa pemulihan atau meminta otorisasi, periksa dulu melalui kanal resmi.
Pelajaran yang saya ambil dari kejadian ini adalah bahwa pertahanan keamanan tidak boleh hanya mengulang asumsi yang sama: jika perhitungan pembayaran bermasalah, lapisan pemeriksaan yang menggunakan asumsi aritmetika serupa juga bisa luput mendeteksinya. Karena itu, patch dan proses peninjauan ulang setelahnya patut terus dipantau. Kesimpulan ini berasal dari mekanisme pengungkapan tersebut dan bukan berarti menyimpulkan adanya celah pada protokol lain.
Saya akan terus memantau apakah pihak resmi memberikan hasil investigasi tambahan, perkembangan peningkatan node lama, dan peninjauan keamanan lanjutan. Hal-hal itu dapat mengubah penilaian terhadap risiko teknis; sementara itu, untuk menilai apakah harga akan terus naik, tetap diperlukan bukti dari transaksi dan dukungan permintaan. Celah keamanan yang telah diperbaiki tidak dengan sendirinya menjadi sinyal beli.
Sumber: Pengungkapan celah keamanan resmi XRPL pada 9 Oktober, catatan rilis XRPLF/rippled 3.4.1. Diverifikasi pada 10 Oktober pukul 22.36 waktu Beijing.