"포킹된 EVM"의 보안 위험을 어떻게 평가합니까?

Odaily资深作者

2023-05-30 09:35

이 기사는 약 2306자로, 전체를 읽는 데 약 4분이 소요됩니다

상위 10개 TVL 체인 중 9개가 EVM 스마트 계약을 지원합니다.

이 기사는 Coinbase이 기사는

ERC-20 및 기타 스마트 계약 기반 자산을 거래하는 고객의 보안 및 보관 보증을 강화하기 위해 Coinbase 블록체인 보안 팀은 이러한 자산의 동작을 정의하는 프로그래밍 계층인 EVM(Ethereum Virtual Machine)을 조사했습니다. 자체 네트워크의 EVM을 수정하는 프로젝트를 평가할 때 Coinbase의 블록체인 보안 팀은 주요 EVM 변경 사항을 검토하여 수정된 EVM이 원래 EVM 구현과 동일한 보안 및 보관 보장을 제공할 수 있는지 여부를 결정합니다.

보조 제목

분기된 EVM 상태

2023년 5월 현재 EVM(Ethereum Virtual Machine)은 가장 인기 있는 스마트 계약 실행 플랫폼에 대해 "빅 브라더"라는 칭호를 주장했습니다. DefiLlama에 따르면 총 가치 잠금(TVL) 기준 상위 10개 체인 중 9개가 EVM 스마트 계약을 지원합니다. 따라서 EVM에 대한 깊은 이해는 블록체인 생태계 전반에서 스마트 계약을 지원하는 데 중요합니다.

EVM은 이더리움 네트워크에서 분산된 스마트 계약 실행을 위한 가상 머신입니다. 많은 EVM 호환 블록체인은 프로토콜 소프트웨어에서 직접 go-ethereum(Golang) 및 besu(Java)와 같은 다양한 언어로 인기 있는 Ethereum 실행 클라이언트의 표준 구현을 활용합니다.즉 말하자면,EVM을 분기하고 수정하는 것은 실제로 주요 프로토콜 내에서도 블록체인 생태계에서 매우 일반적입니다.

. 예를 들어, Coinbase의 Base L2 블록체인을 "강화"하는 Optimism Bedrock Stack은 인기 있는 이더리움 실행 클라이언트와 동일한 EVM을 실행하는 op-geth라는 go-ethereum 실행 클라이언트의 포크와 호환됩니다. 그러나 이것은 Ethereum의 EVM이 Optimism의 EVM과 정확히 동일하게 작동한다는 것을 의미하지는 않습니다. op-geth EVM은 경우에 따라 약간 다르게 작동합니다(즉, 임의의 값을 반환하는 어려움은 시퀀서에 의해 결정됨).계약은 일부 EVM 호환 체인에서 이더리움에서와 다르게 실행될 수 있으며 EVM 스마트 계약 동작에 대한 보안 가정도 프로토콜마다 크게 다를 수 있습니다.

보조 제목

EVM 보안 프레임워크 포크

이를 위해 Coinbase는 일부 분기된 EVM 구현의 보안 영향을 평가하기 위한 Web3 보안 프레임워크를 개발했습니다. 우리는 그것을 Coinbase의 분기된 EVM 프레임워크라고 부르며, 아래에서 자세히 설명합니다.

이 분기된 EVM 보안 프레임워크를 통해 Coinbase는 다음을 효과적으로 수행할 수 있습니다.
이더리움 토큰 프레임워크의 보안 가정의 무효성을 이해하면 새로운 EVM 호환 블록체인을 안전하게 활성화하여 탈중앙화 거래소에서 ERC-20/ERC-721 토큰을 지원할 수 있습니다.
Coinbase의 Base L2 블록체인에서 EVM 스마트 계약의 안전한 사용 및 실행을 보장합니다.

보조 제목

EVM 호환 블록체인의 보안 표준

우리는 보안을 Coinbase 지원을 받을 수 있는 분기된 EVM 구현에 대한 최소 요구 사항을 나타내는 두 가지 보안 기준으로 요약합니다.

보조 제목

EVM 구현의 보안 위험을 어떻게 감사합니까?

