XRPL、メインネット前の重大な脆弱性を修正するも、クライアントアプリは依然としてリスクにさらされるという記事がBitcoinEthereumNews.comに掲載されました。
XRP Ledger（XRPL）のバリデータは、BatchV1_1を9月29日14:06:41 UTCに発動する条件付き経路に置き、セキュリティ上の危機一髪を、ネットワークの修正プロセスとその周辺ソフトウェアの生きたテストへと変えた。9月22日、xrpldashboardは35の信頼済みバリデータのうち30がこの修正を支持しており、表示されている28票の閾値を上回っていることを示した。過半数は9月15日に初めてオンチェーンに現れた。XRPLの修正ルールでは、支持は2週間にわたって80%を超え続けなければならない。80%以下に落ちると過半数期間は終了するため、発動日は依然として条件付きである。9月29日は、XRPLのバリデータプロセス、リファレンス実装、およびクライアントエコシステムが、危険なメインネット前の脆弱性を実用的なアトミックトランザクション基盤へと変換できるかを試す初の本番テストである。バリデータの防火壁はメインネット前に機能した 元のBatch修正はXRP Ledgerメインネットで発動されることはなかった。2月、研究者たちは修正がまだ投票段階にある間に重大な認可の脆弱性を発見し、バリデータはそれを否決するよう助言された。XRPL Labsの公式脆弱性開示は、資金は危険にさらされなかったと述べている。この脆弱性は、バッチを認可するアカウントをチェックするループに存在していた。コードが、新しく作成されたアカウントの署名者に出会い、その鍵がそのアカウントと一致した場合、残りの署名者の処理を続けずに直ちに成功を返していた。攻撃者は、その有効な署名者を最初に置き、その後、被害者のアカウントを認可すると称する偽造エントリを追加することができた。もし修正が発動されていたなら、チェックされていない被害者のトランザクションは、被害者の鍵なしで実行されていた可能性がある。XRPLの対応は2段階で行われた。バージョン3.1.1は、元のBatchおよびfixBatchInnerSigs修正を未サポートとしてマークし、それらの発動を阻止した。BatchV1_1は後にそれらを書き直された認可経路と追加の防御に置き換えた。この一件は、ソフトウェアリリースとプロトコル発動の境界で捉えられた失敗であった。XRPL Foundationの最終的なXLS-56仕様は現在…