https://secureum.substack.com/p/audit-findings-201

102. 훅(Hook) 수신자 계약의 잠재적 예외 상황 문서화 필요

• withdrawTokenAndCall() 및 withdrawTokenAndCallOnBehalf() 함수는 출금하는 스텔스 주소 소유자가 지정한 훅(Hook) 계약을 호출합니다.

  그러나 Umbra 계약 자체에서는 이 호출의 파라미터에 대한 제약이 거의 없습니다.

  • 누구나 자신이 제어하는 주소에 소량의 토큰을 전송한 뒤, 출금 시 원하는 훅 수신자 주소를 지정해 해당 계약을 강제로 호출 가능
  • 훅 수신자 계약(UmbraHookReceiver)이 이를 검증하지 않으면 의도치 않은 호출이나 악의적인 파라미터 입력 가능성 존재

• 영향

  • 악성 훅 호출 유도 가능
  • 잘못된 파라미터로 인한 예기치 않은 로직 실행
  • 보안 취약점 발생 시 자금 손실 가능

• 권장 조치

  • 훅 수신자(UmbraHookReceiver) 구현 시 반드시 tokensWithdrawn() 호출자의 신원 검증
  • 함수 파라미터에 대한 유효성 검사 수행
  • 개발 문서에 이러한 잠재적 위험과 안전한 구현 지침을 명시

• 심각도: 정보 제공/문서화 필요 (Informational)

• 출처: ConsenSys Audit – Umbra

103. 토큰 동작 제약 사항 문서화 필요

• Umbra 프로토콜은 임의의 ERC20 토큰과 상호작용할 수 있으므로, 지원되는 토큰의 동작 명세를 명확히 문서화하는 것이 중요합니다.

  특정 클래스의 토큰 및 그 상호작용을 충분히 검토하기 전까지는, 예상 ERC20 동작 사양을 준수하는 토큰만 지원하는 것이 바람직합니다.

• 문제점

  Umbra 프로토콜은 다음과 같은 표준 ERC20에서 벗어난 토큰에 대해 취약하거나 비정상적인 동작을 보일 수 있음:

  1. 디플레이션(Deflationary) / 전송 수수료 부과(Fee-on-transfer) 토큰
     • 수신자가 전송한 금액만큼 잔액이 증가하지 않음
     • 일부 메커니즘에서 잔액이 예상치 못하게 감소할 수 있음
     • sendToken() 호출은 가능하나, Umbra 내부 회계와 실제 토큰 계약의 잔액이 불일치 → 자금 손실 가능
  2. 인플레이션(Inflationary) 토큰
     • 잔액이 예상치 못하게 증가
     • Umbra는 잔액 증가분을 청구할 수 있는 메커니즘이 없음
  3. 리베이싱(Rebasing) 토큰
     • 공급량 확장·축소에 따라 잔액이 증가하거나 감소
     • Umbra는 이러한 변화를 반영할 수 없으며, 내부 회계가 불일치 → 자금 손실 가능

• 권장 조치

  • 사용자 문서에 지원하지 않는 토큰 유형을 명확히 명시
  • 프로토콜 동작 보장을 위해 지원 ERC20 동작 사양 제공
  • ERC20 동작이 표준에서 벗어난 경우, 별도의 검토 및 테스트 후에만 지원 결정

• 심각도: 정보 제공/문서화 필요 (Informational)

• 출처: ConsenSys Audit – Umbra