Риск модулей мультиподписи: какие разрешения обходят порог?

Включённый модуль может выполнять операции из аккаунта с мультиподписью без обычного порога владельцев. Узнайте, как проверять модули, Guard, Fallback Handler, обновления и пути восстановления.

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Включённый модуль — это отдельный путь авторизации. В смарт-аккаунтах типа Safe одобренный модуль может вызвать execTransactionFromModule и выполнить CALL или DELEGATECALL, не собирая для этой операции обычные подписи владельцев M-из-N. Поэтому отображаемый порог описывает лишь один путь выполнения, а не полную границу безопасности аккаунта.

Модули обеспечивают полезную автоматизацию: лимиты расходов, регулярные платежи, восстановление и операции протокола. Однако их полномочия могут быть широкими: официальный контракт Safe указывает, что включённые модули могут выполнять произвольные транзакции, и предупреждает, что вредоносный модуль способен захватить Safe. Проверяйте каждый включённый модуль, а не только владельцев и порог.

Как это работает

Сначала владельцы авторизуют enableModule обычной транзакцией Safe. Аккаунт сохраняет модуль в реестре включённых модулей. Позже модуль сам проверяет вызывающего и свои правила, затем вызывает execTransactionFromModule; аккаунт убеждается, что вызывающий включён, и выполняет запрошенную операцию. Безопасность теперь также зависит от кода, конфигурации, администраторов, ключей обновления и внешних зависимостей модуля.

Guard транзакций и Module Guard — разные средства контроля. Первый проверяет обычные вызовы execTransaction, второй — вызовы, инициированные модулями. Guard может отклонить выполнение, но неисправный или чрезмерно строгий Guard способен также вызвать отказ в обслуживании. Установите, какой тип используется, что он проверяет и как его восстановить или удалить.

Fallback Handler — ещё одна точка расширения. Когда calldata не соответствует основной функции аккаунта, аккаунт перенаправляет вызов настроенному Handler и добавляет адрес исходного вызывающего. Handler может добавить проверку подписей и обратные вызовы токенов, но небезопасная логика или конфигурация создаёт дополнительную поверхность разрешений и интерпретации.

Пример

Казначейство использует порог владельцев 3-of-5 и включает модуль лимитов для обычных платежей. Модуль обновляемый, а администратор обновления — один горячий кошелёк. При компрометации ключа атакующий может обновить модуль, воспользоваться модульным путём и перевести активы без 3 подписей. Порог 3-of-5 остаётся неизменным, но не регулирует этот путь.

Проверка должна определить адрес и верифицированную реализацию модуля, прокси и администратора, лимиты расходов, разрешённые цели и селекторы функций, допустимость DELEGATECALL, установленный Module Guard, Fallback Handler и точную транзакцию для отключения модуля. Проверяйте значения в контрактах аккаунта и связанных прокси в каждой сети, а не только в интерфейсе кошелька.

Риски

Риск полномочий: Уязвимый или вредоносный модуль может переводить активы, одобрять расходующие адреса, менять состояние через DELEGATECALL или вызывать другие привилегированные контракты. Ограниченный интерфейс не доказывает ограниченность полномочий в сети.
Риск контроля и обновления: Прокси модуля, администратор, оракул, исполнитель автоматизации или ключ восстановления могут свести видимую схему 3-of-5 к меньшему фактическому набору контроля. Проследите каждый путь обновления и настройки до конечных подписантов и задержек.
Риск доступности: Неисправный Guard может блокировать корректные транзакции, а скомпрометированный модуль — действовать быстрее, чем владельцы согласуют его удаление. Проверьте отключение и восстановление, отслеживайте изменения модуля, Guard и Handler и сохраняйте путь реагирования, не зависящий от удаляемого компонента.

Распространённые заблуждения

Заблуждение 1: «Аккаунт использует 3-of-5, значит каждый перевод требует 3 подписей». Порог применяется к обычному пути владельцев; включённые модули могут использовать другую политику авторизации.
Заблуждение 2: «Один Guard защищает все пути выполнения». Обычный Guard транзакций и Module Guard охватывают разные точки входа; покрытие зависит от установленного контракта и его правил.
Заблуждение 3: «Удаление модуля в интерфейсе устраняет риск». В каждой сети проверьте реестр включённых модулей, хранилище Handler и Guard, реализацию прокси и выполненные транзакции изменения.

Источники

Модули Safe - Safe Ecosystem Foundation (дата обращения: 2026-08-21)
Guard в Safe - Safe Ecosystem Foundation (дата обращения: 2026-08-21)
Fallback Handler в Safe - Safe Ecosystem Foundation (дата обращения: 2026-08-21)
ModuleManager.sol - Safe Ecosystem Foundation (дата обращения: 2026-08-21)