Home / Knowledge / 핵심 문제: 비트코인 코어의 보안 유지

핵심 문제: 비트코인 코어의 보안 유지

비트코인 코어는 2조 달러 이상의 가치를 보호하는 통화 네트워크의 중추 역할을 합니다. 위험이 막대하며, 코드베이스의 큰 부분은 높은 영향력을 미치는 버그를 숨길 수 있습니다. 합의 엔진, 피어 투 피어(p2p) 메시지 처리 코드 및 암호화 라이브러리는 취약점이 도난을 가능하게 하거나 네트워크를 중단시키거나 시스템에 대한 신뢰를 근본적으로 저해할 수 있는 영역입니다. 전통적인 금융 소프트웨어가 보험 및 법적 구제책에 의해 뒷받침되는 것과 달리, 비트코인의 보안은 코드의 품질과 그 품질을 유지하는 프로세스에 전적으로 의존합니다.

비트코인 코어의 보안 접근 방식은 공식적으로 정의되어 있지 않지만, 시간이 지남에 따라 개선된 진화하는 일련의 관행입니다. 검토 프로세스는 더 철저해졌고, 테스트 인프라는 크게 확장되었으며, 프로젝트 전체가 소프트웨어 변경에 대해 더 보수적이고 신중해졌습니다. 이러한 느린 속도 자체가 보안 조치로 작용하여 성급한 수정으로 인한 새로운 버그 도입의 위험을 줄입니다.

이 글에서는 비트코인 코어가 보안에 접근하는 몇 가지 주요 측면을 살펴봅니다:

발견된 취약점을 처리하기 위한 공개 정책
버그를 찾기 위한 광범위한 퍼징 인프라
프로덕션에 도달하기 전에 문제를 포착하는 더 넓은 테스트 도구 모음

이러한 관행은 함께 작용하지만, 통합된 전략이 아니라 프로젝트가 성숙해짐에 따라 발전한 보완적인 방어층으로 작용합니다.

취약점 공개 프로세스

비트코인 코어는 사용자에 대한 개발자 보호 조치로서 배포하는 소프트웨어에 대한 자동 업데이트 기능을 제공하지 않으며, 모든 릴리스된 바이너리는 재현 가능한 빌드를 통해 공개된 소스 코드와 일치하는지 확인할 수 있습니다. 노드 운영자는 어떤 버전의 소프트웨어를 실행할지 및 언제 업그레이드할지를 결정할 책임이 있습니다. 보안 취약점의 맥락에서 이는 심각한 딜레마를 제시합니다. 수정 사항은 릴리스가 이루어지기 전에 검토 프로세스를 위해 오픈 소스여야 하지만, 취약점의 세부 사항이 공개되면 공격자가 이를 악용할 수 있기 때문에 사용자가 합리적인 시간 내에 업데이트할 수 있도록 전체 공개는 지연되어야 합니다.

역사적으로, 프로젝트의 보안에 중요한 취약점에 대한 공개는 외부에서 보고되었거나 기여자에 의해 발견된 경우 모두 불충분했습니다. 이로 인해 많은 사용자가 비트코인 코어에 버그가 없다고 인식하게 되었으며, 이는 위험하고 부정확한 인식입니다. 약 1년 반 전, 이러한 문제에 의해 동기 부여를 받아 프로젝트는 보안 문제 처리 방식을 포괄적인 공개 정책 및 자문 프로세스로 수정하고 공식화했습니다. 목표는 더 많은 투명성을 제공하고, 보안 연구자에 대한 명확한 기대치를 설정하며(취약점을 발견하고 책임감 있게 공개할 수 있는 인센티브 제공), 구버전을 실행할 때의 위험을 더 잘 전달하고, 공개 후 더 넓은 기여자 그룹이 보안 버그를 이용할 수 있도록 하여 향후 문제를 학습하고 예방하는 것이었습니다.

정책

모든 취약점은 [email protected]에 보고되어야 합니다(자세한 내용은 SECURITY.md 참조). 보고되면 취약점은 심각도 범주가 지정됩니다. 우리는 4가지 취약점 클래스를 구분합니다:

치명적: 비트코인 네트워크의 기본 보안 및 무결성을 위협하는 버그입니다. 이러한 버그는 프로토콜 수준에서 코인 도난, 지정된 발행 일정 외부에서의 코인 생성 또는 영구적인 네트워크 전반의 체인 분할을 허용합니다.

높음: 영향을 받는 노드 또는 네트워크에 상당한 영향을 미치는 버그입니다. 일반적으로 기본 구성에서 원격으로 악용될 수 있으며 광범위한 중단을 초래할 수 있습니다.

