EIP-3074에 대한 비판과 단순 교체

以太坊爱好者

特邀专栏作者

2021-06-29 09:00 (UTC+8)

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

AUTH 커밋에 서명하는 것이 취약하거나 악의적인 계약과 관련된 트랜잭션에 서명하는 것보다 더 위험한 이유는 무엇입니까?

AI 요약

펼치기

AUTH 커밋에 서명하는 것이 취약하거나 악의적인 계약과 관련된 트랜잭션에 서명하는 것보다 더 위험한 이유는 무엇입니까?

개발자에게 AUTH/AUTHCALL 메커니즘은 매우 매력적입니다. 호출자를 생성하여 다양한 일괄 처리 전략(예: 더 나은 병렬 처리를 위한 여러 논스 지원), 가스 추상화 모델, 복잡한 계정 추상화 방법 등을 구현할 수 있습니다.

이러한 유연성은 이 메커니즘이 개발자에게 제공하는 큰 자유에서 비롯됩니다. AUTH/AUTHCALL 메커니즘은 개발자가 특정 패턴을 따르도록 요구하지 않지만 사용자가 커밋 해시 값에 서명하도록 요구합니다(커밋 콘텐츠는 호출자가 구문 분석함). 개발자는 커밋을 기반으로 자체 제한을 설정할 수 있습니다.

그러나 이러한 유연성은 보안을 희생합니다. 이 기사에서는 더 간단한 대안을 소개하고자 합니다. 이 솔루션은 AUTH/AUTHCALL 메커니즘의 장점을 대부분 가지고 있지만 위험은 후자보다 훨씬 낮습니다.

AUTH 커밋에 서명하는 것이 취약하거나 악의적인 계약과 관련된 트랜잭션에 서명하는 것보다 더 위험한 이유는 무엇입니까?

사용자가 계약 관련 거래에 서명할 때 사용자가 감수할 위험, 즉 계약 통제 범위 내의 자산이 손실될 수 있음을 알 수 있습니다. 사용자가 악의적인 DEX 계약을 승인하는 ERC 20 계약에 대한 승인 거래에 서명했다고 가정해 보겠습니다. 이 악의적인 DEX 계약은 ERC 20 계약에서 사용자의 전체 잔액을 인출할 수 있습니다. 그러나 사용자가 승인하지 않는 한 사용자의 다른 ERC 20 계약에서 토큰을 인출할 수 없습니다. 또한 독점적인 사용자 승인이 필요하므로 사용자를 대신하여 다른 작업을 수행할 수 없습니다.

대조적으로, EIP 3074는 사용자가 "백지 수표"에 서명할 것을 요구할 뿐만 아니라 발신자가 정직하고 취약성이 없다고 가정합니다. 악의적인/취약한 호출자는 사용자를 대신하여 사용자가 보유한 자산에 액세스하고, 사용자를 대신하여 투표하고, 사용자가 소유한 계약을 제어하는 등의 모든 작업을 수행할 수 있습니다.

더 나쁜 것은 nonce 구현이 호출자의 제어하에 있기 때문에 호출자는 언제든지 악을 행할 수 있습니다. 난스 로직의 취약하고 악의적인 구현은 사용자의 과거 트랜잭션을 재생할 수 있습니다. 커밋 확인의 다른 부분의 논리도 취약한 경우 호출자는 이 논스 논리 구현을 사용하여 사용자를 대신하여 모든 작업을 수행할 수 있습니다. 취약점이 발견되더라도 이용자는 백지체크를 철회할 수 없습니다. 이 외부 계정(EOA)은 영구적으로 손상되었습니다.

올바른 호출자 프로그램을 작성하는 것은 어렵고 EIP 3074의 끝에서 호출자가 주의해야 하는 검사/취약점/상황의 전체 목록에서 알 수 있듯이 호출자가 때때로 버그아웃할 것이라고 거의 확신합니다. 고통스러운 검색 프로세스로 인해 목록이 더 길어질 수 있습니다.

