저는 Uniswap v4가 곧 모든 사람에게 제공될 것이라고 믿습니다!

이번에 Uniswap 팀은 무제한의 유동성 풀 지원과 각 거래 쌍에 대한 동적 수수료, 싱글톤 설계, 라이트닝 회계, 후크 및 ERC1155 토큰 지원을 포함하여 많은 새로운 기능[1]을 도입하려는 야심 찬 목표와 계획을 가지고 있습니다. 기준. EIP-1153에 의해 도입된 임시 스토리지를 활용하는 Uniswap v4는 Ethereum Cancun 업그레이드 후에 출시될 것으로 예상됩니다.

많은 혁신 중에서 Hook 메커니즘은 강력한 잠재력으로 인해 널리 주목을 받았습니다. 후크 메커니즘은 유동성 풀 수명 주기의 특정 지점에서 특정 코드 실행을 지원하여 풀의 확장성과 유연성을 크게 향상시킵니다. 그러나 후크 메커니즘은 양날의 검이 될 수도 있습니다. 강력하고 유연하지만 Hook을 안전하게 사용하는 것도 큰 도전입니다.

후크의 복잡성으로 인해 필연적으로 새로운 잠재적인 공격 벡터가 발생합니다. 따라서 우리는 Hook 메커니즘과 관련된 보안 문제와 잠재적 위험을 체계적으로 소개하는 일련의 기사를 작성하여 커뮤니티의 보안 발전을 촉진하기를 희망하며 이러한 통찰력이 안전한 Uniswap v4 Hook을 구축하는 데 도움이 될 것이라고 믿습니다. 이 기사 시리즈의 시작으로 이 기사에서는 Uniswap v4의 후크 메커니즘과 관련된 개념을 소개하고 후크 메커니즘의 보안 위험에 대해 간략하게 설명합니다.

1 -Uniswap V4의 메커니즘

이에 대해 알아보기 전에 Uniswap v4의 메커니즘에 대한 기본적인 이해가 필요합니다.

공식 발표 [1] 및 백서 [2]에 따르면 Hooks, 싱글톤 아키텍처 및 라이트닝 회계는 맞춤형 유동성 풀을 구현하고 여러 풀에 걸쳐 효율적인 라우팅을 달성하는 세 가지 중요한 기능입니다. 1.1 HookHook은 유동성 풀 수명 주기의 다양한 단계에서 실행되는 계약을 의미합니다. Uniswap 팀은 Hooks를 도입하여 누구나 절충 결정을 내릴 수 있기를 희망합니다. 이러한 방식으로 동적 수수료를 기본적으로 지원하거나, 온체인 한도 주문을 추가하거나, 시간 가중 평균 시장 조성자(TWAMM)를 통해 대량 주문을 분산시키는 것이 가능합니다.

현재 8개의 Hook 콜백이 4개 그룹으로 나누어져 있습니다(각 그룹에는 한 쌍의 콜백이 포함되어 있습니다).

- 초기화 전/초기화 후

- 수정 전 위치/수정 후 위치

- 스왑 전/스왑 후

-기부 전/후기부

다음은 백서[2]에 소개된 Hooks 교환 과정이다.

- 스왑 전/스왑 후

-기부 전/후기부

다음은 백서[2]에 소개된 Hooks 교환 과정이다.

그림 1: Hook 교환 과정

Uniswap 팀은 몇 가지 예(예: TWAMM Hook[3])를 통해 운영 방법을 소개했으며 커뮤니티 참가자도 일부 기여를 했습니다. 공식 문서[4]는 또한 더 많은 Hook 예제를 수집하는 Awesome Uniswap v4 Hooks[5] 저장소에 연결됩니다.

1.2 싱글톤, 라이트닝 회계 및 잠금 메커니즘

싱글톤 아키텍처와 플래시 회계는 비용을 절감하고 효율성을 보장하여 성능을 향상시키도록 설계되었습니다. 모든 유동성 풀이 동일한 스마트 계약에 유지되는 새로운 싱글톤 계약을 도입합니다. 이 싱글톤 디자인은 PoolManager를 사용하여 모든 풀의 상태를 저장하고 관리합니다.

Uniswap 프로토콜의 이전 버전에서는 유동성 교환이나 추가와 같은 작업에 직접 토큰 전송이 필요했지만, v4 버전에서는 라이트닝 회계 및 잠금 메커니즘을 도입한다는 점에서 다릅니다.

잠금 메커니즘은 다음과 같이 작동합니다.

