장미의 가시: 유니스왑 v4의 새로운 훅 메커니즘의 보안 위험 탐구

Uniswap v4가 출시를 앞두고 있습니다! 개발팀은 각 거래 쌍에 대한 (이론적으로) 무제한의 풀과 동적 수수료율, 싱글톤, 플래시 어카운팅, 훅, ERC1155 지원을 포함한 다양한 새로운 기능[1]을 도입할 야심찬 계획을 가지고 있습니다. EIP-1153에서 도입된 임시 저장소를 활용하는 Uniswap v4는 이더리움의 Cancun 업그레이드 이후 출시될 것으로 예상됩니다.

이러한 혁신들 중에서 훅(hook) 메커니즘은 강력한 잠재력으로 인해 상당한 주목을 받고 있습니다. 이는 풀 운영 중 특정 시점에 특정 코드를 실행할 수 있게 하여, 풀의 확장성과 유연성을 크게 향상시킵니다.

그러나 훅 메커니즘은 양날의 검이 될 수도 있습니다. 강력하고 유연한 만큼, 이를 안전하게 활용하는 것의 어려움을 간과할 수 없습니다. 이러한 복잡성은 필연적으로 새로운 잠재적 공격 벡터를 열어줍니다. 보안 관점에서 커뮤니티에 기여하고자, 이 메커니즘과 관련된 보안 문제와 우려 사항을 체계적으로 살펴보는 일련의 글을 제시하는 것이 우리의 목표입니다. 이러한 통찰이 안전한 Uniswap v4 훅 구축에 도움이 되기를 바랍니다.

이 글은 시리즈의 첫 번째로, 독자들을 위한 포괄적인 개요와 기초적인 이해를 제공합니다. 앞으로의 심층적인 논의도 기대해 주세요!

Uniswap v4의 메커니즘

세부 사항을 살펴보기 전에, Uniswap v4의 메커니즘에 대한 기본적인 이해가 필요합니다. 공식 발표[1]와 백서[2]에 따르면, 훅, 싱글톤 아키텍처, 플래시 어카운팅은 풀 커스터마이징과 여러 풀 간의 효율적인 라우팅을 가능하게 하는 세 가지 핵심 기능입니다.

훅(Hooks)

v4의 훅은 풀 작업의 생명 주기 중 다양한 시점에서 실행되는 계약인 훅을 통해 누구나 트레이드오프 결정을 내릴 수 있도록 설계되었습니다. 이를 통해 동적 수수료를 기본적으로 지원하는 풀을 커스터마이징하거나, 온체인 지정가 주문을 추가하거나, 대규모 주문을 시간에 걸쳐 분산시키는 시간 가중 평균 시장 조성자(TWAMM)로 활용할 수 있습니다.

현재 여덟 가지 훅 콜백이 있으며, 네 그룹으로 나뉩니다(각 그룹에는 한 쌍의 콜백이 포함됩니다):

beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate

아래는 백서[2]에서 제공하는 스왑 훅의 흐름을 보여줍니다.

Uniswap 팀은 TWAMM 훅[3] 등의 예시를 제공하여 사용법을 시연했으며, 커뮤니티 참여자들도 기여하고 있습니다. 공식 문서[4]는 더 많은 훅 예시를 수집한 Awesome Uniswap v4 Hooks[5] 저장소로 연결됩니다.

싱글톤, 플래시 어카운팅 및 잠금 메커니즘

싱글톤 아키텍처와 플래시 어카운팅은 비용을 줄이고 효율성을 보장하여 성능을 향상시키도록 설계되었습니다. 구체적으로, 모든 풀이 단일 스마트 계약 내에 존재하는 새로운 싱글톤 계약을 도입합니다. 이 싱글톤 설계는 모든 풀의 모든 상태를 저장하고 관리하는 PoolManager에 의존합니다.

스왑이나 유동성 추가와 같은 작업에서 직접적인 토큰 전송이 이루어졌던 이전 버전의 Uniswap 프로토콜과 달리, Uniswap v4는 잠금 메커니즘과 함께 플래시 어카운팅을 도입합니다.

구체적으로, 잠금 메커니즘은 다음과 같이 작동합니다:

