EVM(Ethereum Virtual Machine) 호환 블록체인은 이더리움 블록체인의 스마트 컨트랙트 기능, 프로그래밍 언어(Solidity), 그리고 툴링 생태계와의 호환성을 갖추도록 설계되어 있습니다. 이 과정에서 EVM 호환 가상 머신의 구현은 핵심 단계 중 하나입니다. 그러나 연구 과정에서 서로 다른 구현체 간의 EVM 호환성을 유지하는 것이 쉽지 않다는 사실을 발견했습니다.
이 문제를 해결하기 위해 BlockSec은 EVM 구현 내부의 버그 및 보안 취약점을 체계적으로 찾아낼 수 있는 내부 시스템을 개발했습니다. 이 시스템은 효과적인 것으로 입증되었습니다. Aurora Engine에서 4개의 버그가, Moonbeam에서 4개의 버그가 발견되어 보고되었습니다. 이 모든 버그는 보고 후 수정되었습니다. 참고로, 이 테스트 방법론은 작년에 Solana rbpf 구현에서 두 가지 심각한 취약점(CVE-2021–46102, CVE-2022–23066)을 찾아내는 데도 활용되었습니다.
1. 배경
오늘날 낮은 가스 비용, 높은 처리량, 뛰어난 성능을 최적화한 다양한 블록체인이 제안되고 있습니다. 이에 따라 새로운 가상 머신이나 개발 언어가 제안되고 있으며, 이는 기존 Solidity 개발자들의 전환 장벽을 높이고 있습니다. 이러한 상황에서 많은 EVM 호환 솔루션들이 제안되었고, 이를 통해 사용자들은 Solidity로 개발한 DApp을 새로운 체인에 배포할 수 있게 되었습니다. Aurora와 Moonbeam은 이러한 EVM 호환 솔루션의 대표적인 사례입니다. 그러나 이러한 EVM 구현체들의 견고성, 신뢰성, 정확성은 아직 검증되지 않았으며 주의를 기울일 필요가 있습니다. 이를 위해 우리는 차등 퍼징(differential fuzzing) 기법을 활용하여 구현체에 결함이 있는지 확인했습니다.
2. 차등 퍼징(Differential Fuzzing)
기본적인 아이디어는 동일한 입력을 Aurora, Moonbeam과 같은 EVM 구현체와 최신 이더리움 클라이언트(즉, geth)에 동시에 제공하여 동일한 출력이 나오는지 확인하는 것입니다. 구체적으로, 이더리움의 과거 트랜잭션을 수집하고 다양한 전략으로 컨트랙트 코드와 트랜잭션 상태를 변형하여 테스트 케이스를 생성했습니다. 연구 결과, Aurora Engine과 Moonbeam이 일부 경우에 명세를 따르지 않는다는 사실이 밝혀졌습니다. 다행히 보고된 모든 문제는 해결되었으며, 이제 그 세부 내용을 공유하겠습니다.
3. 발견된 버그
이 버그들의 대부분은 사전 컴파일된 컨트랙트에서 발견되었으며, 근본 원인과 영향은 다양합니다. 예를 들어, 일부 버그는 논스(nonce) 값 계산에 영향을 미치고, 다른 버그는 가스 계산에 영향을 주어 DoS 공격으로 이어질 수 있습니다. 발견된 모든 버그는 EVM 명세에서 지정한 실행 로직에 위배되며, 특정 상황에서 예기치 않은 동작을 유발할 수 있습니다. 발견된 버그에 대한 상세한 설명은 아래에서 확인하세요.
3.1 부적절한 유효성 검사
암호화 로직은 복잡합니다. 이 경우 EVM 바이트코드로 해당 로직을 구현하면 상당히 많은 가스가 소비될 수 있습니다. 대신, 네이티브 코드로 개발된 사전 컴파일된 컨트랙트는 성능을 향상시킬 수 있습니다. 그러나 부적절한 유효성 검사로 인해 사전 컴파일된 컨트랙트에서 여러 버그가 발견되었습니다.
Aurora Engine: ecPairing
이 버그는 사전 컴파일된 컨트랙트 ecPairing에서 발견되었습니다.
ecPairing의 입력은 두 타원 곡선 위의 여러 점으로 구성됩니다. 명세에 따르면 점 (0, 0)은 두 곡선 위에 모두 있으며 유효한 입력이어야 합니다:
그러나 Aurora Engine(버전 2.7.0)은 입력에 점 (0, 0)이 포함된 경우 되돌림(revert)을 수행합니다.
관련 PR은 여기에서 확인할 수 있습니다.
Moonbeam: ecMul
이 버그는 사전 컴파일된 컨트랙트 ecMul에서 발견되었습니다. Aurora Engine과 달리, Moonbeam은 입력이 유효한 경우에도 트랜잭션을 되돌립니다. 명세에 따르면 사전 컴파일된 컨트랙트 ecMul은 입력 길이가 64보다 짧을 경우 0으로 패딩해야 합니다. 그러나 Moonbeam은 패딩 작업을 수행하는 대신 되돌림을 실행합니다.
또한 사전 컴파일된 컨트랙트 ecAdd와 modexp에서도 동일한 문제가 발견되었습니다.
Moonbeam: ecRecover
이 버그는 이더리움 주소를 복구하는 데 사용되는 사전 컴파일된 컨트랙트 ecRecover에서 발견되었습니다.
명세에 따르면, input[32..63]의 v는 U256 식별자를 나타내며, 27 또는 28이어야 하고, 그렇지 않은 경우 ecRecover는 아무것도 반환하지 않아야 합니다(단, 전체 트랜잭션이 되돌려지면 안 됩니다).
그러나 Moonbeam은 여기서 두 가지 실수를 범합니다:
- input[32..63]을 U256 타입으로 변환한 후 값을 확인하는 대신, input[63]만 확인합니다.
- 식별자가 0 또는 1일 때 입력을 유효한 것으로 간주합니다(27 또는 28이어야 합니다).
Moonbeam: ecPairing
이 버그는 사전 컴파일된 컨트랙트 ecPairing에서 발견되었습니다. Moonbeam은 입력이 유효하지 않을 때 트랜잭션을 되돌리지 않습니다. 명세에 따르면, 사전 컴파일된 컨트랙트 ecPairing의 입력은 192의 배수여야 합니다. 그렇지 않은 경우 트랜잭션은 되돌려져야 합니다.
그러나 Moonbeam은 위에서 언급한 요구 사항이 충족되지 않아도 트랜잭션을 되돌리지 않습니다.
3.2 잘못된 가스 계산
각 사전 컴파일 컨트랙트에는 가스 사용량을 결정하는 알고리즘이 있습니다. 잘못된 가스 계산은 DoS 공격으로 이어질 수 있습니다.
우리는 Aurora Engine과 Moonbeam 모두에서 가스 계산이 잘못된 두 가지 버그를 발견했습니다.
Aurora Engine: modexp
이 버그는 사전 컴파일된 컨트랙트 modexp에서 발견되었습니다. 가스 사용량 계산 알고리즘은 EIP-2565에 의해 정의됩니다. 가스 사용량은 반복 횟수와 관련이 있습니다.
반복 횟수를 계산하는 알고리즘은 다음과 같습니다.
def calculate_iteration_count(exponent_length, exponent):
iteration_count = 0
if exponent_length <= 32 and exponent == 0: iteration_count = 0
elif exponent_length <= 32: iteration_count = exponent.bit_length() - 1
elif exponent_length > 32: iteration_count = (8 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
return max(iteration_count, 1)위 알고리즘에 따르면, 반복 횟수는 최소 1이어야 합니다. 그러나 Aurora Engine은 max(iteration_count, 1) 대신 iteration_count를 직접 반환합니다. 이 경우 반환값(즉, iteration_count)이 0이 될 수 있으며, 특정 상황에서 Aurora가 예상보다 훨씬 적은 가스 비용을 청구한다는 것을 의미합니다.
관련 이슈 링크는 여기에서 확인할 수 있습니다.
Moonbeam: modexp
이 버그도 사전 컴파일된 컨트랙트 modexp의 calculate_iteration_count 함수에서 발견되었습니다. 단, Moonbeam에서 발견되었습니다.
exponent_length가 32보다 클 경우, iteration_count는 아래 알고리즘으로 계산됩니다.
(8 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)여기서 exponent & (2**256 - 1)은 exponent의 가장 낮은 32바이트를 취하며, Moonbeam의 구현도 이 알고리즘을 따르고 있습니다.
그러나 명세에 따르면, 가스 계산 공식은 exponent의 가장 높은 32바이트를 사용해야 합니다:
3.3 논스 증가 버그
외부 소유 계정(EOA)의 논스는 해당 주소가 서명한 성공적인 트랜잭션 수를 나타냅니다. 그러나 Aurora Engine에서는 유효하지 않은 트랜잭션을 전송하여 논스가 증가될 수 있다는 사실을 발견했습니다.
EIP-1559에 따르면, 트랜잭션 실행 전에 EVM은 서명자가 전송할 네이티브 토큰(예: ETH)과 필요한 가스를 충당할 충분한 잔액을 가지고 있는지 확인해야 합니다. 그렇지 않은 경우, 트랜잭션은 폐기되어야 하며 서명자의 논스는 증가하지 않아야 합니다.
Aurora Engine은 이 상황에서 트랜잭션을 폐기하지만, 서명자의 논스는 여전히 증가시킵니다.
관련 PR은 여기에서 확인할 수 있습니다.
3.4 잘못된 옵코드 구현
이 버그는 특정 옵코드(즉, PUSH)의 구현과 관련이 있습니다. PUSH 옵코드 뒤에 오는 바이트가 불완전할 경우, 우측 정렬(right-aligned)되어야 합니다. 예를 들어, 바이트코드 0x64ffff는 다음과 같이 디코딩될 수 있습니다:
PUSH5 0xffff피연산자는 우측 정렬되어야 하므로 0xffff000000이 스택에 푸시되어야 합니다. 그러나 Aurora Engine과 Moonbeam 모두에서 0xffff가 대신 푸시되어 올바르지 않습니다.
관련 PR은 여기에서 확인할 수 있습니다.
4. 우리의 서비스
BlockSec은 서로 다른 블록체인 구현체 간의 EVM 호환성 및 보안을 유지하는 것의 중요성을 잘 이해하고 있습니다. 이를 위해 EVM 구현체의 취약점을 쉽게 찾아낼 수 있는 체계적인 버그 탐지 방법을 개발했습니다.
우리의 내부 시스템은 EVM 구현체의 버그 및 보안 취약점을 찾아내는 데 매우 효과적인 것으로 입증되었습니다. Aurora Engine에서 4개, Moonbeam에서 4개의 버그를 성공적으로 보고하고 수정했습니다. 또한, 우리의 테스트 방법론은 작년에 Solana rbpf 구현에서 두 가지 심각한 취약점(CVE-2021–46102, CVE-2022–23066)을 찾아내는 데 사용되어, 우리 접근 방식의 효과성을 입증했습니다.
우리의 체계적인 버그 탐지 방법을 도입함으로써, 고객들은 자신들의 EVM 구현체가 안전하고 신뢰할 수 있다는 확신을 가질 수 있습니다. 우리는 EVM 호환성과 보안을 위한 최고 수준의 솔루션을 제공하여, 고객들이 사용자 및 이해관계자들의 신뢰를 구축할 수 있도록 최선을 다하고 있습니다.
BlockSec 소개
BlockSec 팀은 블록체인 생태계의 보안에 집중하며, 선도적인 DeFi 프로젝트와 협력하여 제품 보안을 강화하고 있습니다. 이 팀은 학계와 산업계에서 활동한 최고 수준의 보안 연구원과 경험 풍부한 전문가들로 구성되어 있습니다. 이들은 권위 있는 학술 컨퍼런스에 여러 편의 블록체인 보안 논문을 발표했으며, DeFi 애플리케이션의 여러 제로데이 공격을 보고하고, 영향력 있는 보안 사고에 대한 상세한 분석 보고서를 공개했습니다.