1. 라커 계약은 PoolManager에 대한 잠금을 요청합니다.

2. PoolManager는 lockData 대기열에 라커 계약의 주소를 추가하고 해당 lockAcquired 콜백을 호출합니다.

3. 라커 계약은 콜백에서 해당 논리를 실행합니다. 실행 중에 라커 계약과 풀의 상호 작용으로 인해 0이 아닌 통화 증가가 발생할 수 있습니다. 그러나 실행이 끝나면 모든 델타는 0으로 설정되어야 합니다. 또한 lockData 큐가 비어 있지 않으면 마지막 라커 계약만 작업을 수행할 수 있습니다.

4. PoolManager는 lockData 대기열 및 통화 증가 상태를 확인합니다. 검증 후 PoolManager는 라커 계약을 삭제합니다. 요약하면 잠금 메커니즘은 동시 액세스를 방지하고 모든 트랜잭션을 지울 수 있도록 보장합니다. 라커 계약은 잠금에 순차적으로 적용한 다음 lockAcquired 콜백을 통해 트랜잭션을 실행합니다. 해당 Hook 콜백은 각 풀 작업 전후에 트리거됩니다. 마지막으로 PoolManager는 상태를 확인합니다.

이 접근 방식은 작업이 즉각적인 이체를 수행하는 대신 내부 순 잔액(즉, 델타)을 조정한다는 것을 의미합니다. 모든 수정 사항은 풀의 내부 잔액에 기록되며 실제 전송은 작업(예: 잠금)이 끝날 때 이루어집니다. 이 프로세스는 미결제 토큰이 없음을 확인하여 자금의 무결성을 유지합니다.

잠금 메커니즘으로 인해 외부 소유 계정(EOA)은 PoolManager와 직접 상호 작용할 수 없습니다. 대신 모든 상호 작용은 계약을 통해 이루어져야 합니다. 이 계약은 중간 보관함 역할을 하며 풀 작업을 수행하기 전에 잠금을 요청해야 합니다.

두 가지 주요 계약 상호 작용 시나리오가 있습니다.

특정 라커 계약은 공식 코드 베이스에서 나오거나 사용자에 의해 배포됩니다. 이 경우 상호작용은 라우터를 통과하는 것으로 생각할 수 있습니다.

특정 라커 계약과 Hook은 동일한 계약에 통합되거나 제3자 개체에 의해 제어됩니다. 이 경우 상호작용은 Hooks를 통해 발생한다고 생각할 수 있습니다. 이 경우 Hook은 라커 계약 역할을 하며 콜백 처리를 담당합니다.

2 - 위협 모델

관련 보안 문제를 논의하기 전에 위협 모델을 식별해야 합니다. 우리는 주로 다음 두 가지 상황을 고려합니다.

위협 모델 I: 후크 자체는 무해하지만 취약점이 있습니다.

위협 모델 II: 후크는 본질적으로 악의적입니다.

다음 섹션에서는 이 두 가지 위협 모델을 기반으로 잠재적인 보안 문제에 대해 논의합니다.

위협 모델 I: 후크 자체는 무해하지만 취약점이 있습니다.

위협 모델 II: 후크는 본질적으로 악의적입니다.

다음 섹션에서는 이 두 가지 위협 모델을 기반으로 잠재적인 보안 문제에 대해 논의합니다.

2.1 위협 모델 I의 보안 문제

위협 모델 I은 후크 자체와 관련된 취약점에 중점을 둡니다. 이 위협 모델은 개발자와 개발자의 후크가 무해하다고 가정합니다. 그러나 스마트 계약의 기존 알려진 취약점도 Hooks에 나타날 수 있습니다. 예를 들어 Hook가 업그레이드 가능한 계약으로 구현되면 OpenZeppelin의 UUPSUpgradeable 취약점과 관련된 문제가 발생할 수 있습니다.

위의 요소를 고려하여 우리는 v4 버전과 관련된 잠재적인 취약점에 초점을 맞추기로 결정했습니다. Uniswap v4에서 Hooks는 코어 풀 작업(초기화, 위치 수정, 교환 및 수집 포함) 전후에 사용자 지정 논리를 실행할 수 있는 스마트 계약입니다. Hooks는 표준 인터페이스를 구현할 것으로 예상되지만 사용자 정의 논리를 포함하는 것도 허용합니다. 따라서 우리의 논의는 표준 Hook 인터페이스와 관련된 로직으로 제한됩니다. 그런 다음 Hooks가 이러한 표준 Hook 기능을 어떻게 남용할 수 있는지와 같이 취약점의 가능한 소스를 식별하려고 노력할 것입니다.

