저자:옵테크
출처: https://bitcoinops.org/zh/newsletters/2024/07/05/
이 기사는 Bitcoin Optech 뉴스레터 #310의 뉴스 섹션에서 발췌한 것입니다. 번역은 "Optech 중국어 번역팀( BitcoinOptechCN )"에서 제공됩니다.
원본 기사는 0.21.0 이전의 Bitcoin Core 소프트웨어 버전에 영향을 미치는 최근 공개된 보안 취약점을 요약합니다. 독자가 사용 중인 소프트웨어 버전의 보안을 쉽게 확인할 수 있도록 취약점에 대한 설명을 수리 시간의 역순으로 재배열했습니다. 최신 버전을 사용하는 사용자는 읽어야 할 심각한 부분이 점점 줄어들고 있습니다.
우리는 소프트 포크 철학이 사용자에게 자신이 선호하는 합의 규칙을 자유롭게 선택할 수 있는 비트코인 개발 철학의 핵심 부분이라는 것을 잘 알고 있습니다. 따라서 이전 버전의 소프트웨어의 보안은 소프트 포크 없이 모든 사람이 방어해야 하는 것입니다. , 소프트 포크 철학과 그에 따른 자유는 공허한 이야기입니다. 그러나 다른 제품과 마찬가지로 소프트웨어에도 설계된 수명주기가 있습니다. 소프트웨어 제품이 지속 가능한 보안 유지 관리를 받을 수 있다고 기대하는 것은 비현실적입니다. 따라서 궁극적으로 전체 노드 운영자는 판단에 대한 책임을 져야 합니다. 즉, 소프트웨어를 사용하기 전에 소프트웨어의 보안을 평가하고 정보가 공개되면 평가를 업데이트해야 합니다.
0.21.0 이전 버전의 Bitcoin Core에 영향을 미치는 취약점 공개 : Antoine Poinsot는 Bitcoin-Dev 메일링 그룹에 거의 2년 동안 폐기된 Bitcoin Core 소프트웨어 버전에 영향을 미치는 10가지 취약점을 알리는 링크를 게시했습니다 . 우리는 공개 내용을 다음과 같이 요약합니다.
과도한 시간 조정으로 인한 네트워크 단편화 : 이전 버전의 비트코인 코어는 연결된 처음 200개의 피어가 보고한 시간에 따라 자체 시계가 왜곡되는 것을 허용했습니다. 이러한 코드는 70분 이하의 왜곡을 허용하도록 고안되었습니다. 모든 버전의 비트코인 코어 소프트웨어는 현지 시간보다 2시간 이상 늦은 타임스탬프가 있는 블록을 일시적으로 무시합니다. 두 가지 버그를 결합하면 공격자는 피해자의 시계를 2시간 이상 뒤로 설정하여 정확한 타임스탬프가 있는 블록을 무시할 수 있습니다. 이 취약점은 개발자 practiceswift에 의해 성실하게 공개되었으며 Bitcoin Core 0.21.0에서 수정되었습니다.
확인되지 않은 거래 검토 : 피어는 일반적으로 거래의 txid 또는 wtxid를 통해 새 거래를 발표합니다. 노드가 txid 또는 wtxid를 처음 볼 때 트랜잭션을 알리기 위해 첫 번째 피어로부터 완전한 트랜잭션을 요청합니다. 이 피어의 응답을 기다리는 동안 노드는 동일한 txid 또는 wtxid를 발표한 다른 피어도 추적합니다. 첫 번째 피어가 시간 초과될 때까지 응답하지 않으면 피어는 두 번째 피어에게 전체 트랜잭션을 요청합니다(다시 시간 초과되면 세 번째 피어로 이동하는 식입니다).
Bitcoin Core 0.21.0 이전에는 노드가 최대 50,000개의 요청만 추적했습니다. 따라서 첫 번째 피어 노드가 txid를 발표한 후 완전한 트랜잭션에 대한 응답 노드의 요청을 연기하고 노드의 다른 피어가 트랜잭션을 발표할 때까지 기다린 다음 다른 txid에 대한 50,000개의 공지를 보낼 수 있습니다. 가짜 TXID). 이렇게 하면 첫 번째 피어의 전체 트랜잭션에 대한 노드의 요청 시간이 초과되면 다른 피어로부터 전체 트랜잭션을 요청하지 않습니다. 공격자(첫 번째 피어)는 이 공격을 무기한 반복하여 노드가 이 트랜잭션의 영향을 받는 것을 영구적으로 방지할 수 있습니다. 확인되지 않은 거래에 대한 이러한 검열로 인해 거래가 빠르게 확인되는 것을 방지할 수 있으며, 이로 인해 라이트닝 채널과 같은 계약 기반 프로토콜에서 자금 손실이 발생할 수 있습니다. John Newbery는 Amiti Uttarwar의 공동 발견을 인용하면서 이 취약점을 책임감 있게 공개했습니다. 수정 사항은 Bitcoin Core 0.21.0에서 릴리스되었습니다.
무한 크기 금지 목록의 CPU/메모리 DoS : Bitcoin Core PR #15617 (0.19.0에 처음 포함됨)은 P2P
getaddr메시지가 최대 2500회 주소로 수신될 때 로컬로 금지된 IP를 확인하는 코드를 추가합니다. 노드의 연결되지 않은 목록의 길이는 무제한이며, 공격자가 대량 의 IP 주소(예: 쉽게 얻을 수 있는 IPv6 주소)를 제어하는 경우 목록의 크기가 엄청나게 커질 수 있습니다. 이 목록이 매우 길어지면 각getaddr요청이 과도한 CPU와 메모리를 소비하여 노드를 사용할 수 없게 만들거나 충돌이 발생할 수도 있습니다. 이 취약점은 CVE-2020-14198 로 번호가 지정되어 있으며 Bitcoin Core 0.20.1에서 수정되었습니다.BIP72 URI 구문 분석 시도로 인해 발생한 메모리 충돌 : 0.20.0 이전 비트코인 코어는 BIP72 에서 정의한 참가자를 사용하여 HTTP(S) URL을
r하는 BIP21bitcoin:URI를 확장하는 BIP70 결제 프로토콜을 지원했습니다. 비트코인 코어는 이 URL에서 파일을 다운로드하고 구문 분석을 기다리는 메모리에 저장하려고 시도하지만, 파일이 사용 가능한 메모리보다 크면 결국 비트코인 코어가 종료됩니다. 다운로드 시도가 백그라운드에서 진행되는 동안 사용자는 자리를 비울 수 있으므로 노드가 충돌하고 중요한 서비스가 다시 시작되지 않는 것을 알지 못할 수 있습니다. 이 취약점은 Michael Ford에 의해 공개되었으며 BIP70 지원을 제거하여 Bitcoin Core 0.20.0에서 수정되었습니다(주간 보고서 #70 참조).대규모
inv메시지의 메모리 DoS : P2Pinv메시지에는 최대 50,000개의 블록 헤더 해시 목록이 포함될 수 있습니다. 버전 0.20.0 이전에는 새로운 비트코인 코어 노드가 이해하지 못한 각 해시 값에 대해 별도의 P2Pgetheaders메시지로 응답했으며 이러한 메시지의 크기는 약 1kB였습니다. 이로 인해 노드는 약 50MB의 메시지를 메모리에 저장하고 피어가 메시지를 수신할 때까지 기다립니다. 각 피어는 이를 수행할 수 있으며(피어 수의 기본값은 약 130개), 이는 노드의 일반 메모리 요구 사항 외에 6.5GB 이상의 추가 메모리를 사용합니다. 이는 많은 노드를 충돌시키기에 충분합니다. 충돌이 발생한 노드는 계약 기반 프로토콜 사용자의 시간에 민감한 거래를 처리하지 못하여 잠재적으로 사용자가 자금을 잃을 수 있습니다. John Newbery는 책임감 있게 취약점을 공개하고 수정 사항을 제공했습니다. 수정 사항이 Bitcoin Core 0.20.0에 포함된 해시 수에 관계없이getheaders메시지로inv메시지에만 응답하십시오.잘못된 요청을 통한 CPU 낭비 DoS : Bitcoin Core 0.20.0 이전에는 공격자 또는 오작동하는 피어가 잘못된 P2P
getdata메시지를 보내 메시지를 처리하는 스레드가 CPU를 100% 소비하게 만들 수 있었습니다. 노드는 연결 기간(공격 후) 동안 더 이상 공격자로부터 메시지를 받을 수 없지만 정직한 피어로부터 메시지는 계속 받을 수 있습니다. 이는 CPU 코어가 적은 노드에서는 사소한 문제만 일으킬 수 있습니다. 다른 곳에서는 문제가 될 수 있습니다. John Newbery는 책임감 있게 취약점을 공개하고 수정 사항을 Bitcoin Core 0.20.0에 제공했습니다.고아 트랜잭션 처리로 인한 CPU DoS 및 노드 지연 : 비트코인 코어 노드는 노드가 아직 트랜잭션 풀 및 UTXO 세트 정보에 필요한 상위 트랜잭션을 갖고 있지 않은 " 고아 트랜잭션 "에 대해 100개 이하의 트랜잭션 캐시를 추적합니다. 새 트랜잭션의 유효성을 검사한 후 노드는 고아 트랜잭션이 처리 가능해졌는지 확인합니다. Bitcoin Core 0.18.0 이전에는 고아 트랜잭션 캐시를 확인할 때마다 노드는 최신 트랜잭션 풀과 UTXO 상태를 사용하여 각 고아 트랜잭션을 확인하려고 시도했습니다. 이러한 100개의 캐시된 고아 트랜잭션이 검증을 위해 대량 의 CPU를 필요로 하도록 구성되어 있는 경우 노드는 과도한 CPU를 낭비할 수 있으므로 몇 시간 동안 새 블록과 새 트랜잭션을 처리하지 못할 수 있습니다. 이 공격은 기본적으로 무료입니다. 고아 트랜잭션은 존재하지 않는 상위 트랜잭션을 참조할 수 있기 때문에 자유롭게 생성할 수 있습니다. 정지된 노드는 블록 템플릿을 생성할 수 없으므로 이 공격은 채굴자가 이익을 얻는 것을 방지하는 데 사용될 수 있으며 거래가 확인되는 것을 방지하는 데 사용될 수 있으며 잠재적으로 라이트닝 채널과 같은 계약 기반 프로토콜 사용자가 발생할 수 있습니다. 자금을 잃습니다. 개발자 sec.eine은 이 취약점을 성실하게 공개했으며 이는 Bitcoin Core 0.18.0에서 수정되었습니다.
난이도가 낮은 블록 헤더를 사용하는 메모리 내 DoS : 비트코인 코어 0.10부터 노드는 각 동료에게 자신이 알고 있는 최고의 블록체인 (가장 많은 작업 증명을 축적한 유효한 블록체인)에서 블록 헤더를 보내도록 요청합니다. 이 접근 방식의 알려진 문제는 악의적인 피어가 난이도가 낮은(예: 난이도 1) 대량 의 가짜 블록 헤더를 노드에 공격할 수 있다는 것입니다. 이러한 블록 헤더는 고급 ASIC 채굴 장비를 사용하여 쉽게 생성할 수 있습니다. Bitcoin Core의 원래 솔루션은 코드 내에 하드 코딩된 체크포인트 와 일치하는 온체인 블록 헤더만 허용하는 것이었습니다. 마지막 체크포인트도 2014년부터지만 오늘날의 기준으로는 난이도가 상대적으로 높기 때문에 가짜 블록 헤더를 생성하려면 대량 작업이 필요합니다. 그러나 비트코인 코어 0.12에 도입된 코드 변경으로 인해 노드는 난이도가 낮은 블록 헤더를 메모리에 수용할 수 있게 되었고, 잠재적으로 공격자가 가짜 블록 헤더로 메모리를 채울 수 있게 되었습니다. 이로 인해 노드 가동 중단이 발생하고 계약 기반 프로토콜(예: 라이트닝 채널) 사용자가 자금을 잃을 수도 있습니다. Cory Fields는 이 취약점을 공개했으며 0.15.0에서 수정되었습니다.
miniupnpc로 인한 원격 코드 실행 취약성 : Bitcoin Core 0.11.1(2015년 10월 출시) 이전 버전에서는 노드가 NAT를 통한 인바운드 연결을 허용하기 위해 기본적으로 UPnP를 활성화했습니다. 이는 Aleksandar Nikolic이 발견한 miniupnpc 라이브러리를 사용하여 원격으로 악용할 수 있는 여러 취약점( CVE-2015-6031 )을 발견한 것입니다. 이러한 흐름은 업스트림 라이브러리에서 수정되었고 수정 사항이 비트코인 코어에 반영되었으며 개발자는 기본적으로 UPnP를 비활성화하는 업데이트를 구현했습니다. 비트코인 개발자 Wladimir J. Van Der Laan은 이 버그를 조사하는 동안 동일한 라이브러리에서 또 다른 원격 코드 실행 취약점을 발견했습니다. 취약점은 정식으로 공개 되어 업스트림 라이브러리에서 수정되었으며 Bitcoin Core 0.12(2016년 2월 출시)에 적용되었습니다.
여러 피어의 대용량 메시지는 노드 충돌을 일으킬 수 있습니다 . Bitcoin Core 0.10.1 이전에는 노드별 P2P 메시지 크기 요구 사항이 (대략) 32MB를 초과하지 않았습니다. 그리고 역사적으로(지금까지) 노드는 기본적으로 최대 130개의 연결을 허용했습니다. 각 피어가 거의 동시에 최대 크기의 메시지를 보내려면 노드가 다른 메모리 요구 사항 외에 추가로 4GB의 메모리 공간을 할당해야 하며, 이는 많은 노드가 제공할 수 있는 것보다 많습니다. 이 취약점은 사용자 Evil-Knievel에 의해 BitcoinTalk.org 포럼에 공개되었으며 번호 CVE-2015-3641을 받았으며 Bitcoin Core 0.10.1에서 수정되었습니다. 수정 사항은 메시지 크기를 2MB 미만으로 제한하는 것이었습니다. (나중에 Segregated Witness 업그레이드의 경우 약 4MB로 늘어났습니다.)
