이 글은 비트코인 분야의 독학 교육자이자 기술 중심의 비트코인 팟캐스트 호스트인 신오비의 의견 기고입니다.
약 한 달 만에 두 번째로 btcd/LND에서 버그가 악용되어 비트코인 코어와의 합의에서 벗어났습니다. 다시 한 번, 이 취약점을 유발한 개발자는 부락이었으며 — 이번에는 명백히 의도적이었습니다 — 그리고 다시 한 번, 이는 합의 계층 위에서 비트코인 거래를 파싱하는 코드의 문제였습니다. 제가 이전에 부락이 유발한 버그에 대해 논의했듯이, 탭루트 이전에는 거래의 스크립트와 증인 데이터의 크기에 제한이 있었습니다. 탭루트가 활성화되면서 이러한 제한이 제거되어 개별 거래의 이러한 부분을 제한하는 것은 블록 크기 제한만 남게 되었습니다. 마지막 버그의 문제는 btcd의 합의 코드가 이 변화를 반영하도록 제대로 업그레이드되었음에도 불구하고, 피어 투 피어 전송을 처리하는 코드 — 즉, 전송 전에 데이터를 파싱하거나 수신할 때 — 제대로 업그레이드되지 않았다는 것입니다. 그래서 블록과 거래를 처리하는 코드는 실제로 합의를 위해 검증되도록 전달되기 전에 데이터를 실패시켰고, 해당 블록은 결코 검증되지 못했습니다.
이번에도 매우 유사한 일이 발생했습니다. 코드베이스의 피어 투 피어 섹션에서 또 다른 제한이 증인 데이터를 잘못 제한하여 블록 크기의 최대 1/8로 제한했습니다. 부락은 엄격한 제한을 단 한 단위 초과하는 증인 데이터로 거래를 작성했고, 다시 한 번 btcd와 LND 노드를 해당 블록 높이에서 멈추게 했습니다. 이 거래는 비표준 거래로, 합의 규칙에 따라 완전히 유효하지만 기본 메모리 풀 정책에 따라 유효하지 않기 때문에 노드가 네트워크를 통해 이를 중계하지 않습니다. 블록에 채굴되는 것은 완전히 가능하지만, 그렇게 하려면 직접 채굴자에게 제공해야 하며, 부락은 F2Pool의 도움으로 그렇게 했습니다.
이것은 비트코인 데이터를 파싱하고 검증하는 목적의 모든 코드 조각은 비트코인 코어가 수행하는 것과 일치하도록 철저히 감사받아야 한다는 점을 강조합니다. 그 코드가 노드 구현을 위한 합의 엔진이든 라이트닝 노드를 위한 거래를 전달하는 코드 조각이든 상관없습니다. 이 두 번째 버그는 코드베이스에서 지난 달의 버그 바로 위에 있었습니다. 라이트닝 연구소의 누구도 이를 발견하지 못했습니다. AJ 타운스는 부락의 998-of-999 멀티시그 거래로 인해 원래 버그가 발생한 후 이틀 뒤인 10월 11일에 이를 보고했습니다. 10시간 동안 깃허브에 공개 게시된 후 삭제되었습니다. 이후 수정이 이루어졌지만 공개되지 않았으며, 다음 LND 릴리스에서 조용히 패치할 의도로 진행되었습니다.
이것은 비트코인 코어와 같은 프로젝트에서 심각한 취약점에 대한 표준 절차입니다. 하지만 이 특정 경우에는 LND 사용자 자금에 심각한 위험을 초래했으며, 이전 버그와 동일한 위험이 있는 바로 옆에 있었기 때문에 발견되고 악용될 가능성이 매우 높았습니다. 이는 사용자 자금의 도난에 노출될 수 있는 취약점에 대해 조용히 패치하는 접근 방식이 올바른 방법인지에 대한 질문을 제기합니다.
제가 이전 버그에 대해 논의했듯이, 악의적인 행위자가 선의의 개발자보다 먼저 버그를 발견했다면, 그들은 취약한 노드에 새로운 채널을 전술적으로 열고, 해당 채널의 전체 내용을 자신에게 라우팅한 다음 버그를 악용했을 것입니다. 그렇게 되면 그들은 자금을 통제하게 되고 초기 상태로 채널을 닫을 수 있어, 사실상 돈을 두 배로 늘릴 수 있었습니다. 부락이 이 문제를 적극적으로 악용한 것은 아이러니하게도 LND 사용자를 그러한 공격으로부터 보호했습니다.
일단 악용되면, 사용자들은 이미 열린 채널을 가진 기존 피어로부터 그러한 공격에 노출되었지만, 더 이상 새로운 채널로 특정하게 목표가 될 수 없었습니다. 그들의 노드는 멈추었고, 누군가가 그들의 노드를 멈춘 블록 이후에 열려고 시도한 채널을 통해 결제를 인식하거나 처리할 수 없었습니다. 따라서 사용자가 악용당할 위험을 완전히 제거하지는 않았지만, 그 위험을 이미 채널을 가진 사람들로 제한했습니다. 부락의 행동이 이를 완화시켰습니다. 개인적으로 저는 버그에 대한 이러한 대응이 합리적이라고 생각합니다. 이는 피해를 제한하고 사용자에게 위험을 인식하게 하며 빠르게 패치되도록 했습니다.
LND만 영향을 받은 것은 아닙니다. 리퀴드의 페깅 프로세스도 깨져서 연합의 기능자들에게 수정을 요구했습니다. 오래된 버전의 러스트 비트코인도 영향을 받았으며, 이로 인해 일부 블록 탐색기와 electrs 인스턴스(일렉트럼 지갑의 백엔드 서버 구현)에 영향을 미쳤습니다. 이제 리퀴드의 페그가 결국 블록스트림이 보유한 긴급 복구 키에 자금을 노출시킨 것을 제외하고는 — 그리고 현실적으로 블록스트림이 이러한 자금을 훔친 강도 스타일의 영화 플롯에서, 모두가 정확히 누구를 추적해야 할지 알고 있습니다 — 이러한 다른 문제들은 어느 시점에서도 누구의 자금을 위험에 빠뜨리지 않았습니다. 또한 러스트 비트코인은 실제로 최신 버전에서 이 특정 버그를 패치했으며, 이는 다른 코드베이스의 유지 관리자와 이러한 문제의 잠재력을 강조하기 위한 커뮤니케이션으로 이어지지 않았습니다. 네트워크에서 버그가 적극적으로 악용되었을 때만 이 문제가 여러 코드베이스에 존재한다는 것이 널리 드러났습니다.
이것은 비트코인에서 레이어 2 소프트웨어의 취약점과 관련하여 몇 가지 큰 문제를 제기합니다. 첫째, 이러한 코드베이스가 보안 버그에 대해 얼마나 심각하게 감사받고 있으며, 새로운 기능의 통합과 비교하여 어떻게 우선시되는지입니다. 이 두 번째 버그가 존재했던 코드베이스의 유지 관리자가 발견하지 못했음에도 불구하고, 이는 매우 주목할 만한 일입니다. 사용자의 자금을 위험에 빠뜨린 주요 버그가 발생한 후, 해당 코드베이스에 대한 내부 감사가 이루어지지 않았습니까? 프로젝트 외부의 누군가가 이를 발견해야 했습니까? 이는 사용자 자금을 보호하는 것보다 더 많은 사용자를 끌어들이기 위한 새로운 기능 구축을 우선시하는 것을 보여줍니다. 둘째, 이 문제가 러스트 비트코인에서 이미 패치되었다는 사실은 이러한 버그에 대한 서로 다른 코드베이스의 유지 관리자 간의 커뮤니케이션 부족을 보여줍니다. 이는 이해할 수 있는 일입니다. 완전히 다른 코드베이스가 존재하기 때문에, 한 코드베이스에서 버그를 발견한 사람이 즉시 “나는 다른 프로그래밍 언어로 유사한 소프트웨어를 작성하는 다른 팀에 연락하여 이러한 버그의 잠재력에 대해 경고해야겠다”라고 생각하지는 않습니다. 윈도우에서 버그를 발견했다고 해서 리눅스 커널 유지 관리자에게 즉시 보고할 생각을 하지 않게 됩니다. 그러나 비트코인은 전 세계 네트워크에서 분산 합의를 위한 프로토콜로서 매우 다른 존재입니다. 아마도 비트코인 개발자들은 비트코인 소프트웨어의 취약점에 대해 이러한 관점에서 생각하기 시작해야 할 것입니다. 특히 합의와 관련된 데이터를 파싱하고 해석하는 것과 관련하여.
마지막으로, 블록체인을 항상 관찰해야 하며, 구 채널 상태에 반응하여 보안을 유지해야 하는 라이트닝과 같은 프로토콜의 경우, 독립적인 데이터 파싱 및 검증은 절대 최소로 유지되어야 하며 — 완전히 제거하고 비트코인 코어 또는 그로부터 직접 파생된 데이터에 위임해야 할 수도 있습니다. 코어 라이트닝은 이러한 방식으로 설계되어 있으며, 비트코인 코어 인스턴스에 연결하고 블록과 거래의 검증을 전적으로 의존합니다. LND가 동일한 방식으로 작동했다면, btcd의 이러한 버그가 LND 사용자 자금을 위험에 빠뜨리는 방식으로 영향을 미치지 않았을 것입니다.
어떤 방식으로든 처리되든 — 검증을 완전히 외주화하거나 내부 검증을 단순히 최소화하고 훨씬 더 신중하게 접근하든 — 이 사건은 레이어 2 소프트웨어가 합의 관련 데이터와 상호 작용하는 방식을 다루는 데 있어 변화가 필요하다는 것을 보여줍니다. 다시 한 번, 모두가 악의적인 행위자에 의해 악용되지 않고, 오히려 포인트를 증명하는 개발자에 의해 악용된 것에 대해 매우 운이 좋았습니다. 그렇다고 해서 비트코인은 운에 의존하거나 악의적인 행위자가 존재하지 않기를 바랄 수 없습니다.
개발자와 사용자는 이러한 사건이 다시 발생하지 않도록 프로세스를 개선하는 데 집중해야 하며, 핫 포테이토처럼 비난을 주고받는 게임을 해서는 안 됩니다.
이 글은 신오비의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며 BTC Inc 또는 비트코인 매거진의 의견을 반드시 반영하지는 않습니다.
