BitsLab 산하 TonBit, TON VM 코어 취약점 발견: 취약점 근본 원인 및 완화 조치 상세 설명
최근 TON 네트워크의 가상 머신 시스템이 중대한 보안 업그레이드를 단행했다. BitsLab 산하의 보안 팀 TonBit는 TON 가상 머신의 리소스를 고갈시킬 수 있는 핵심 취약점을 성공적으로 발견하고 수정을 지원했다. 이 취약점은 가상 머신이 Continuation의 중첩을 처리할 때 발생하는 재귀 메커니즘을 악용할 수 있으며, 악성 계약이 이를 이용해 시스템 다운과 네트워크 불안정을 유발할 수 있다.
이 취약점이 악용될 경우, 단 하나의 TON도 소비하지 않고 모든 검증 노드를 다운시켜 네트워크 가용성에 직접적인 위협을 가할 수 있었다. 이번 사례에서 TonBit는 뛰어난 기술력을 바탕으로 신속하게 취약점을 식별하고, 가상 머신의 내부 제어 흐름 메커니즘을 조정하여 재귀 대신 반복(iteration)을 사용하는 혁신적인 해결책을 제시함으로써 TON 사용자들을 위한 더욱 안전한 생태계를 구축하는 데 성공했다. TON 공식 팀은 최신 업데이트 공지에서 TonBit의 생태계 보안에 대한 탁월한 기여를 특별히 언급하며 감사를 표했다.
다음 상세한 보안 보고서에서는 이번 취약점의 원인, 기술적 세부 사항 및 해결 방안을 심층 분석한다. 본 보고서는 Continuation의 깊은 중첩을 통해 자원 고갈 공격을 유도하는 재귀 체인을 어떻게 구성하는지, 악성 계약이 호출 스택을 확장함으로써 호스트 스택 공간을 고갈시키는 방법을 설명한다. 또한 TonBit 팀이 재귀 체인의 설계 결함을 제거하고 협업형 반복 메커니즘으로 전환하여 문제를 근본적으로 해결한 과정을 소개한다. 이번 수정은 TON 네트워크의 안정성을 크게 향상시켰을 뿐 아니라 블록체인 산업의 저수준 보안에도 중요한 참고 자료를 제공한다.
사례 연구: TON VM의 DoS 취약점 및 완화 조치
소개
본 보고서는 TON 가상 머신(TVM) 내 존재하는 DoS(서비스 거부) 취약점과 이를 해결하기 위한 완화 조치를 설명한다. 이 취약점은 스마트 계약 실행 도중 Continuation 중첩을 처리하는 방식에서 비롯된다. 공격자는 Continuation을 생성하고 특정 방식으로 깊게 중첩시켜 평가 과정에서 깊은 재귀를 유발함으로써 호스트의 스택 공간을 고갈시키고 가상 머신의 작동을 중단시킬 수 있다. 이 문제를 완화하기 위해 가상 머신은 Continuation 및 제어 흐름 처리 방식을 변경하였다. 이제 더 이상 Continuation 체인을 통한 순차적 꼬리 호출(tail call)을 수행하지 않고, 가상 머신이 주도적으로 체인을 반복하며 처리한다. 이 방법은 일정한 호스트 스택 공간만을 사용함으로써 스택 오버플로우를 방지한다.
개요
공식 문서에 따르면 TON VM은 스택 기반 가상 머신으로, 내부 프로세스 및 스마트 계약에 대해 Continuation-Passing Style(CPS, 연속체 전달 스타일)을 제어 흐름 메커니즘으로 채택하고 있다. 제어 흐름 레지스터는 계약에서 접근 가능하여 유연성을 제공한다.
TVM의 Continuation은 이론적으로 다음 세 가지로 나뉜다:
-
OrdCont(vmc_std): TON 어셈블리 조각을 포함하며 TVM의 1급 객체이다. 계약은 런타임 중 명시적으로 이를 생성하고 전달함으로써 임의의 제어 흐름을 구현할 수 있다.
-
비보통 Continuation(Extraordinary continuations): 일반적으로 OrdCont를 구성 요소로 포함하며, 명시적 반복 원시 함수 또는 특수한 암묵적 작업을 통해 생성되어 해당 제어 흐름 메커니즘을 처리한다.
-
추가 ArgContExt: 다른 Continuation을 래핑하여 제어 데이터를 보존한다.
계약 실행 중 가상 머신은 메인 루프에 진입하며, 매번 계약 조각의 한 단어를 디코딩하고 해당 작업을 적절한 핸들러로 분배한다. 일반 핸들러는 작업을 수행한 후 즉시 반환한다.
반면, 반복 지시문은 제공된 Continuation을 구성 요소로 사용해 비보통 Continuation을 생성하고, 적절한 컨텍스트로 점프한다. 비보통 Continuation 자체는 점프 시 로직을 구현하며 조건에 따라 특정 구성 요소로 점프한다. 예를 들어 WHILE 지시문을 사용할 경우, 아래 그림 1과 같이 이를 시연할 수 있다(간략화를 위해 가능한 탈출 경로는 생략).
그림 1: 비보통 Continuation 로직
근본 원인
취약점이 존재했던 가상 머신 버전에서는 이러한 점프가 연속적인 동적 꼬리 호출을 유도하였으며, 이는 각 점프마다 호스트 스택이 스택 프레임을 유지해야 함을 의미한다(아래 그림 2 참조).
WhileCont을 예로 들며, 간결함을 위해 기타 부분은 생략한다.
그림 2: 깊은 중첩을 위한 3중 점프 재귀
이론적으로 이는 문제가 되지 않아야 한다. 왜냐하면 구성 요소는 일반적으로 OrdCont로 표현되며, 이들의 점프는 현재 컨텍스트를 저장한 후 자신이 보유한 조각을 먼저 실행하도록 가상 머신에 지시하고, 남은 계약 조각보다 우선 실행되며 추가 재귀를 유발하지 않는다. 그러나 비보통 Continuation은 이론적으로 TVM의 cc(c0) 레지스터(위 set_c0 분기 참조)를 통해 구성 요소에 접근할 수 있도록 설계되어 있다. 따라서 계약은 이 기능을 악용해 깊은 재귀를 수행할 수 있다(후술). 이 일반 기능의 구현을 변경하는 것보다, 비보통 Continuation의 점프 과정에서 재귀를 직접 제거하는 것이 더 명확하고 용이하다.
이미 획득한 비보통 Continuation을 반복적으로 사용해 상위 수준의 비보통 Continuation을 구성함으로써, 반복을 통해 깊게 중첩된 Continuation을 생성할 수 있다. 이러한 깊게 중첩된 Continuation이 평가될 때 호스트의 사용 가능한 스택 공간을 고갈시켜 운영체제가 SIGSEGV 신호를 보내고 가상 머신 프로세스를 종료시킬 수 있다.
그림 3은 중첩 과정의 개념 증명(PoC)을 제공한다.
그림 3: 중첩 과정
각 반복에서 본문이 WhileCont{chkcond=true}를 하나씩 확장하는 것을 확인할 수 있다. 이전 반복에서 생성되어 저장된 cc를 실행하면 다음과 같은 호출 스택이 형성된다:
스택 공간이 중첩 레벨(즉 반복 횟수)과 선형적으로 의존한다는 것을 알 수 있으며, 이는 결국 스택 공간 고갈 가능성을 시사한다.
실제 환경에서의 악용 가능성
실제 블록체인 환경에서는 연료비(fuel fee) 제한으로 인해 악성 계약의 구축이 상당히 어렵다. 중첩 과정이 선형 복잡도를 가지며(TVM 설계상 자기참조를 통한 더 저렴한 구축을 효과적으로 방지), 실질적으로 작동 가능한 악성 계약을 개발하는 것은 쉬운 일이 아니다. 구체적으로 말해, 한 단계의 중첩은 디버깅 바이너리에서 3개의 호스트 스택 프레임(320바이트)을 소비하며, 릴리스 바이너리에서는 2개(256바이트, 후속 두 호출이 인라인화됨)를 소비한다. 현대 POSIX 운영체제에서 실행되는 검증 노드의 기본 스택 크기는 8MiB이며, 이는 릴리스 바이너리에서 30,000단계 이상의 중첩을 지원할 수 있다. 여전히 스택 공간을 고갈시키는 계약을 작성할 수는 있지만, 앞 섹션의 예시보다 훨씬 어렵다.
완화 조치
이 패치는 Continuation 중첩 상황에서 점프 동작을 수정하였다. Continuation 점프의 시그니처가 변경된 것을 확인할 수 있다.
UntilCont을 예로 들며, 간략화를 위해 기타 부분은 생략한다.
이제 더 이상 VmState::jump를 호출하여 다음 Continuation으로 점프하지 않는다. 이는 각 Continuation에서 3중 점프를 재귀적으로 실행하고 반환 값을 뒤로 전파할 때까지 기다리는 것을 의미한다. 이제 Continuation 점프는 다음 레벨의 Continuation만 해석한 후 제어권을 가상 머신에 돌려준다.
가상 머신은 협업적으로 각 레벨의 continuation을 반복하며 해석해 나가며, NullRef를 만날 때까지 진행한다. NullRef는 체인의 해석이 완료되었음을 나타내며, OrdCont 또는 ExuQuitCont에서 구현된다. 이 반복 과정에서 호스트 스택에는 항상 하나의 continuation 점프만 할당되므로 스택 사용량이 일정하게 유지된다.
결론
높은 가용성이 요구되는 서비스에서는 재귀 사용이 잠재적인 공격 벡터가 될 수 있다. 사용자 정의 로직이 관련될 경우 재귀 종료를 강제하는 것은 도전 과제일 수 있다. 본 DoS 취약점은 리소스 제한 상황(또는 기타 제약 조건)에서 정상 기능이 예기치 않게 악용되는 극단적인 사례를 보여준다. 사용자 입력에 따라 재귀가 결정된다면 유사한 문제가 발생할 수 있으며, 이는 가상 머신의 제어 흐름 원시 함수에서 매우 흔한 현상이다.
본 보고서는 TON 가상 머신에 존재하는 핵심 DoS 취약점의 기술적 세부 사항, 근본 원인, 가능한 공격 방식을 상세히 분석하였으며, 동시에 TonBit 팀이 제시한 효율적인 해결책을 제시한다. 가상 머신의 재귀 점프 메커니즘을 반복 처리 방식으로 조정함으로써, TonBit는 네트워크 마비를 유발할 수 있었던 핵심 취약점을 성공적으로 수정하는 해결책을 제시하고 이를 수정하는 데 기여하여 TON 생태계에 더욱 견고한 보안을 제공했다. 이번 사건은 TonBit가 블록체인 저수준 기술 보안 분야에서 오랜 경험을 축적했음을 입증하며, TON 공식 Security Assurance Provider(SAP)로서의 중요한 역할을 보여준다.
TonBit는 TON 생태계에서 필수적인 보안 파트너로서, 블록체인 네트워크의 안정성과 사용자 자산 보호를 선도하고 있다. 취약점 발견부터 솔루션 설계까지, TonBit는 강력한 기술력과 블록체인 발전에 대한 깊은 이해를 바탕으로 TON 네트워크의 장기적 발전을 위한 든든한 기반을 마련했다. 또한 TonBit 팀은 사이버 보안 아키텍처, 사용자 데이터 보호, 블록체인 응용 시나리오의 보안 강화 분야에서도 지속적으로 노력하고 있다. 앞으로도 TonBit는 혁신을 통해 보안 기술 발전을 이끌며, TON 생태계와 블록체인 산업 전체의 건강한 발전을 위해 끊임없이 지원과 보장을 제공할 것이다. 이번 취약점 발견 및 수정 지원 작업은 TON 공식팀으로부터 높은 평가를 받았으며, TonBit의 블록체인 보안 분야에서의 업계 지위를 더욱 공고히 하고, 탈중앙화 생태계 발전을 위한 확고한 약속을 보여주었다.
TonBit 공식 웹사이트: https://www.tonbit.xyz/
TonBit 공식 트위터: https://x.com/tonbit_
텔레그램: https://t.me/BitsLabHQ
Linkedin: https://www.linkedin.com/company/tonbit-team/
블로그: https://www.tonbit.xyz/#blogs
텔레그램 감사 요청 연락처: @starchou
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@tonbit_
