XRP 레저의 긴급 보안 업데이트
XRP 레저 개발자들은 네트워크의 표준 2주 검증자 승인 프로세스를 기다리지 않고 중요한 프로토콜 수정을 배포한 비상 보안 결정을 방어하고 있습니다. 9월 25일에 발표된 이 긴급 업데이트는 공격자가 암호화폐의 의도된 공급 한도를 초과하여 사용 가능한 XRP를 생성할 수 있는 11년 된 취약점을 해결했습니다.
조사자들은 악용의 증거를 발견하지 못했지만, 위협을 제거하는 데 사용된 방법은 분산 네트워크가 비상 상황에 어떻게 대응해야 하는지에 대한 논란을 불러일으켰습니다.
정상적인 XRPL 거버넌스 프레임워크에 따르면, 거래 처리에 영향을 미치는 변경 사항은 활성화 전에 두 주 연속으로 80% 이상의 신뢰할 수 있는 검증자의 지지를 받아야 합니다. 그러나 9월 보안 패치는 다른 절차를 따랐습니다. 공식 취약점 보고서에 따르면, 수정 사항은 승인된 수정안을 통해 동시에 활성화되는 대신, xrpld 3.4.1로 업그레이드한 각 서버에서 즉시 효력을 발휘했습니다.
개발자들은 XRP 공급 취약점의 심각성이 정상적인 프로세스를 따르는 것이 너무 위험하다고 주장했습니다. 패치를 게시하면서 결함이 악용 가능한 상태로 남아 있는 동안 장기간 투표를 진행하는 것은 공격자에게 악용을 재현할 수 있는 충분한 정보를 제공할 수 있었습니다.
취약점의 원인과 대응
근본적인 문제는 결제 엔진의 정수 오버플로우와 관련이 있었습니다. 특별히 구성된 거래는 시스템이 발신자가 실제로 지불한 것보다 더 많은 XRP를 적립하게 할 수 있었고, 이는 새로운 토큰을 생성할 가능성이 있었습니다. 연구자들은 취약한 코드를 2015년으로 추적했지만, 공공 네트워크에서 악용된 증거는 발견하지 못했습니다.
이 결정은 기술적인 결과 없이 이루어진 것은 아닙니다. 일반적으로 수정안은 호환 가능한 서버에서 동시에 활성화되어 검증자들이 동일한 거래 규칙을 적용하도록 보장합니다. 그러나 긴급 업데이트는 업그레이드된 서버가 특정 악의적인 거래를 거부하는 임시 기간을 생성했으며, 이전 버전은 여전히 이를 수용할 수 있었습니다.
이 불일치는 공격자들이 충분한 검증자가 업그레이드하기 전에 취약점을 악용하려고 시도할 경우 원장 검증을 중단시킬 수 있었습니다.
그러나 신속한 배포로 인해 이러한 노출이 줄어들었습니다. 개발팀의 공개에 따르면, 기본 고유 노드 목록의 80% 이상의 운영자가 9월 25일까지 3.4.1 버전을 설치했습니다. 이 대응은 정상적인 수정 절차를 따르고 10월 9일에 활성화된 별도의 배치 보안 수정과는 달랐습니다.
네트워크 거버넌스와 향후 과제
이 사건은 심각한 네트워크 비상 상황에서 개발자와 검증자 운영자가 얼마나 많은 권한을 행사해야 하는지에 대한 질문을 불러일으켰습니다. 비판은 보안에 민감한 소스 코드가 공개되기 전에 소프트웨어의 임시 배포에 부분적으로 집중되었습니다. 지지자들은 공격자가 공개된 약점을 악용하지 않도록 즉각적인 조정이 필요했다고 주장합니다.
XRPL 재단은 운영자들이 업데이트를 설치하도록 강요당했다는 주장을 거부하며, 검증자들이 스스로 업그레이드 결정을 내렸다고 강조했습니다. 이 논란은 다가오는 XRPL 대출 업그레이드가 여전히 일반적인 투표 과정을 통해 진행되고 있다는 점에서 발생하고 있으며, 이는 일상적인 프로토콜 변경이 여전히 지속적인 검증자 지원을 요구함을 보여줍니다.
개발자들은 수정안을 우회하는 것은 예외적으로 심각한 보안 위협에만 남아 있어야 하며, 네트워크 거버넌스의 표준 대안이 되어서는 안 된다고 주장합니다. XRP 보유자들에게 즉각적인 우려는 해결되었습니다: 취약점이 패치되었고, 조사자들은 알려진 악용 사례가 없다고 보고했습니다. 장기적인 질문은 XRPL이 향후 중요한 위협에 신속하게 대응하면서 어떻게 분산된 의사 결정을 유지할 수 있을 것인가입니다.
