Отчет об аудите смарт-контрактов для Dimo

Резюме управления

Димо связался с Sayfer, чтобы провести аудит безопасности их смарт-контракта.

В этом отчете документально подтверждено исследование, проведенное Sayfer с использованием выбранных ресурсов, определенных в рамках исследования. В частности, в этом отчете представлен обзор состояния безопасности смарт-контракта Dimo.

За период исследования в 40 исследовательских часов мы обнаружили 14 уязвимостей в контракте. Ни один из них не является критическим.

В заключение следует отметить, что после отчета необходимо внести несколько исправлений, но уровень безопасности системы является компетентным.

После проверки командой Sayfer мы подтверждаем, что все проблемы безопасности, упомянутые в этом отчете, были решены командой Dimo.

Методология риска

В Sayfer мы стремимся предоставлять нашим клиентам аудит смарт-контрактов высочайшего качества. Вот почему мы внедрили комплексную модель оценки рисков, чтобы оценить серьезность наших выводов и предоставить нашим клиентам наилучшие рекомендации по их снижению.

Наша модель оценки рисков основана на двух ключевых факторах: ВЛИЯНИЕ и ВЕРОЯТНОСТЬ. Под воздействием понимается потенциальный вред, который может возникнуть в результате проблемы, например финансовые потери, репутационный ущерб или неработоспособность системы. Вероятность означает вероятность возникновения проблемы с учетом таких факторов, как сложность контракта и количество потенциальных злоумышленников.

Объединив эти два фактора, мы можем получить полное представление о риске, связанном с конкретной проблемой, и предоставить нашим клиентам четкую и действенную оценку серьезности проблемы. Такой подход позволяет нам расставлять приоритеты в наших рекомендациях и гарантировать, что наши клиенты получат наилучшие советы о том, как защитить свои смарт-контракты.

Риск определяется следующим образом:

Обзор протокола

Введение протокола

DIMO — это компания, занимающаяся Интернетом вещей в формате web3, которая позволяет пользователям и разработчикам использовать богатый поток данных, генерируемых современными транспортными средствами. Его решение представляет собой экосистему, принадлежащую пользователям, которая позволяет водителям извлекать экономическую выгоду из своих данных и создавать возможные приложения, такие как параметрическое страхование, одноранговый обмен автомобилями и рынки транспортных средств. Децентрализованная платформа также дает разработчикам душевное спокойствие, поскольку их доступ к данным не зависит от прихотей централизованного привратника. Это решение построено на Polygon.

Выводы аудита

[H] Изменение времени Бытия может потенциально нарушить распределение наград.

ID	САЙ-01
Статус:	Исправлена
Снижение	High
Бизнес Влияние	rewardsGenesisTime — это критическая переменная, которая отслеживает время запуска вознаграждений и, таким образом, управляет распределением вознаграждений. Размер вознаграждения продолжает снижаться с течением времени, постепенно снижаясь до 85% от предыдущего цикла в какой-то момент в будущем. Следовательно, сброс времени генезиса после начала распределения вознаграждений может нарушить всю схему.
Адрес	— Награда.sol; сбросRewardsGenesisTime() — Награда.sol; вручнуюSetRewardsGenesisTime(uint256)

Описание

Изменение rewardsGenesisTime позже в цикле позже повлияет на важнейшие переменные currentWeek и WeekLimit и потенциально может испортить всю схему распределения вознаграждений и ее прогнозируемый график.

риска

Одним из возможных способов смягчения последствий является пересмотр этих функций таким образом, чтобы сброс времени генезиса был возможен только до начала распределения вознаграждения:

 function resetRewardsGenesisTime() external onlyRole(ADMIN_ROLE) {
        require(dimoTotalSentOutByContract==0,"Reward Distribution already started");
        rewardsGenesisTime = block.timestamp;
  }

Если необходим сброс или изменение переменной постфактум, возможно, с этим можно справиться контролируемым и предсказуемым образом в цепочке, вместо того, чтобы предоставлять администраторам произвольный контроль.

 

[H] Непроверенный отказ администратора

ID	САЙ-02
Статус:	Исправлена
Снижение	High
Влияние на бизнес	Хотя учетным записям администраторов по определению предоставляется определенная степень доверия, в случае их компрометации их можно использовать для слива средств с контракта с помощью этой функции.
Адрес	— Награда.sol; adminWithdraw (адрес, uint256)

Описание

Функция adminWithdraw(address, uint256) позволяет администраторам отправлять пользователям средства по контракту без ограничений. Согласно документации, это используется, если пользователи отправляют DIMO на контракт без стейкинга. Однако мы считаем, что этой функцией могут злоупотреблять, как описано в разделе «Влияние на бизнес».

риска

Один из возможных способов повышения безопасности — отправить запрос от имени пользователя, возможно, используя учетную запись с ролью oracle. Затем администратор должен одобрить транзакцию. Для одобрения таких транзакций требуется как минимум две учетные записи, что обеспечивает еще один уровень безопасности.

 

[H] Администраторы могут сбросить реестр по своему желанию.