중간: 네트워크 또는 노드의 성능이나 기능을 눈에 띄게 저하시킬 수 있는 버그지만, 범위나 악용 가능성이 제한적입니다. 이러한 버그는 비기본 설정과 같은 특별한 조건이 필요할 수 있으며, 완전한 노드 실패보다는 서비스 저하를 초래할 수 있습니다.

낮음: 악용하기 어려운 버그이거나 노드의 작동에 미치는 영향이 미미한 버그입니다. 비기본 구성이나 로컬 네트워크에서만 트리거될 수 있으며, 즉각적이거나 광범위한 위협을 초래하지 않습니다.

낮음 심각도 취약점은 수정 사항이 포함된 주요 버전 릴리스 후 2주 후에 공개됩니다. 중간 및 높음 심각도 취약점은 마지막 영향을 받는 릴리스가 생명 종료(수정 사항이 포함된 주요 버전이 처음 릴리스된 후 약 1년)된 후 2주 후에 공개됩니다.

취약점의 세부 사항을 공개하기 2주 전에 사전 발표가 이루어집니다. 이 사전 발표는 새로운 주요 버전의 릴리스와 동시에 이루어지며, 수정된 취약점의 수와 그 심각도 수준을 포함합니다.

치명적 버그는 표준 정책에서 고려되지 않으며, 이는 대부분 즉흥적인 절차가 필요할 것입니다. 또한, 버그가 전혀 취약점으로 간주되지 않을 수도 있습니다. 보고된 문제는 심각하다고 간주될 수 있지만, 금지가 필요하지 않을 수도 있습니다.

취약점이 프로젝트에 보고되면, 먼저 비트코인 코어의 “보안 팀”에 의해 검증되고 평가됩니다. 이 팀은 보안 버그를 발견하거나 수정한 경험이 있는 장기 기여자로 구성된 소규모 그룹입니다. 프로젝트는 취약점을 네 가지 심각도 수준으로 분류합니다: 치명적(코인 도난 또는 인플레이션과 같은 네트워크 무결성에 대한 위협), 높음(상당한 영향, 원격 악용 가능), 중간(성능 저하 또는 제한된 범위), 낮음(악용하기 어려운 미미한 영향). 심각한 것으로 확인되면, 수정 사항이 개발되고 철저하게 비공식적으로 테스트됩니다. 그런 다음 수정 사항은 다른 코드 변경과 마찬가지로 풀 리퀘스트로 제출되지만, PR 설명 및 논의는 수정의 진정한 성격을 흐리게 합니다. 이는 리팩토링, 성능 개선 또는 잠재적인 문제에 대한 강화로 설명될 수 있습니다. 이를 통해 수정 사항은 취약점 세부 정보를 비공식적으로 유지하면서 정상적인 코드 검토를 거칠 수 있습니다.

이 접근 방식은 실제 거래를 포함하며, 유지하는 것이 진정으로 어려운 균형 잡기입니다. 비평가들은 이것이 부성적이라고 주장할 수 있으며, 대중에게 공개되기 전에 취약점에 대해 아는 몇몇 개발자에게 너무 많은 권력이 집중된다고 주장할 수 있습니다. 이러한 우려는 진지하게 고려할 가치가 있지만, 즉각적인 공개의 대안은 재앙적일 수 있습니다. 대부분의 사용자가 업데이트하기 전에 취약점 세부 사항을 공개하는 것은 공격자에게 목표 목록(업데이트되지 않은 노드)과 무기(악용 코드)를 모두 제공하는 것입니다.

퍼징 인프라

퍼징은 소프트웨어에 무작위, 잘못된 형식 또는 예기치 않은 입력을 제공하여 버그를 찾는 테스트 기술입니다. 기본적으로 테스트 케이스를 지속적으로 생성하고 변형하여 프로그램에 제공하고, 충돌, 멈춤, 논리 버그 등과 같은 예기치 않은 동작을 관찰합니다. 현대의 퍼저는 진화 알고리즘을 사용하여 어떤 입력이 흥미로운 코드 경로를 유도하는지 학습한 다음, 이러한 입력을 변형하여 프로그램을 더 깊이 탐색합니다. 이는 수동 테스트나 코드 검토를 통해 발견하기 거의 불가능한 엣지 케이스 버그를 찾는 효과적인 방법입니다.

