XRPL, 메인넷 이전 치명적 결함 수정했지만 클라이언트 앱은 여전히 위험 게시물이 BitcoinEthereumNews.com에 게재되었습니다.
XRP 레저(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 레저 메인넷에서 활성화된 적이 없습니다. 2월에 연구자들은 수정안이 아직 투표 단계에 있을 때 치명적인 권한 부여 결함을 발견했고, 검증자들은 이를 반대 투표하도록 권고받았습니다. XRPL Labs의 공식 취약점 공개에 따르면 자금은 위험에 노출되지 않았습니다. 결함은 배치를 승인하는 계정을 확인하는 루프에 있었습니다. 코드가 새로 생성된 계정의 서명자를 만났을 때 그 키가 해당 계정과 일치하면, 나머지 서명자들을 계속 확인하지 않고 즉시 성공을 반환했습니다. 공격자는 그 유효한 서명자를 먼저 배치한 다음, 피해자 계정을 승인한다고 주장하는 위조된 항목을 추가할 수 있었습니다. 만약 수정안이 활성화되었다면, 확인되지 않은 피해자 트랜잭션이 피해자의 키 없이 실행될 수 있었습니다. XRPL의 대응은 두 단계로 이루어졌습니다. 버전 3.1.1은 원래의 Batch 및 fixBatchInnerSigs 수정안을 지원되지 않는 것으로 표시하여 활성화를 차단했습니다. 이후 BatchV1_1이 재작성된 권한 부여 경로와 추가 방어로 이들을 대체했습니다. 이 사건은 소프트웨어 릴리스와 프로토콜 활성화 사이의 경계에서 포착된 실패였습니다. XRPL 재단의 최종 XLS-56 사양은 이제…