로커 계약이 PoolManager에 잠금을 요청합니다.
PoolManager는 로커의 주소를 lockData 대기열에 추가하고 lockAcquired 콜백을 호출합니다.
로커는 콜백에서 로직을 실행합니다. 로커의 실행 중에 풀과의 상호작용으로 인해 통화 델타가 0이 아닌 값이 될 수 있습니다. 그러나 실행이 끝날 때까지 모든 델타는 0으로 정산되어야 합니다. 또한, lockData 대기열이 비어 있지 않은 경우 마지막 로커만 작업을 수행할 수 있습니다.
이후, PoolManager는 lockData 대기열과 통화 델타의 상태를 확인합니다. 검증이 완료되면 PoolManager는 로커를 제거합니다.

요약하면, 잠금 메커니즘은 동시 접근을 방지하고 정산을 보장합니다. 로커는 잠금을 위해 대기열에 들어간 후 lockAcquired 콜백을 통해 실행됩니다. 풀 작업 전후에 지정된 훅 콜백이 호출됩니다. 마지막으로 PoolManager가 상태를 확인합니다.

이 접근 방식은 즉각적인 전송을 실행하는 대신, 내부 순 잔액(즉, 델타)을 조정하는 방식으로 작업이 이루어짐을 의미합니다. 모든 수정 사항은 풀의 내부 잔액에 기록되며, 실제 전송은 작업이 끝날 때(즉, 잠금) 이루어집니다. 이 과정은 미결 토큰이 없음을 보장하여 지급 능력을 유지합니다.

잠금 메커니즘으로 인해 EOA(외부 소유 계정)는 PoolManager와 직접 상호작용할 수 없습니다. 대신 모든 상호작용은 계약을 통해 이루어져야 합니다. 계약은 풀 작업 전에 잠금을 요청하는 중간 로커 역할을 합니다. 주로 두 가지 계약 상호작용 시나리오가 있습니다:

로커 계약이 공식 저장소에서 제공되거나 사용자가 배포한 경우. 이 경우, 상호작용을 라우터를 통한 것으로 볼 수 있습니다.
로커와 훅이 동일한 계약에 통합되거나 제3자 엔티티에 의해 제어되는 경우. 이 시나리오에서는 상호작용을 훅을 통한 것으로 볼 수 있습니다. 따라서 훅은 로커와 콜백 핸들러의 이중 역할을 수행합니다.

위협 모델

보안 문제를 논의하기 전에 위협 모델을 결정해야 합니다. 기본적으로 훅을 사용할 때 다음과 같은 고려 사항이 발생합니다:

위협 모델 I: 훅이 선의이지만 취약한 경우.
위협 모델 II: 훅이 악의적인 경우.

다음 섹션에서는 위협 모델에 기반한 잠재적인 보안 문제/우려 사항을 논의합니다.

위협 모델 I의 보안 우려 사항

위협 모델 I은 훅 자체와 관련된 취약점에 초점을 맞춥니다. 이 위협 모델은 개발자와 그들의 훅이 선의임을 가정합니다. 그러나 스마트 계약의 기존에 알려진 취약점이 훅에서도 발생할 수 있습니다. 예를 들어, 훅이 업그레이드 가능한 계약으로 구현된 경우 OZ 라이브러리의 UUPSUpgradeable 취약점[6]과 유사한 취약점이 발생할 수 있습니다.

이러한 고려 사항을 감안하여, 우리는 v4에 특화된 잠재적 취약점에 집중하기로 했습니다. 구체적으로, Uniswap v4에서 훅은 핵심 풀 작업(초기화, 포지션 수정, 스왑, 기부 포함) 전후에 로직을 실행할 수 있는 커스터마이징 가능한 스마트 계약입니다. 훅은 표준 훅 인터페이스를 구현할 것으로 예상되지만, 커스터마이징된 로직을 포함할 수도 있습니다. 따라서 우리의 범위는 표준 훅 인터페이스와 관련된 로직으로 제한됩니다. 그런 다음 훅이 이러한 표준 훅 함수를 어떻게 활용할 가능성이 있는지 요약하여 잠재적인 취약점 원인을 파악할 수 있습니다.