ID	САЙ-03
Статус:	Признанный
Снижение	High
Влияние на бизнес	Реестр — это место, где хранятся пользовательские данные и выполняются проверки. Если реестр будет сброшен, существующие пользователи перестанут получать вознаграждения, если данные не будут перенесены в новый реестр.
Адрес	— Награда.sol; setRegistryContractAddress (адрес)

Описание

setRegistryContractAddress(address) позволяет администраторам сбрасывать адрес реестра по своему желанию.

риска

Одним из решений является обеспечение возврата этой функции, если реестр не настроен изначально.

  function setRegistryContractAddress(
    address registryContractAddress
  ) external onlyRole(ADMIN_ROLE) {
    require(
        registryContractAddress != address(0),
        "registryContractAddress is an invalid zero address"
    );
    require(address(registry)==address(0)),"already set, cannot be set again")
    registry = IRegistry(registryContractAddress);
  }

Другое решение — настроить процедуру миграции данных. Если такая процедура уже существует, то этот вывод можно смело игнорировать.

 

[I] У Deployer есть роли администратора и Oracle.

ID	САЙ-04
Статус:	Признанный
Снижение	Информационный
Влияние на бизнес	Мы решили оценить этот вывод как информационный, поскольку он главным образом является следствием основных проблем централизации, описанных выше. При нынешнем построении системы необходимо, чтобы кто-то назначал роли Oracle и администратора и управлял ими. Однако не обязательно, чтобы эта учетная запись сама выполняла эти роли.
Адрес	— Награда.сол:108-111; инициализировать(адрес, адрес, адрес)

Описание

Во время инициализации развертыватель получает роли администратора, администратора по умолчанию и Oracle:

_setupRole(DEFAULT_ADMIN_ROLE, msg.sender);

_setupRole(ORACLE_ROLE, msg.sender);
_setupRole(ADMIN_ROLE, msg.sender);

риска

Рассмотрите возможность предоставления только роли администратора по умолчанию, унаследованной от OA. AccessControlUpgradeable, к развертывателю, что позволяет ему управлять ролями других пользователей.

 

[M] Использовать AccessControlDefaultAdminRulesUpgradeable

ID	САЙ-05
Статус:	Признанный
Снижение	Medium
Влияние на бизнес	Учитывая присущую контракту централизацию и важность ролей администраторов (и, следовательно, их управления), мы решили оценить этот вывод как средний риск.
Адрес	–

Описание

Reward.sol в настоящее время использует AccessControlUpgradable для предоставления и управления доступом к критическим функциям. В схеме управления доступом OZ учетная запись, имеющая DEFAULT_ADMIN_ROLE, может предоставлять и отзывать все остальные роли. В текущем состоянии контракта он передается развертывателю при инициализации.

AccessControlDefaultAdminRulesUpgradeable продолжается AccessControlUpgradable с двумя важными функциями безопасности:

• Только один аккаунт может содержать DEFAULT_ADMIN_ROLE.
• DEFAULT_ADMIN_ROLE могут быть переданы только с помощью двухэтапного процесса. Настраиваемая задержка между двумя шагами, changeDefaultAdminDelay, соблюдается.

риска

Переключиться с AccessControlUpgradable в AccessControlDefaultAdminRulesUpgradeable.

 

[L] Недостаточная проверка ввода вручнуюSetRewardsGenesisTime(uint256)

ID	САЙ-06
Статус:	Исправлена
Снижение	Низкий
Влияние на бизнес	Мы оцениваем эту проблему как низкую, поскольку администратор может исправить ошибочное значение так же легко, как оно было задано.
Адрес	— Награда.sol; вручнуюSetRewardsGenesisTime(uint256)

Описание

Помимо создания риска централизации, как подробно описано выше, manuallySetRewardsGenesisTime(uint256) также не может проверить метку времени, указанную администратором. Оно с радостью приняло бы будущее время, что привело бы к _getNumberOfWeeksSinceGenesis() вернуться:

  function _getNumberOfWeeksSinceGenesis()
    private
    view
    returns (uint256 unixTimeDiff)
  {
    unixTimeDiff = (block.timestamp - rewardsGenesisTime) / 7 days;
  }

риска

Убедитесь, что введенное значение равно или меньше текущей метки времени.

 

[L] Недостаточная проверка ввода в setMinimumTimeForRewards(uint256)

ID	САЙ-07
Статус:	Исправлена
Снижение	Низкий
Влияние на бизнес	Как и в случае с предыдущим выводом, мы решили оценить этот вывод как низкий риск, поскольку его можно легко исправить, вызвав функцию еще раз.
Адрес	— Награда.sol; setMinimumTimeForRewards (uint256)

Описание

Эта находка по существу очень похожа на ту, что находится непосредственно над ней. Слишком высокое значение приведет к тому, что пользователи не смогут получить свои награды. Это, в сочетании с тем фактом, что награды уменьшаются еженедельно на _limitForWeek(uint256), нивелирует преимущество, предоставляемое ранним внедрением.

