이더리움 클라이언트 베수, 피어 하나로 노드 다운되는 취약점 5건 26.7.1서 패치

이더리움 실행 클라이언트 베수(Besu)에서 발견된 자원고갈(resource-exhaustion) 취약점 5건이 패치된 뒤 뒤늦게 공개됐다. 보안업체 CertiK는 자체 연구로 찾아낸 이 결함들을 베수 개발팀에 비공개로 제보했고, 베수는 7월 27일(현지시각) 배포한 26.7.1 버전으로 다섯 가지 문제를 모두 수정했다. 기술적 세부 내용은 패치가 충분히 퍼진 뒤인 8월 14일(현지시각) 네 건의 보안권고문을 통해서만 공개됐다. 해당 결함들은 P2P 네트워킹, RPC, 웹소켓, 합의 처리 인터페이스 전반에 걸쳐 있었고, 방치될 경우 노드 메모리나 스레드를 고갈시켜 노드 가용성이나 합의 처리를 방해할 수 있었다.

다섯 개 결함, 어디를 노렸나

CertiK가 찾아낸 다섯 건의 취약점은 블록 알림 처리, 미래 시점 합의 제안 버퍼링, 웹소켓 구독 제한, JSON-RPC 필터 생성 등 네 가지 영역에 걸쳐 있었다. 이 중 두 건은 근본 원인과 수정 방식이 같아 하나의 권고문으로 묶여, 총 네 건의 깃허브 보안권고문(GHSA-j2j5-x2rr-cv75, GHSA-qhrf-865g-38rh, GHSA-ffqr-pj4h-xq37, GHSA-vff7-xxjc-rccp)으로 정리됐다. CertiK는 이 결함들의 심각도를 경미(Minor)에서 심각(Major)까지 매겼고 이 중 두 건이 Major 등급이었다. 베수 측 자체 등급으로는 Moderate에서 High까지 분류됐다.

문제가 된 인터페이스는 P2P 통신 프로토콜인 devp2p의 eth/68·istanbul/100 서브프로토콜, HTTP 기반 JSON-RPC, 웹소켓 RPC 네 곳이다. 26.7.1 버전은 이 문제들을 고치면서 활성 JSON-RPC 필터와 웹소켓 구독 개수에도 새로운 상한선을 뒀다. 무제한으로 늘어날 수 있던 리소스 소비 경로를 원천적으로 막은 조치다.

CertiK, 어떻게 결함을 찾았나

CertiK는 이번 결함을 베수나 다른 고객사로부터 의뢰받은 감사가 아니라 자체 연구로 발견했다고 밝혔다. 별도의 작업범위 문서(scope document)조차 없었다는 설명이다. 연구팀은 통신·대규모 분산 시스템의 카오스 엔지니어링(고의로 장애를 주입해 시스템 반응을 관찰하는 기법)을 블록체인에 적용해, 비공개 다중 노드 베수 테스트망을 직접 구축했다. P2P, HTTP RPC, 웹소켓 RPC, 합의 인터페이스 전반에 인위적인 결함을 주입하며 노드가 언제 가용성을 잃는지 확인하는 방식이다.

CertiK는 필요할 때마다 결함을 재현할 수 있는 증거(proof-of-concept) 테스트 도구까지 함께 베수 팀에 전달했다. 베수 팀이 별도 관찰 없이도 문제를 검증하고 수정을 확인할 수 있게 하기 위해서다. 일부 결함은 다중 검증자로 구성된 QBFT 합의망에도 그대로 적용해, 소수 노드만 마비시켜도 체인 전체의 라이브니스(liveness, 새 블록을 계속 생성하는 능력)를 멈출 수 있는지까지 시험했다. 이 방법론은 CertiK의 상시 적대적 테스트 서비스인 ‘체인 스캔(Chain Scan)’의 기반이 됐다. 같은 테스트 도구는 향후 베수의 새 버전에도 그대로 적용해 회귀 결함을 잡아내는 데 쓰일 수 있다는 설명이다. CertiK는 예일대학교와 컬럼비아대학교 교수진이 2017년 설립한 보안업체로, 지금까지 11만9000건 이상의 취약점을 찾아냈고 150여개 국가·지역에서 6,000억 달러 이상의 디지털자산 보호에 기여했다고 소개하고 있다.