포크된 EVM 프레임워크는 전체 보안 기준(예: 계약 불변성 및 안전한 실행 환경) 준수를 평가할 때 다음 감사 요구 사항에 중점을 둡니다. 다음 위험 요소는 포크 EVM 감사의 전체 범위가 아닙니다.

EVM opcode의 정의 및 인코딩을 수정하면 계약 실행 방식이 크게 달라질 수 있습니다. 예를 들어, 일부 분기된 EVM 구현(EVM')이 산술 ADD opcode를 변경하여 두 값(x 1 - x 2)을 빼는 논리(x 1 + x 2 )를 정의한다고 가정합니다.

결과적으로 편차 EVM'은 표준 EVM과 실행 시 동일하지 않고 호환되지 않습니다. opcode 수정의 결과는 정수 오버플로 및 산술 opcode의 언더플로 방지와 같은 유익한 동작이거나 로컬 자산의 무한 채굴을 유발하는 자체 파괴 동작과 같은 더 위험한 동작일 수 있습니다.

EVM은 사전 컴파일된 계약을 사용하여 복잡한 기능(예: 암호화 기능)을 정의하고, 접근성이 떨어지는 EVM 바이트코드를 사용하는 대신 Golang과 같은 더 편리하고 성능이 뛰어난 언어를 사용합니다.

기본적으로 이들은 노드 소프트웨어에 표시된 미리 결정된 체인 주소를 통해 액세스되는 프로그래밍된 기능입니다. Ethereum Yellow Paper(2023년 5월 기준)에는 9개의 프리컴파일러가 정의되어 있으며, 이 9개의 프리컴파일러에 대한 변경 또는 새로운 프리컴파일러의 도입은 감사 대상입니다.

또 다른 구체적인 예인 BNB 스마트 체인 취약점을 살펴보겠습니다. BNB 스마트 체인은 노드를 실행하기 위해 go-ethereum의 다른 구현을 사용합니다. 이를 위해 두 개의 새로운 사전 컴파일된 계약(tmHeaderValidate, iavlMerkleProofValidate)이 도입되어 타사 소프트웨어(예: Cosmos SDK)를 활용하여 라이트 클라이언트 블록 유효성 검사 및 Merkle 증명 유효성 검사를 수행합니다. 문제는 Cosmos SDK 소프트웨어의 IAWL 트리 표현에 암호학적으로 유효하지 않은 증명이 유효성 검사를 통과하도록 허용하는 구현 버그가 있다는 것입니다. 즉, 누구나 허공에서 돈을 벌 수 있습니다. 공격자는 iavlMerkleProofValidate 프리컴파일러에 중첩된 이 구현 결함을 악용하여 Binance 크로스체인 브리지에서 수억 달러를 빼돌릴 수 있었습니다.

이 익스플로잇 예제는 프리컴파일러 보안의 필요성과 일탈하는 EVM 구현을 위해 새로운 프리컴파일된 계약을 도입할 때의 잠재적 위험을 보여주기 위한 것입니다.

추가 프리컴파일러를 도입할 때 잠재적으로 치명적인 위험은 다음과 같습니다.
당사자가 배포된 계약의 상태를 일방적으로 수정하도록 허용
여기에는 모든 스토리지 수정(삽입, 업데이트, 삭제)이 포함됩니다.
신뢰할 수 없거나 확인되지 않았거나 감사되지 않은 타사 종속성을 사용합니다.

불확정 노드 내의 값에 대한 액세스를 제공합니다.

컴파일러와 EVM을 완전히 별개의 엔터티로 취급함에도 불구하고 Solidity 컴파일러가 처음 세 개의 미리 컴파일된 계약(ecrecover, sha 256 및 &ripemd)의 동작에 대해 엄격한 가정을 한다는 점은 주목할 가치가 있습니다. 솔리디티 언어. 배후에서 Solidity 컴파일러는 실제로 이러한 키워드를 계약 간의 정적 호출을 실행하는 바이트코드로 처리합니다. 아래 다이어그램은 이러한 계약 간 통신 방법을 자세히 보여줍니다.