риска

Определите приемлемый диапазон значений для minimumTimeForRewards и обеспечить его соблюдение с помощью функции. Поскольку эта ценность оказывает прямое влияние на всю структуру вознаграждений платформы, тщательное управление ею имеет первостепенное значение.

 

[L] Неиспользованная ошибка

ID	САЙ-08
Статус:	Исправлена
Снижение	Низкий
Влияние на бизнес	Мы решили оценить этот вопрос как низкий, а не информационный, это, казалось бы, случайное упущение действительно имеет некоторое влияние на логику контракта.
Адрес	— Награда.сол:12

Описание

Ошибка InvalidArrayLegnth() объявляется в строке 12, но никогда не используется.

риска

Мы предполагаем, что эта ошибка должна была быть выброшена batchTransfer(TransferInfo[]) если предоставленный массив не имеет восьми элементов:

if(transferInfos.length != 8) revert InvalidArrayLength();

 

[L] Непроверенное возвращаемое значение

ID	САЙ-09
Статус:	Исправлена
Снижение	Низкий
Влияние на бизнес	Функция передачи токенов ERC20 возвращает успех или неудачу передачи в виде логического значения. Считается хорошей практикой проверять это значение и продолжать только в случае успеха. Однако, поскольку документация подразумевает, что batchTransfer(TransferInfo[]) используется только для передачи токенов Dimo, мы оцениваем этот результат как низкий.
Адрес	— Награда.sol:232; пакетный перенос(TransferInfo[])

Описание

В указанной строке осуществляется передача dimoToken, но возвращаемое значение остается непроверенным.

риска

Откат с ошибкой, если передача не удалась:

if (!dimoToken.transfer(user, amount)) revert TokenTransferFailed();

 

[L] Устаревший вызов API

ID	САЙ-10
Статус:	Признанный
Снижение	Низкий
Влияние на бизнес	В отличие от grantRole(bytes32, address), _setupRole(bytes32, address) не выполняет никаких проверок вызывающего счета. Поэтому он устарел.
Адрес	— Награда.сол:108-111; инициализировать(адрес, адрес, адрес)

Описание

Функция _setupRole(bytes32, address), используемый в указанном месте, устарел в OpenZepplin 5.0. Вызов grantRole(bytes32, address) вместо этого теперь рекомендуется.

риска

Замените звонки на _setupRole(bytes32, address) grantRole(bytes32, address).

 

[I] Недостаточная эмиссия событий

ID	САЙ-11
Статус:	Исправлена
Снижение	Информационный
Влияние на бизнес	Многие инструменты мониторинга, интерфейсы, автономные инструменты и службы отчетности полагаются на события для отслеживания действий по контрактам в реальном времени. Более того, протоколы могут быстро реагировать на выбросы подозрительных событий.
Адрес	— Награда.sol; setRegistryContractAddress (адрес) — Награда.sol; setMinimumTimeForRewards (uint256) — Награда.sol; setSyntheticProxyAddress (адрес) — Награда.sol; сбросRewardsGenesisTime() — Награда.sol; вручнуюSetRewardsGenesisTime() — Награда.sol:267-268; пакетный перенос(TransferInfo[])

Описание

Вышеупомянутые функции не генерируют события для важных обновлений состояния.

риска

Добавьте выбросы событий.

 

[I] Управление версиями Solidity

ID	САЙ-12
Статус:	Признанный
Снижение	Информационный
Влияние на бизнес	Контракт можно скомпилировать и протестировать с разными версиями компилятора во время разработки и проверки, а также с другой версией компилятора во время развертывания в основной сети. Это может привести к неожиданным результатам.
Адрес	Награда.сол:2

Описание

Контракт определяет свою прагму как pragma solidity ^0.8.13;. Это позволяет использовать любую версию Solidity, начиная с 0.8.13. Тем более, что 0.8.13 не самая последняя версия.

риска

Решите, какую версию Solidity использовать. Последняя стабильная (и, следовательно, рекомендуемая) версия — 0.8.19.

 

[I] Индексируйте параметр недели в TokensTransferredForConnectionStreak().

ID	САЙ-13
Статус:	Исправлена
Снижение	Информационный
Влияние на бизнес	Индексирование полезно для фильтрации событий в журналах Ethereum. Каждый индексированный параметр события добавляет тему в журнал событий, что упрощает поиск конкретных событий с использованием этих параметров.
Адрес	— Награда.сол:81

Описание

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

риска

Рассмотрите возможность индексации указанного параметра.

 

[I] Соблюдение руководства по стилю Solidity

ID	САЙ-14
Статус:	Исправлена
Снижение	Информационный
Влияние на бизнес	Этот вопрос носит чисто информационный характер. Это не влияет на состояние безопасности контракта или иное.
Адрес	— Награда.сол:36

Описание

TransferInfo[], структура, определяется в строке 36, сразу после переменных состояния. Руководство по стилю Solidity рекомендует размещать объявления структур заранее.

риска

Переместите объявление структуры непосредственно в начало контракта, перед переменными состояния.