특히 다음 두 가지 유형의 Hook에 중점을 둘 것입니다.

첫 번째 유형의 후크는 사용자 자금을 유지하는 것입니다. 이 경우 공격자는 자금 이체를 위해 이 후크를 공격하여 자산 손실을 초래할 수 있습니다.

두 번째 유형의 후크는 사용자 또는 기타 프로토콜이 의존하는 주요 상태 데이터를 저장합니다. 이 경우 공격자는 위험 상태를 변경하려고 시도할 수 있습니다. 다른 사용자나 프로토콜이 잘못된 상태를 사용하는 경우 잠재적인 위험이 발생할 수 있습니다.

이 두 범위 밖의 후크는 우리 논의 범위를 벗어납니다. 이 글을 쓰는 시점에는 Hooks에 대한 실제 사용 사례가 없으므로 Awesome Uniswap v4 Hooks 저장소에서 몇 가지 정보를 얻을 것입니다. Awesome Uniswap v4 Hooks 리포지토리(커밋 해시 3a0a444922f26605ec27a41929f3ced924af6075)에 대한 심층 연구를 통해 몇 가지 심각한 취약점을 발견했습니다. 이러한 취약점은 주로 후크, PoolManager 및 외부 제3자 간의 위험한 상호 작용에서 발생하며 주로 액세스 제어 문제와 입력 유효성 검사 문제의 두 가지 범주로 나눌 수 있습니다. 구체적인 결과는 아래 표를 참조하세요.

총 22개의 관련 프로젝트를 찾았습니다(Uniswap v4와 관련되지 않은 프로젝트 제외). 이들 프로젝트 중 8개(36%)가 취약하다고 생각됩니다. 취약한 8개 프로젝트 중 6개는 액세스 제어 문제가 있었고 2개는 신뢰할 수 없는 외부 호출에 취약했습니다.

2.1.1 접근 제어 문제

이 부분에서는 주로 8 후크 콜백 및 잠금 콜백을 포함하여 v4의 콜백 함수로 인해 발생할 수 있는 문제에 중점을 둡니다. 물론 확인해야 할 다른 상황도 있지만 이러한 상황은 설계에 따라 다르며 논의 범위를 벗어납니다.

이러한 함수는 PoolManager에서만 호출해야 하며 다른 주소(EOA 및 계약 포함)에서는 호출할 수 없습니다. 예를 들어, 풀 키로 보상을 분배하는 경우 해당 기능을 어떤 계정에서든 호출할 수 있는 경우 보상이 잘못 청구될 수 있습니다.

따라서 특히 후크가 풀 자체가 아닌 다른 당사자에 의해 호출될 수 있으므로 후크에 대한 강력한 액세스 제어 메커니즘을 설정하는 것이 중요합니다. 접근 권한을 엄격하게 관리함으로써 유동성 풀은 후크와의 무단 또는 악의적인 상호 작용의 위험을 크게 줄일 수 있습니다.

2.1.2 입력 확인 질문

Uniswap v4에서는 잠금 메커니즘으로 인해 사용자는 자금 풀 작업을 수행하기 전에 계약을 통해 잠금을 획득해야 합니다. 이는 현재 상호작용에 참여하고 있는 계약이 최신 라커 계약임을 보장합니다. 그럼에도 불구하고 여전히 가능한 공격 시나리오, 즉 일부 취약한 Hook 구현에서 부적절한 입력 유효성 검사로 인해 신뢰할 수 없는 외부 호출이 있습니다.

Uniswap v4에서는 잠금 메커니즘으로 인해 사용자는 자금 풀 작업을 수행하기 전에 계약을 통해 잠금을 획득해야 합니다. 이는 현재 상호작용에 참여하고 있는 계약이 최신 라커 계약임을 보장합니다. 그럼에도 불구하고 여전히 가능한 공격 시나리오, 즉 일부 취약한 Hook 구현에서 부적절한 입력 유효성 검사로 인해 신뢰할 수 없는 외부 호출이 있습니다.

첫째, 후크는 사용자가 상호 작용하려는 풀을 확인하지 않습니다. 이는 가짜 토큰을 포함하고 유해한 논리를 실행하는 악성 풀일 수 있습니다.

둘째, 일부 키 후크 기능은 임의의 외부 호출을 허용합니다.