가장 위험했던 결함, 피어 하나로 노드 다운

CertiK가 Major로 분류한 첫 번째 결함(HYB-01)은 설정 변경으로도 막을 수 없는 구조적 문제였다. 베수는 다른 노드가 보내는 NEW_BLOCK_HASHES 메시지, 즉 새 블록이 나왔다는 통상적인 알림을 받으면 알림에 담긴 블록 해시 하나하나를 별도의 조회(fetch) 작업과 네이티브 스레드로 처리했다. 이 스레드 수에는 아무런 상한이 없었다.

특별한 권한이 필요 없는 일반 피어 하나만 있어도, 정상적으로 운영되는 노드를 수만 개의 스레드로 몰아넣어 수 초 만에 메모리 부족(OOM)으로 강제 종료시킬 수 있었다는 게 CertiK의 설명이다. 같은 기법을 QBFT 합의망의 검증자 과반수에 겨냥하면 합의 자체를 완전히 멈춰 세울 수도 있었다. 이 결함은 기본 devp2p 통신 경로에서 발생해 JSON-RPC나 웹소켓 설정을 바꾸는 방식으로는 막을 수 없었다는 점에서 나머지 세 건과 성격이 달랐다. 베수는 해당 경로의 무제한 스레드 풀을 고정 크기의 제한된 풀로 교체해 이 문제를 해결했다.

왜 조율된 공개가 필요했나

베수는 이더리움 메인넷과 테스트넷에서 실행 클라이언트로 쓰이는 동시에 기업용 프라이빗 네트워크에서도 활용된다. 명령줄 인터페이스와 JSON-RPC API, 플러그인 API를 함께 제공하는 자바 기반 오픈소스 클라이언트로, 아파치 2.0 라이선스로 배포된다. 이더리움은 게스(Geth), 네더마인드(Nethermind), 레스(Reth), 베수 등 여러 독립 실행 클라이언트를 함께 지원하는데, 이는 특정 클라이언트 하나의 결함이 네트워크 전체 장애로 번지는 위험을 줄이기 위한 설계다. 2024년 1월만 해도 게스 점유율이 임계선인 3분의 2를 훌쩍 넘어선 84%에 달해, 특정 클라이언트 결함 하나가 체인 파이널리티 자체를 멈출 수 있다는 우려가 나온 바 있다.

이더노드(Ethernodes) 집계에 따르면 2026년 8월 기준 이더리움 실행 클라이언트 8023개 노드 중 게스가 40.58%, 네더마인드가 32.08%, 레스가 15.07%, 베수가 7.49%를 차지하고 있다. 점유율 4위인 베수는 결함이 발견돼도 네트워크 전체를 멈추기보다는 일부에 영향을 주는 구조지만, 다중 클라이언트 체제가 제 역할을 하려면 이런 소수 클라이언트의 결함도 소홀히 다룰 수 없다는 지적이 나온다.

베수는 이번 26.7.1 배포와 보안권고문에서 CertiK와 함께 이더리움 파운데이션 시큐리티(Ethereum Foundation Security) 팀의 책임있는 공개(responsible disclosure)에도 감사를 표했다. 패치가 먼저 배포되고 세부 기술 정보는 운영자들이 업그레이드할 시간을 번 뒤에야 공개되는 조율된 절차를 거친 셈이다. CertiK 측은 이번 조사가 상업적 의뢰 없이 이뤄진 자체 연구였다는 점을 강조하며, 공격자보다 먼저 결함을 찾아내는 것이 책임있는 공개의 목표라고 설명했다.