퍼저가 이 테스트를 위한 입력을 제공하기 때문에 개발자는 예상 결과를 직접 주장할 수 없습니다(예: 입력 A는 출력 B를 생성해야 함). 대신, 그들은 소프트웨어가 유지해야 하는 일반적인 속성에 대해 주장을 합니다. 이는 매우 가치가 있으며, 노드가 충돌하지 않도록 방지하거나 코인 공급이 예상 이상으로 인플레되지 않도록 보장하는 등의 속성을 테스트함으로써 원하는 동작에 대한 더 넓은 신뢰를 구축할 수 있게 해줍니다.

정확성, 강건성 및 보안의 중요한 필요성으로 인해 비트코인 코어는 다양한 접근 방식으로 퍼징을 광범위하게 활용합니다. 비트코인 코어의 역사 전반에 걸쳐 퍼징 테스트 노력은 증가해왔습니다. 매우 원시적인 퍼징의 최초 언급은 2012년으로 거슬러 올라가며, 간단한 퍼징 프레임워크의 통합은 2016년에 이루어졌고, 이는 현재 200개 이상의 개별 퍼징 테스트를 포함하는 포괄적인 프레임워크로 발전했습니다. 이 프레임워크는 코드베이스의 중요한 개별 구성 요소 및 기능을 다룹니다.

표준 단위 테스트와 달리, 퍼징 테스트는 정의된 “통과” 지점이 없습니다. 즉, 한 번 실행하고 “통과” 또는 “실패” 상태를 반환하지 않습니다. 퍼징은 지속적인 무작위 프로세스이기 때문에 결과에 대한 어떤 진술(결함이 발견되지 않았을 때)도 확률적일 수밖에 없습니다. 퍼징 테스트는 5000시간 동안 버그를 발견하지 못할 수 있지만, 다음 5000시간 동안에는 하나를 발견할 수 있습니다. 따라서 효과적이기 위해서는 퍼징 테스트를 지속적으로 실행해야 합니다. 비트코인 코어는 구글의 oss-fuzz 인프라를 활용하여 퍼징 테스트를 실행하지만, 여러 기여자가 자신의 설정으로 지속적으로 퍼징을 수행하는 데에도 많은 투자를 하고 있습니다. 예를 들어, 브링크의 인프라만으로도 비트코인 코어의 퍼징에 연간 100만 CPU 시간을 제공합니다.

비트코인 코어 리포지토리에는 구성 요소/기능 수준에서 수많은 퍼징 테스트가 있지만, 여러 외부 프로젝트는 독특한 퍼징 전략을 사용합니다. 크립토퍼즈(Cryptofuzz)는 이제 은퇴했지만, libsecp256k1 및 기타 암호화 코드의 차등 퍼징에 중점을 두었습니다. 직렬화 원시 데이터, 합의 논리 및 지갑 설명 구문 분석과 같은 비암호화 코드의 경우, 프로젝트 비트코인퍼즈(bitcoinfuzz)는 비트코인 특화 차등 퍼징 접근 방식을 사용합니다. 시스템 수준에서 버그를 발견하기 위한 전체 시스템 퍼징 방법론도 Fuzzamoto와 함께 개발 중이며, 이는 코드베이스의 서로 다른 부분 간의 복잡한 상호작용에서 발생하는 버그를 찾는 것을 주로 목표로 합니다.

수백 개, 아니 수천 개의 버그가 출시된 비트코인 코어 버전이나 풀 리퀘스트에서 퍼징을 통해 발견되었습니다(물론 그 중 모든 것이 보안 관련은 아닙니다), 이는 퍼징의 효과성과 중요성을 강조합니다. 최근에 발표된 높은 심각도의 예는 CVE-2024-35202로, 퍼징을 통해 발견된 원격 접근 가능한 충돌 버그로, 공격자가 모든 공개적으로 접근 가능한 노드를 충돌시킬 수 있게 했을 것입니다. 이 발견은 컴팩트 블록 릴레이 논리를 리팩토링하고 이를 독립적이고 테스트 가능한 모듈로 추출하며, 이를 위한 퍼징 테스트를 작성하는 과정을 포함했습니다.

품질 보증

퍼징이 위에서 강조되었지만, 프로젝트는 매일 다양한 추가 테스트 방법론을 사용하여 프로덕션 코드에 문제가 도달할 위험을 더욱 최소화합니다.

비트코인 코어는 수백 개의 단위 테스트를 보유하고 있습니다. 이러한 테스트는 개별 함수나 클래스와 같은 작고 고립된 코드 조각의 예상 동작을 검증하기 위해 설계되었습니다. 예를 들어, 단위 테스트는 작업 증명 검증 함수의 동작을 검증하는 데 사용됩니다. 이러한 테스트는 함수에 엣지 케이스 입력을 제공하고 결과 출력이 기대에 부합하는지를 테스트합니다.