넓게 보면, 훅은 두 가지 범주로 나뉩니다:

사용자 자금의 보관자 역할을 하는 훅. 이 경우, 공격자는 자금을 이전하기 위해 훅을 표적으로 삼아 자산 손실을 초래할 수 있습니다.
사용자 또는 다른 프로토콜이 의존하는 중요한 상태 데이터를 저장하는 훅. 이러한 훅의 경우, 공격자는 의도적으로 중요한 상태를 변경할 수 있습니다. 잘못된 상태가 다른 사용자나 프로토콜에 의해 사용될 때 잠재적인 위험이 발생합니다.

이 두 가지 범주에 해당하지 않는 훅은 우리 논의의 범위에 포함되지 않습니다.

제한된 범위에도 불구하고, 여기서 모든 가능성을 열거하는 것은 여전히 불가능합니다. 이 글을 작성하는 시점에는 실제 애플리케이션이 없으므로, 일부 통찰을 얻기 위해 Awesome Uniswap v4 Hooks 저장소를 살펴보기로 했습니다.

저장소(커밋 해시 3a0a444922f26605ec27a41929f3ced924af6075)를 철저히 검토한 후, 여러 중요한 취약점을 발견했습니다. 이들은 주로 훅, PoolManager, 외부 제3자 간의 위험한 상호작용에서 비롯됩니다. 취약점은 크게 두 가지 범주로 나뉩니다: 결함 있는 접근 제어와 부적절한 입력 유효성 검사. 발견된 내용은 아래 표에 요약되어 있습니다:

# 결함 있는 프로젝트 수	# 결함 있는 접근 제어 수	# 부적절한 입력 유효성 검사 수
8	6	2

전반적으로, 22개의 관련 프로젝트를 확인했습니다(Uniswap v4와 무관해 보이는 것은 제외). 이 중 8개(약 36%)가 취약한 것으로 판단되었습니다. 구체적으로, 취약한 프로젝트 6개에서 결함 있는 접근 제어가 발견되었으며, 2개는 신뢰할 수 없는 외부 호출에 취약했습니다.

결함 있는 접근 제어

이 논의에서는 v4의 콜백 함수에서 비롯된 v4 관련 접근 제어 문제에 초점을 맞춥니다. 여기에는 8개의 훅 콜백과 잠금 콜백이 포함됩니다. 물론 다른 경우도 검증이 필요할 수 있습니다. 그러나 이러한 경우는 설계에 따라 다르므로, 앞서 논의한 범위를 벗어납니다.

이 함수들은 다른 주소(EOA 및 계약 포함)가 아닌 PoolManager에 의해서만 호출되어야 합니다. 예를 들어, 풀 키에 의해 보상이 분배되는 상황을 생각해보세요. 해당 함수가 임의의 계정에 의해 호출될 수 있다면, 보상이 잘못 청구될 수 있습니다.

이를 감안할 때, 훅에 대한 강력한 접근 제어 메커니즘을 구축하는 것이 중요합니다. 특히 훅은 풀 자체 이외의 당사자에 의해 호출될 수 있기 때문입니다. 접근 권한을 신중하게 관리함으로써, 풀은 훅과의 무단 또는 악의적인 상호작용 위험을 크게 줄일 수 있습니다.

부적절한 입력 유효성 검사

Uniswap v4에서는 잠금 메커니즘으로 인해 사용자는 풀 작업을 실행하기 전에 계약을 통해 잠금을 획득해야 합니다. 이는 현재 상호작용하는 계약이 최신 로커임을 보장합니다.

그럼에도 불구하고, 일부 취약한 훅 구현에서 부적절한 입력 유효성 검사로 인한 신뢰할 수 없는 외부 호출이라는 잠재적인 공격 시나리오가 존재합니다:

첫째, 훅이 사용자가 상호작용하려는 풀을 검증하지 않습니다. 이는 가짜 토큰을 보유하고 유해한 로직을 실행하는 악의적인 풀일 수 있습니다.
둘째, 일부 중요한 훅 함수가 임의의 외부 호출을 허용합니다.

신뢰할 수 없는 외부 호출은 잘 알려진 재진입 문제를 포함한 다양한 유형의 공격으로 이어질 수 있기 때문에 매우 위험합니다.

