XRP Ledger 긴급 패치, 18조 5,000억 개 발행 가능했던 버그 차단

18조 5,000억 개 XRP 넘침 버그

공격 경로는 XRP Ledger의 거래소, 즉 분산형 오더북이었다. 공격자는 이 오더북에 특별히 조작된 가격의 매도 주문을 죄다 올려놓고, 결제 엔진의 회계 처리에서 오버플로를 유발할 수 있었다. 그 결과 장부가 만든 적 없는 XRP가 실제로 쓸 수 있는 형태로 나타나는 구조였다. 이론상 확보 가능한 물량은 약 18조 5,000억 개로, 네트워크의 유통량 상한 1,000억 개를 약 185배 웃돈다. 문제의 무게가 큰 이유는 이것이 화면 표시 오류가 아니라 완전히 사용 가능한 XRP였기 때문이다. 초과 발행이 실현됐다면 발행 한도는 사실상 무의미해졌을 것이다. 개발자들은 이 경로를 긴급 패치로 막았고, 패치는 9월 25일 xrpld 3.4.1로 배포됐다.

XRPL 재단의 취약점 공개 보고서는 결함의 출처를 BookStep으로 짚는다. 결제가 장부의 거래소를 경유할 때 매도 주문 가격을 집계하는 코드가 바로 BookStep이다. 특정 패턴으로 배열된 주문은 엔진을 오버플로시켜 XRPNotCreated 불변식을 무력화할 수 있었다. 이 불변식은 2017년에 작성된 장치로, 프로토콜의 규칙 밖에서 XRP가 새로 생겨나는 것을 막는 역할을 한다. 보안 회사 Veria는 이 경로를 실제로 재현했다. 조작된 토큰을 여러 지갑 주소로 연달아 옮기면서, 모든 계정을 장부의 계정별 잔고 상한 이하로 유지해 어느 한 계정에서도 불일치가 드러나지 않게 만든 것이다. Veria는 이론상 노출 규모를 약 940억 달러로 추산했다. 대응 일정도 촉박했다. 버그는 9월 22일 화요일에 확인됐고, 다음 날 수정 코드가 코드베이스에 병합됐으며, 패치 버전은 9월 25일 금요일에 xrpld 3.4.1로 출시됐다. 확인, 병합, 출시가 모두 4일 안에 이뤄진 셈이다. RippleX의 점검에서는 이 결함이 실제 네트워크에 사용된 흔적은 발견되지 않았다. 한편 일반적인 수정안 투표를 건너뛴 결정은 10월 12일 월요일, 긴급 패치 발표가 X(트위터)에 퍼지면서 다시 주목받았다.

검증자 투표를 건너뛴 이유

XRPL의 평상치 거버넌스에서 검증자는 새 규칙이 활성화되기 전 몇 주에 걸쳐 거래 처리 방식의 변경 사항을 투표한다. 네트워크가 한 번에 정합성 있게 전환하기 위한 절차다. 현재 파이프라인에 대기 중인 수정안들은 정확히 이 경로를 따른다. 이번 수정은 그렇지 않았다. 코드를 활성화 전에 공개하면 대부분의 서버가 여전히 취약한 소프트웨어를 돌리는 동안 공격자에게 작동 방법을 그대로 넘겨주는 꼴이 될 수 있었다. 그래서 개발자들은 패치를 직접 배포했고, 각 서버는 3.4.1로 업그레이드하는 시점에 효과를 적용했다.

예외적 조치에는 그만의 위험도 있었다. 배포 과정에서 버전이 다른 서버들이 같은 악용 거래를 서로 다르게 처리해, 네트워크가 장부에 대한 상충하는 시점을 갖게 될 수 있었다. 이 구간은 짧게 끝났다. Veria 집계 기준 9월 25일까지 신규 버전 검증자가 전체의 80%를 넘었다. 표준 절차를 따랐다면 2주의 대기가 필요했을 것이고, 그동안 네트워크가 노출된 상태로 공격자에게 기회를 줄 수 있었다는 점이 판단의 근거였다. 이 사건은 코드의 나이도 기록으로 남겼다. BookStep은 2015년부터, XRPNotCreated 불변식은 2017년부터 소프트웨어의 일부였다. 둘을 함께 깨는 조합이 발견되기까지 수년이 흘렀다는 뜻이다.

XRPL 재단의 공개 보고서는 오버플로 자체와 수정안 절차를 거치지 않은 배포 결정을 모두 다룬다. 보고서는 이번 조치를 장부 거버넌스의 새 템플릿이 아니라, 원래 공급량을 훌쩍 넘는 쓸 수 있는 XRP를 만들 수 있었던 위협에 대한 비상 대응으로 명확히 규정한다. 검증자들은 이번 달 별개의 프로토콜 사안도 검토 중이다. 10월 23일까지 PaymentBurn 위임 금지를 해제할지 여부가 그것이다.

열려 있는 거버넌스 질문

이 이야기의 핵심 문서는 공개 보고서이고, 보고서는 한계를 분명히 밝힌다. 실제로 발행된 토큰은 없으며, 18조 5,000억 개라는 수치는 악용이 도달했을 수 있는 범위를 재는 것일 뿐 실제 결과가 아니다. 우리의 판단은 이렇다. 상한이 지켜진 이유는 발행 한도가 특정인의 보관이 아니라 코드에 의해 강제되기 때문이다. 결함은 단 하나의 개인 키도 건드리지 않았고, XRP가 존재하는지 자체를 판정하는 회계 계층을 공격했다. 보고서가 열어둔 거래는 여기서 시작된다. 공급을 깨는 버그 앞에서의 긴급 패치는 정당화할 수 있지만, 더 가벼운 위협에도 우회가 반복된다면 장부 규칙에 무게를 부여하는 검증자 절차가 침식된다. 업그레이드는 9월 25일 기준 사실상 완료됐고, 악용 사례도 기록상 존재하지 않는다. 따라서 보유자가 지금 취할 별도 조치는 자료상 남아 있지 않다. 논쟁이 진행되는 동안 시장 측면은 XRP 기술적 분석에서 추적할 수 있고, 이런 종류의 공개 보고서를 읽는 방법은 블록체인 보안 감사 가이드에서 다룬다.