반면 기능 테스트는 하나 이상의 비트코인 코어 인스턴스를 전체적으로 테스트하여 소프트웨어의 외부 인터페이스(예: RPC, p2p 메시지)를 사용하여 잠재적인 실제 시나리오를 시뮬레이션합니다. 예를 들어, 이러한 테스트는 작은 노드 네트워크를 생성하고 그 중 하나에 트랜잭션을 제출한 다음(예: 지갑 RPC를 사용하여) 테스트에서 모든 노드가 트랜잭션을 관찰하고 수용하는지를 검증할 수 있습니다. 비트코인 코어는 역사적으로 상당한 코드 모듈성을 결여하고 있으며, 이는 여러 영역에서 지속되고 있습니다. 따라서 프로젝트는 종종 테스트를 위해 목표 코드를 독립적으로 격리하기 위해 사전에 코드를 리팩토링해야 하므로 기능 테스트 접근 방식에 더 의존하고 있습니다.

각 테스트 방법론은 장단점이 있습니다. 단위 테스트는 일반적으로 실행 속도가 빠르고 버그가 위치한 곳을 정확히 지적하는 데 유용합니다. 그러나 정의상 여러 단위의 상호작용에서만 나타나는 버그는 감지하지 못합니다. 기능 테스트는 전체 시스템을 테스트하므로 이러한 점에서 빛을 발하지만, 실행 속도 측면에서는 비용이 발생합니다. 각 테스트 실행 시 노드 인스턴스를 설정하고 해체해야 하기 때문입니다. 또한 버그가 위치한 곳을 개발자에게 지시하는 데는 훨씬 더 나쁩니다. 위의 예를 살펴보면, 트랜잭션 전파 테스트가 실패하면(즉, 트랜잭션이 모든 노드에 전파되지 않았을 경우) 시스템의 어떤 구성 요소가 버그가 있는지 파악하기가 더 어렵습니다. 이는 메모리풀 수용 논리, 네트워킹 코드, 트랜잭션을 생성하는 데 사용된 RPC 또는 관련된 다른 구성 요소의 버그일 수 있습니다. 어떤 단일 방법이 가장 좋은 것은 아니며, 모든 방법론의 조합이 소프트웨어가 올바르게 작동할 가능성이 가장 높은 조각을 형성합니다.

모든 테스트는 CI 내에서 모든 PR 및 마스터 브랜치에 대한 모든 푸시에서 실행됩니다. 모든 단위, 기능 및 퍼징 테스트(이전 생성된 입력을 실행)는 다양한 호스트 운영 체제, CPU 아키텍처 및 메모리 안전 및 정의되지 않은 동작과 관련된 일반적인 C++ 버그 클래스를 포착하기 위한 세니타이저(주소, 스레드, 정의되지 않음, 메모리) 및 발그라인드와 같은 다양한 버그 탐지 메커니즘을 통해 실행됩니다.

비트코인 코어는 사토시가 출시한 원래 클라이언트에서 점진적으로 발전해왔으며, 기여자들이 시간이 지남에 따라 오가면서 많은 레거시 코드를 포함하고 있습니다. 기존 코드를 리팩토링하여 단순화하고 격리하는 것은 프로젝트에서 수행되는 작업의 큰 부분이었습니다. 커널, 새로운 p2p 기능, 성능 개선 또는 더 많은 테스트를 배치하기 위한 준비 등 모든 작업에는 리팩토링이 필요합니다. 그러나 리팩토링 시기와 방법에 대한 의견은 분분하며, 이는 양날의 검이 될 수 있습니다. 리팩토링은 관련된 사람들에게 맥락을 새롭게 하고 버그를 발견하며 일반적으로 더 많은 테스트를 가능하게 하지만, 더 이상 이해되지 않는 코드를 건드리는 것은 두려울 수 있으며 새로운 버그가 도입될 수도 있습니다. 기능 테스트 및 시스템 수준의 다른 테스트 전략(위에서 언급한 퍼징 섹션의 Fuzzamoto와 같은)은 리팩토링 노력을 위험을 줄이는 방법이며, 해당 레이어의 테스트는 사전 리팩토링이 거의 필요하지 않습니다.

주요 릴리스 이전에, 추가 테스트 전략으로서 프로젝트는 사용자, 개발자 및 커뮤니티 전체가 기존 및 새로운 기능을 수동으로 테스트할 수 있도록 테스트 가이드를 작성합니다. 소프트웨어를 일반적인 사용으로 테스트하는 것이 일반적으로 권장되며, 이는 개별 사용자의 정상적인 작업 흐름이 기능을 유지하는지 확인하기 위한 행동 촉구입니다.