신뢰할 수 없는 외부 호출은 재진입 공격을 포함하여 다양한 유형의 공격으로 이어질 수 있으므로 매우 위험합니다. 이러한 취약한 Hook을 공격하기 위해 공격자는 자신의 가짜 토큰에 대해 악의적인 자금 풀을 등록한 다음 Hook을 호출하여 자금 풀에서 작업을 수행할 수 있습니다. 풀과 상호 작용할 때 악의적인 토큰 논리는 바람직하지 않은 동작에 참여하기 위해 제어 흐름을 탈취합니다.

2.1.3 위협 모델 I에 대한 예방 조치

후크와 관련된 보안 문제를 피하려면 민감한 외부/공용 기능에 필요한 액세스 제어를 적절하게 적용하고 입력 매개변수의 유효성을 검사하여 상호작용을 인증하는 것이 중요합니다. 또한 재진입 보호는 표준 논리 흐름에서 후크가 반복적으로 실행되지 않도록 하는 데 도움이 될 수 있습니다. 풀은 적절한 보안 보호 장치를 구현함으로써 그러한 위협과 관련된 위험을 줄일 수 있습니다.

2.2 위협 모델 II의 보안 문제

이 위협 모델에서는 개발자와 그의 후크가 악의적이라고 가정합니다. 범위가 넓기 때문에 v4 버전과 관련된 보안 문제에만 중점을 둡니다. 따라서, 제공된 후크가 사용자가 전송하거나 승인한 암호화폐 자산을 처리할 수 있는지 여부가 핵심입니다. 후크에 액세스하는 방법에 따라 후크에 부여될 수 있는 권한이 결정되므로 후크를 두 가지 범주로 나눕니다.

관리되는 후크: 후크는 진입점이 아닙니다. 사용자는 라우터(Uniswap에서 제공)를 통해 후크와 상호 작용해야 합니다.

독립형 후크: 후크는 사용자가 직접 상호 작용할 수 있는 진입점입니다.

그림 2: 악성 Hook의 예

2.2.1 관리되는 후크

이 경우 사용자의 암호화 자산(기본 토큰 및 기타 토큰 포함)이 라우터로 전송되거나 승인됩니다. PoolManager는 잔액 확인을 수행하므로 악의적인 후크가 이러한 자산을 직접 훔치는 것은 쉽지 않습니다. 그러나 여전히 잠재적인 공격 표면이 있습니다. 예를 들어, v4 버전의 비용 관리 메커니즘은 공격자가 후크를 통해 조작할 수 있습니다.

2.2.2 독립 후크 후크가 진입점으로 사용되는 경우 상황은 더욱 복잡해집니다.

이 경우 사용자가 직접 상호 작용할 수 있기 때문에 후크가 더 많은 힘을 얻습니다. 이론적으로 후크는 이 상호 작용을 통해 원하는 모든 작업을 수행할 수 있습니다. v4 버전에서는 코드 로직 검증이 매우 중요합니다. 가장 큰 문제는 코드 로직을 조작할 수 있는지 여부입니다. 후크를 업그레이드할 수 있는 경우 이는 안전해 보이는 후크가 업그레이드 후에는 악의적인 후크가 되어 상당한 위험을 초래할 수 있음을 의미합니다. 이러한 위험에는 다음이 포함됩니다.

업그레이드 가능한 에이전트(직접 공격 가능)

자기 파괴 논리를 사용합니다. 자멸 및 생성을 공동 호출하는 경우 공격 가능2.

2.2.3 위협 모델 II에 대한 예방 조치

업그레이드 가능한 에이전트(직접 공격 가능)

자기 파괴 논리를 사용합니다. 자멸 및 생성을 공동 호출하는 경우 공격 가능2.

2.2.3 위협 모델 II에 대한 예방 조치

후크가 악성인지 평가하는 것이 중요합니다. 특히 관리형 후크의 경우 비용 관리 동작에 중점을 두어야 하며, 독립형 후크의 경우 주요 초점은 업그레이드 가능 여부입니다. - 3 -결론 본 글에서는 먼저 Uniswap v4의 Hook 보안 문제와 관련된 핵심 메커니즘을 간략하게 설명합니다. 이어서 우리는 두 가지 위협 모델을 제안하고 관련 보안 위험에 대해 간략하게 설명합니다. 후속 기사에서는 각 위협 모델에 따른 보안 문제에 대한 심층 분석을 수행할 것입니다. 계속 지켜봐주세요!