이것은 비트코인 공간의 독학 교육자이자 기술 지향적인 비트코인 팟캐스트 호스트인 Shinobi의 의견 사설입니다.
약 한 달 만에 두 번째로 btcd/LND에서 버그가 악용되어 비트코인 코어의 합의에서 벗어나게 되었습니다. 이번에도 Burak은 이 취약점을 촉발한 개발자였으며(이번에는 분명히 의도적인 것이었습니다), 다시 한번 합의 계층 위의 비트코인 거래를 구문 분석하는 코드에 문제가 있었습니다. 내가 내에서 논의한대로 이전 버그에 대한 부분 Burak이 트리거한 것과 같이 Taproot 이전에는 트랜잭션의 스크립트 및 증인 데이터의 크기에 제한이 있었습니다. Taproot가 활성화되면서 이러한 제한은 제거되었으며 블록 크기 제한 자체에 대한 제한만 남아 개별 거래의 이러한 부분을 제한했습니다. 마지막 버그의 문제점은 이러한 변경 사항을 반영하기 위해 btcd의 합의 코드가 올바르게 업그레이드되었음에도 불구하고 전송 또는 수신 전 데이터 구문 분석을 포함하여 P2P 전송을 처리하는 코드가 제대로 업그레이드되지 않았다는 것입니다. 따라서 실제로 합의 검증을 위해 전달되기 전의 코드 처리 블록 및 트랜잭션은 데이터에 실패했으며 합의 검증 논리에 전달되지 않았으며 문제의 블록은 검증에 실패했습니다.
이번에도 아주 비슷한 일이 일어났습니다. 코드베이스의 P1P 섹션의 또 다른 제한은 감시 데이터에 대한 제한을 잘못 적용하여 전체 블록 크기가 아닌 블록 크기의 최대 8/XNUMX로 제한하는 것입니다. 부락이 만든 거래 증인 데이터를 사용하면 엄격한 제한을 초과하는 단일 가중치 단위가 발생하고 다시 한번 해당 블록 높이에서 btcd 및 LND 노드가 정지됩니다. 이 거래는 비표준 거래였습니다. 즉, 합의 규칙에 따르면 완벽하게 유효하더라도 기본 mempool 정책에 따르면 유효하지 않으므로 노드는 네트워크를 통해 이를 중계하지 않습니다. 블록으로 채굴하는 것은 완벽하게 가능하지만 그렇게 하는 유일한 방법은 채굴자에게 직접 제공하는 것입니다. 이것이 바로 Burak이 F2Pool의 도움으로 수행한 작업입니다.
이는 비트코인 데이터를 구문 분석하고 검증하는 것이 목적인 코드 조각이 비트코인 코어가 수행할 작업과 일치하는지 확인하기 위해 철저하게 감사해야 한다는 점을 실제로 강조합니다. 해당 코드가 노드 구현을 위한 합의 엔진인지 아니면 Lightning 노드에 대한 트랜잭션을 전달하는 코드 조각인지는 중요하지 않습니다. 이 두 번째 버그는 말 그대로 지난 달의 것 바로 위에 코드베이스에서. Lightning Labs의 누구도 발견하지 못했습니다. AJ Towns는 원래 버그가 Burak의 11/998 다중 서명 트랜잭션으로 인해 발생한 지 이틀 후인 999월 10일에 이를 보고했습니다. XNUMX시간 동안 Github에 공개적으로 게시된 후 삭제되었습니다. 그런 다음 LND의 다음 릴리스에서 문제를 조용히 패치할 의도로 수정이 이루어졌지만 릴리스되지는 않았습니다.
이제 이것은 심각한 취약점에 대한 매우 표준적인 절차입니다. 특히 이러한 취약점이 실제로 기본 계층 네트워크/프로토콜에 심각한 손상을 일으킬 수 있는 Bitcoin Core와 같은 프로젝트의 경우 더욱 그렇습니다. 하지만 이 특정한 경우에는 LND 사용자의 자금에 심각한 위험을 초래했으며 동일한 위험이 있는 이전 버그 바로 옆에 있다는 사실을 고려하면 발견되어 악용될 가능성이 매우 높았습니다. Burak이 보여준 것처럼. 이는 사용자를 자금 도난의 위험에 빠뜨릴 수 있는 이와 같은 취약점에 대해 자동 패치 접근 방식이 적합한지 여부에 대한 의문을 제기합니다(노드가 이전 채널 상태를 감지하고 적절하게 처벌할 수 없기 때문입니다).
마지막 버그에 대한 글을 쓰면서 악의적인 행위자가 선의의 개발자보다 먼저 버그를 발견했다면 전술적으로 취약한 노드에 새 채널을 열고 해당 채널의 전체 콘텐츠를 자신에게 다시 라우팅한 다음 버그를 악용했습니다. 거기에서 그들은 그 자금을 통제할 수 있게 되고 초기 상태로 채널을 폐쇄하여 말 그대로 돈을 두 배로 늘릴 수 있었습니다. Burak은 아이러니한 방식으로 이 문제를 적극적으로 이용하여 실제로 LND 사용자를 그러한 공격으로부터 보호했습니다.
일단 그것이 악용되면 사용자는 이미 공개 채널을 갖고 있는 기존 동료로부터 그러한 공격에 노출되었지만 더 이상 새로운 채널을 통해 특별히 표적이 될 수는 없었습니다. 그들의 노드는 정지되었으며 노드를 정지시킨 블록 이후 누군가가 열려고 시도한 채널을 통해 지불을 인식하거나 처리하지 못했습니다. 따라서 사용자가 악용될 위험을 완전히 제거하지는 못했지만 이미 채널을 갖고 있는 사람들에게만 해당 위험을 제한했습니다. Burak의 행동은 그것을 완화했습니다. 개인적으로 나는 버그에 대한 이러한 유형의 조치가 합리적이라고 생각합니다. 피해를 제한하고 사용자에게 위험을 인식하게 하여 신속하게 패치를 적용할 수 있게 되었습니다.
LND도 영향을 받은 유일한 것이 아니었습니다. 액체의 페깅 프로세스도 중단되었습니다., 문제를 해결하려면 연맹 임원의 업데이트가 필요합니다. Rust Bitcoin의 이전 버전 또한 영향을 받아 지연이 일부 블록 탐색기 및 선출자 인스턴스(Electrum Wallet의 백엔드 서버 구현)에 영향을 미쳤습니다. 이제 Liquid의 페그가 시간 잠금 만료 후 Blockstream이 보유한 비상 복구 키에 결국 자금을 노출시키는 것을 제외하고는 현실적으로 Blockstream이 이러한 자금을 훔친 강도 스타일의 영화 플롯에서 모두가 누구를 추적해야 할지 정확히 알고 있습니다. 문제는 어느 시점에서도 누구의 자금을 위험에 빠뜨리지 않습니다. 또한 Rust Bitcoin은 실제로 최신 버전에서 이 특정 버그를 패치했는데, 이는 분명히 그러한 문제의 가능성을 강조하기 위해 다른 코드베이스의 관리자와 어떤 의사소통으로도 이어지지 않았습니다. 문제가 여러 코드베이스에 존재한다는 사실을 널리 노출시킨 것은 네트워크에서 라이브로 버그를 적극적으로 악용하는 것이었습니다.
이는 비트코인의 레이어 2 소프트웨어에서 이와 같은 취약점과 관련하여 몇 가지 큰 문제를 야기합니다. 첫째, 보안 버그에 대해 이러한 코드베이스를 감사하는 심각성과 새로운 기능의 통합에 비해 우선순위가 어떻게 정해지는지입니다. 이 두 번째 버그는 말 그대로 지난 달에 발견된 초기 버그 바로 옆에 있었음에도 불구하고 이 두 번째 버그가 존재했던 코드베이스의 관리자조차 발견하지 못했다는 점을 고려하면 보안이 항상 우선순위가 아니라는 점은 매우 시사하는 바가 큽니다. 사용자의 자금을 위험에 빠뜨리는 주요 버그 이후 해당 코드베이스에 대한 내부 감사가 수행되지 않았습니까? 그것을 발견하기 위해 프로젝트 외부의 누군가가 필요했나요? 이는 더 많은 사용자를 끌어들이기 위해 새로운 기능을 구축하는 것보다 사용자의 자금을 보호하는 것이 우선 순위를 나타내지 않습니다. 둘째, 이 문제가 Rust Bitcoin에서 이미 패치되었다는 사실은 이와 같은 버그와 관련하여 다양한 코드베이스의 관리자 간의 의사소통이 부족하다는 것을 보여줍니다. 코드베이스가 완전히 다르다고 해서 버그를 발견한 사람이 즉시 "완전히 다른 프로그래밍 언어로 유사한 소프트웨어를 작성하는 다른 팀에 연락하여 그러한 버그의 가능성에 대해 경고해야 한다"고 생각하게 만드는 것은 아니기 때문에 이것은 꽤 이해할 수 있습니다. Windows에서 버그를 발견하지 못했다면 즉시 Linux 커널 관리자에게 버그를 보고할 생각을 하게 됩니다. 그러나 글로벌 네트워크 전반에 분산된 합의를 위한 프로토콜인 비트코인은 매우 다른 짐승입니다. 아마도 비트코인 개발자는 비트코인 소프트웨어의 취약점에 관해 이러한 관점에서 생각해야 할 것입니다. 특히 합의와 관련된 데이터를 구문 분석하고 해석하는 경우에는 더욱 그렇습니다.
마지막으로, 보안을 유지하기 위해 항상 블록체인을 관찰하여 이전 채널 상태에 반응할 수 있는 Lightning과 같은 프로토콜의 경우 데이터의 독립적인 구문 분석 및 확인을 최소한으로 유지해야 합니다. 완전히 제거되지 않고 비트코인 코어 또는 그로부터 직접 파생된 데이터에 위임되지 않습니다. Core Lightning은 이러한 방식으로 설계되어 Bitcoin Core 인스턴스에 연결하고 블록 및 트랜잭션 검증을 위해 전적으로 이에 의존합니다. LND가 동일한 방식으로 작동했다면 btcd의 이러한 버그 중 어느 것도 LND 사용자에게 자금을 위험에 빠뜨리는 방식으로 영향을 미치지 않았을 것입니다.
검증을 완전히 아웃소싱하거나 단순히 내부 검증을 최소화하고 훨씬 더 주의 깊게 접근하는 등 어떤 방식으로 처리하든 이 사건은 레이어 2 소프트웨어가 합의 관련 데이터와의 상호 작용을 처리하는 방법에 대한 문제에 접근하는 데 있어 무언가 변화가 필요하다는 것을 보여줍니다. 다시 한 번, 이것이 악의적인 행위자에 의해 악용된 것이 아니라 개발자가 이를 입증했다는 점에서 모두가 매우 운이 좋았습니다. 즉, 비트코인은 행운을 빌거나 악의적인 행위자가 존재하지 않기를 바랄 수는 없습니다.
개발자와 사용자는 이런 일이 다시 발생하지 않도록 프로세스 개선에 집중해야 할 것이지, 뜨거운 감자처럼 비난을 퍼붓는 게임을 해서는 안 됩니다.
Shinobi님의 게스트 게시물입니다. 표현된 의견은 전적으로 자신의 것이며 BTC Inc 또는 Bitcoin Magazine의 의견을 반드시 반영하는 것은 아닙니다.