이러한 취약한 훅을 악용하기 위해, 공격자는 가짜 토큰에 대한 악의적인 풀을 등록한 다음, 훅을 호출하여 풀에서 작업을 실행할 수 있습니다. 풀과 상호작용할 때, 악의적인 토큰 로직이 제어 흐름을 가로채 악의적인 행동을 촉진합니다.

위협 모델 I에 대한 완화 방안

훅과 관련된 이러한 문제를 방지하기 위해서는 민감한 외부/공개 함수에 대한 적절한 접근 제어를 시행하고 입력 인수를 검증하여 상호작용을 유효성 검사하는 것이 필수적입니다. 또한, 재진입 가드가 표준 로직 흐름 내에서 훅이 반복적으로 실행되지 않도록 하는 데 도움이 될 수 있습니다. 적절한 안전장치를 마련함으로써 풀은 이러한 유형의 위협과 관련된 위험을 완화할 수 있습니다.

위협 모델 II의 보안 우려 사항

이 위협 모델에서는 개발자와 그들의 훅이 악의적이라고 가정합니다. 광범위한 가능성을 고려하여, v4와 관련된 문제에 주로 초점을 맞추기로 했습니다. 따라서 핵심 고려 사항은 제공된 훅이 사용자가 전송하거나 승인한 암호 자산을 처리할 수 있는지 여부입니다.

훅에 접근하는 방법에 따라, 훅에 부여된 잠재적 권한이 결정되며, 훅을 두 가지 범주로 분류할 수 있습니다:

관리형 훅: 훅이 진입점이 아닙니다. 사용자는 Uniswap이 제공하는 라우터를 통해 훅과 상호작용해야 합니다.
독립형 훅: 훅이 진입점으로, 사용자가 직접 상호작용할 수 있습니다.

관리형 훅

관리형 훅의 경우, 사용자의 암호 자산(네이티브 토큰 및 기타 포함)은 라우터로 전송되거나 승인됩니다. PoolManager에 의해 적용되는 잔액 확인으로 인해, 악의적인 훅이 이러한 자산을 직접 수집하는 것은 간단하지 않습니다.

그러나 잠재적인 공격 표면은 여전히 존재합니다. 예를 들어, v4의 수수료 관리 메커니즘은 훅을 통해 공격자에 의해 조작될 가능성이 있습니다.

독립형 훅

훅이 독립형 훅의 형태로 진입점으로 사용될 때 상황은 더욱 복잡해집니다. 이 시나리오에서 훅은 사용자가 직접 상호작용할 수 있으므로 더 많은 권한을 갖게 됩니다. 이론적으로 훅은 이 상호작용을 통해 원하는 모든 작업을 수행할 수 있습니다.

v4 시나리오에서 코드 로직의 유효성 검사가 중요한 포인트입니다. 주요 관심사는 코드 로직이 조작될 수 있는지 여부입니다. 훅은 업그레이드 가능하게 구현될 수 있으며, 이는 안전해 보이는 훅이 나중에 악의적인 것으로 업그레이드될 수 있어 상당한 위험을 초래할 수 있습니다. 여기에는 다음이 포함됩니다:

직접 악용될 수 있는 업그레이드 가능한 프록시;
selfdestruct와 create2의 결합 사용으로 악용될 수 있는 자기 파괴 로직이 장착된 경우.

위협 모델 II에 대한 완화 방안

훅이 악의적인지 여부를 평가하는 것이 필수적입니다. 구체적으로, 관리형 훅의 경우 수수료 관리 동작에 집중해야 하며, 독립형 훅의 경우 업그레이드 가능 여부가 주요 관심사입니다.

결론

이 글에서는 먼저 v4 훅의 보안 문제와 관련된 Uniswap v4의 핵심 메커니즘에 대한 간략한 요약을 제공했습니다. 그 다음, 두 가지 위협 모델을 정의하고 각각의 보안 문제에 대한 높은 수준의 논의를 제공했습니다. 이 시리즈의 다음 글에서는 각 위협 모델 하에서의 보안 문제에 대한 자세한 분석을 제공할 것입니다. 기대해 주세요!