또한 악의적인 행위자는 무해해 보이는 호출자 프로그램을 작성할 수 있지만 많은 수의 외부 계정이 호출자에게 권한을 부여할 때까지 공격자가 악용하지 않는 미묘한 취약점을 의도적으로 남길 수 있습니다.

보조 제목

거버넌스 하이재킹 예

악의적인 탈중앙화 거래소 EveSwap은 사용자를 위해 호출자 프로그램을 작성했습니다. 이 호출자 프로그램은 EVE 토큰을 에어드롭하여 사용자에게 가스 자금을 제공하고 사용자 승인 및 전송 트랜잭션을 일괄 처리합니다.
EveSwap의 호출자 프로그램은 무해해 보이며 즉시 공개되기 때문에 사용자의 토큰을 절대 훔치지 않습니다.
사용자는 행복합니다. 거래는 모두 성공적이었고 거래 수수료는 저렴했습니다. 별 일 없는 몇 달이었다.
그러나 누군가가 EveSwap을 사용하여 AliceSwap의 거버넌스 토큰 ALI를 거래할 때마다 사용자의 AliceSwap 투표권은 자동으로 EveSwap에 위임됩니다.
승인된 수가 특정 임계값에 도달하면 EveSwap은 거버넌스 제안을 통해 AliceSwap을 하이재킹합니다.

보조 제목

교차 체인 재생의 예

EIP 3074는 커밋에 체인 ID를 포함해야 한다고 합리적으로 제안합니다. 그러나 이것은 프로토콜이 아니라 호출자에 의해 시행됩니다. 다른 체인에서 동일한 주소를 가진 발신자는 이 검사를 건너뛸 수 있습니다(또는 해당 문제에 대한 검사).

EveSwap은 EIP 3074를 지원하는 EVM 호환 BobSpongeChain에서 실행됩니다. EveSwap은 BobSpongeChain에 정직한 호출자를 배포합니다.
사용자는 이 호출자를 사용하여 BobSpongeChain에서 거래한 다음 브리지를 사용하여 자산을 Ethereum으로 전송합니다.
EveSwap은 동일한 배포 키를 사용하여 Ethereum에 동일한 주소를 가진 다른 호출자를 배포합니다. Ethereum의 이 호출자는 커밋을 확인하지 않고 ownerOnly만 확인하며 소유자에 대한 일반 AUTH/AUTHCALL 프록시 역할을 합니다.
이러한 방식으로 EveSwap은 Ethereum에서 사용자의 외부 계정을 탈취하고 자산을 탈취할 수 있습니다.

사용자는 Ethereum에서 거래한 적이 없으며 BobSpongeChain에서 실행되는 호출자 프로그램은 엄격한 보안 검토를 거쳤습니다. 그럼에도 불구하고 사용자는 전체 자산을 잃었습니다.

보조 제목

또 무엇을 할 수 있습니까?

내 제안은 프로토콜 수준에서 커밋의 의미를 강화하는 보다 명시적인 메커니즘을 구현하는 것입니다. 커밋 구조가 입력되고(EIP 712에 설명된 대로) 지갑은 사용자가 읽을 수 있는 형식으로 커밋을 표시합니다. 사용자는 트랜잭션이 어떻게 생겼는지 정확히 알 수 있으며 호출 프로그램 개발자의 특성과 능력에 의존하지 않고 이 트랜잭션이 어떤 체인에서도 재생되지 않을 것이라고 확신할 수 있습니다.

가능한 구현:

AUTH는 커밋 해시를 승인된 호출 목록을 포함하는 형식화된 구조체로 대체합니다. 각 호출은 {nonce,to,gas,calldata,value,chainid}를 지정합니다. 서명이 확인되고 승인된 호출의 전체 목록이 승인된 주소 변수 대신 authorized_transactions로 저장됩니다.

AUTHCALL은 마지막 AUTH에 의해 생성된 목록의 주소를 가리키는 새 매개변수 인덱스를 가져옵니다.

사용자 주소의 nonce는 AUTHCALL로 증가합니다. nonce는 호출자에 의해 저장되지 않고 실제 계정 nonce에 저장됩니다.

이익: