Звіт про аудит смарт-контрактів для Dimo

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

Дімо звернувся до Sayfer, щоб провести аудит безпеки їх смарт-контракту.

У цьому звіті задокументовано дослідження, проведене Sayfer, спрямоване на вибрані ресурси, визначені в рамках дослідження. Зокрема, у цьому звіті відображається перевірка стану безпеки для смарт-контракту Dimo.

За 40 дослідницьких годин ми виявили 14 уразливостей у контракті. Жоден з них не критичний.

Підсумовуючи, слід зазначити, що після звіту слід внести кілька виправлень, але стан безпеки системи є компетентним.

Після перевірки командою Sayfer ми засвідчуємо, що всі проблеми безпеки, згадані в цьому звіті, були розглянуті командою Dimo.

Методологія ризиків

У Sayfer ми прагнемо надавати нашим клієнтам найвищу якість аудиту розумних контрактів. Ось чому ми запровадили комплексну модель оцінки ризиків, щоб оцінити серйозність наших висновків і надати нашим клієнтам найкращі рекомендації щодо пом’якшення.

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

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

Ризик визначається таким чином:

Огляд протоколу

Вступ до протоколу

DIMO — це компанія web3 IoT, яка дозволяє користувачам і розробникам отримувати доступ до багатого потоку даних, створених сучасними автомобілями. Його рішення — це екосистема, що належить користувачам, яка дозволяє водіям отримувати економічні вигоди від своїх даних і створювати такі додатки, як параметричне страхування, одноранговий обмін автомобілями та ринки транспортних засобів. Децентралізована платформа також дає розробникам спокій, оскільки вони знають, що їхній доступ до даних не залежить від примх централізованого воротаря. Це рішення побудовано на Polygon.

Висновки аудиту

[H] Зміна часу Genesis потенційно може порушити розподіл винагороди

ID	СКАЖИ-01
Статус	Виправлено
Risk	Високий
Business Impact	rewardsGenesisTime є критичною змінною, яка відстежує час початку винагород і таким чином керує розподілом винагород. Рівень винагороди продовжує зменшуватися з часом, повільно зменшуючись до 85% від попереднього циклу в якийсь момент у майбутньому. Тому скидання часу генезису після початку розподілу винагороди може порушити всю схему.
Місце розташування	– Reward.sol; resetRewardsGenesisTime() – Reward.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
Статус	Виправлено
Risk	Високий
Вплив на бізнес	Хоча облікові записи адміністраторів за визначенням користуються певною мірою довіри, якщо їх зламано, їх можна використовувати для вичерпання коштів контракту за допомогою цієї функції.
Місце розташування	– Reward.sol; adminWithdraw(адреса, uint256)

Опис

Функція adminWithdraw(address, uint256) дозволяє адміністраторам надсилати контрактні кошти користувачам без обмежень. Згідно з документацією, це використовується, якщо користувачі надсилають DIMO в контракт без ставки. Однак ми вважаємо, що цією функцією можуть зловживати, як пояснюється в розділі про вплив на бізнес.

Пом'якшення

Одним із можливих способів підвищення безпеки є подання запиту від імені користувача, можливо, за допомогою облікового запису з роллю oracle. Потім адміністратор має схвалити транзакцію. Це принаймні вимагає двох облікових записів для схвалення таких транзакцій, забезпечуючи ще один рівень безпеки.

 

[H] Адміністратори можуть скинути реєстр за бажанням

ID	СКАЖИ-03
Статус	Визнаний
Risk	Високий
Вплив на бізнес	Реєстр – це місце, де зберігаються дані користувача та виконуються перевірки. Якщо реєстр буде скинуто, існуючі користувачі перестануть отримувати винагороди, якщо дані не буде перенесено до нового реєстру.
Місце розташування	– Reward.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
Статус	Визнаний
Risk	Інформаційний
Вплив на бізнес	Ми вирішили оцінити цей висновок як інформаційний, оскільки він головним чином є наслідком основних проблем централізації, описаних вище. За поточного способу побудови системи необхідно, щоб хтось призначав і керував ролями Oracle і Admin. Однак необов’язково, щоб обліковий запис сам мав ці ролі.
Місце розташування	– Reward.sol:108-111; ініціалізувати (адреса, адреса, адреса)

Опис

Під час ініціалізації програма розгортання отримує ролі адміністратора, адміністратора за замовчуванням і оракула:

_setupRole(DEFAULT_ADMIN_ROLE, msg.sender);

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

Пом'якшення

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

 

[M] Використовуйте AccessControlDefaultAdminRulesUpgradeable

ID	СКАЖИ-05
Статус	Визнаний
Risk	Medium
Вплив на бізнес	Враховуючи притаманну централізацію контракту та важливість ролей адміністратора (і, отже, керування ними), ми вирішили оцінити цей результат як середній ризик.
Місце розташування	-

Опис

Reward.sol наразі використовується AccessControlUpgradable для надання та керування доступом до критичних функцій. У схемі контролю доступу OZ обліковий запис, який має DEFAULT_ADMIN_ROLE, може надавати та скасовувати всі інші ролі. У поточному стані контракту він надається розгортачу після ініціалізації.

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

• Може зберігатися лише один обліковий запис DEFAULT_ADMIN_ROLE.
• DEFAULT_ADMIN_ROLE можна передати лише за допомогою двоетапного процесу. Настроювана затримка між двома кроками, changeDefaultAdminDelay, виконується.

Пом'якшення

Переключити з AccessControlUpgradable до AccessControlDefaultAdminRulesUpgradeable.

 

[L] Недостатня перевірка введених даних у manuallySetRewardsGenesisTime(uint256)

ID	СКАЖИ-06
Статус	Виправлено
Risk	низький
Вплив на бізнес	Ми оцінюємо цю проблему як низьку, оскільки помилкове значення може бути виправлено адміністратором так само легко, як воно було надано.
Місце розташування	– Reward.sol; вручну SetRewardsGenesisTime(uint256)

Опис

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

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

Пом'якшення

Переконайтеся, що введені дані дорівнюють або менші за поточну позначку часу.

 

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

ID	СКАЖИ-07
Статус	Виправлено
Risk	низький
Вплив на бізнес	Так само, як і наведене вище, ми вирішили оцінити це відкриття як низький ризик, оскільки його можна легко виправити повторним викликом функції.
Місце розташування	– Reward.sol; setMinimumTimeForRewards(uint256)

Опис

Ця знахідка дуже схожа за змістом на ту, що знаходиться безпосередньо над нею. Занадто високе значення призведе до того, що користувачі не зможуть отримати свої винагороди. Це в поєднанні з тим фактом, що винагороди щотижня зменшуються на _limitForWeek(uint256), каструє перевагу, яку надає раннє прийняття.

Пом'якшення

Визначте прийнятний діапазон значень для minimumTimeForRewards і примусово виконувати його за допомогою функції. Через прямий вплив цієї цінності на всю структуру винагород платформи ретельне управління нею має першорядне значення.

 

[L] Невикористана помилка

ID	СКАЖИ-08
Статус	Виправлено
Risk	низький
Вплив на бізнес	Ми вирішили оцінити цю проблему як низьку, а не як інформаційну, це, здавалося б, випадкове упущення певним чином впливає на логіку контракту.
Місце розташування	– Нагорода.sol:12

Опис

Помилка InvalidArrayLegnth() оголошується в рядку 12, але ніколи не використовується.

Пом'якшення

Ми припускаємо, що ця помилка мала бути введена batchTransfer(TransferInfo[]) якщо наданий масив не має восьми елементів:

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

 

[L] Неперевірене значення, що повертається

ID	СКАЖИ-09
Статус	Виправлено
Risk	низький
Вплив на бізнес	Функція передачі токенів ERC20 повертає успіх або невдачу передачі як логічне значення. Вважається доброю практикою перевірити це значення та продовжувати лише в разі успіху. Однак тому, що документація це передбачає batchTransfer(TransferInfo[]) використовується лише для передачі токенів Dimo, ми оцінюємо цей висновок як низький.
Місце розташування	– Reward.sol:232; batchTransfer(TransferInfo[])

Опис

У зазначеному рядку виконується передача dimoToken, але повертається значення не позначається.

Пом'якшення

Повернути з помилкою, якщо передача не вдається:

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

 

[L] Застарілий виклик API

ID	СКАЖИ-10
Статус	Визнаний
Risk	низький
Вплив на бізнес	на відміну від grantRole(bytes32, address), _setupRole(bytes32, address) не виконує жодних перевірок облікового запису, що телефонує. Тому його визнано застарілим.
Місце розташування	– Reward.sol:108-111; ініціалізувати (адреса, адреса, адреса)

Опис

Функція _setupRole(bytes32, address), що використовується у вказаному розташуванні, у OpenZepplin 5.0 визнано застарілим. Дзвінок grantRole(bytes32, address) замість цього зараз рекомендується.

Пом'якшення

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

 

[I] Недостатня емісія події

ID	СКАЖИ-11
Статус	Виправлено
Risk	Інформаційний
Вплив на бізнес	Багато інструментів моніторингу, зовнішніх інтерфейсів, інструментів поза мережею та служб звітності покладаються на події, щоб фіксувати дії контрактів у реальному часі. Крім того, протоколи можуть швидко реагувати на викиди підозрілих подій.
Місце розташування	– Reward.sol; setRegistryContractAddress(адреса) – Reward.sol; setMinimumTimeForRewards(uint256) – Reward.sol; setSyntheticProxyAddress(адреса) – Reward.sol; resetRewardsGenesisTime() – Reward.sol; manuallySetRewardsGenesisTime() – Reward.sol:267-268; batchTransfer(TransferInfo[])

Опис

Вищезазначені функції не видають події для важливих оновлень стану.

Пом'якшення

Додайте викиди події.

 

[I] Версії Solidity

ID	СКАЖИ-12
Статус	Визнаний
Risk	Інформаційний
Вплив на бізнес	Контракт можна скомпільувати та протестувати з різними версіями компілятора під час розробки та перевірки та іншою іншою версією компілятора під час розгортання в основній мережі. Це може призвести до неочікуваних результатів.
Місце розташування	Reward.sol:2

Опис

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

Пом'якшення

Визначтеся з єдиною версією solidity для використання. Останнім стабільним (і тому рекомендованим) випуском є ​​0.8.19.

 

[I] Індексує параметр тижня в TokensTransferredForConnectionStreak()

ID	СКАЖИ-13
Статус	Виправлено
Risk	Інформаційний
Вплив на бізнес	Індексація корисна для фільтрації подій у журналах Ethereum. Кожен проіндексований параметр у події додає тему до журналу подій, що полегшує пошук певних подій за допомогою цих параметрів.
Місце розташування	– Нагорода.sol:81

Опис

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

Пом'якшення

Розгляньте індексацію зазначеного параметра.

 

[I] Дотримання посібника зі стилю Solidity

ID	СКАЖИ-14
Статус	Виправлено
Risk	Інформаційний
Вплив на бізнес	Це питання суто інформаційне. Немає жодного впливу на безпеку контракту чи інше.
Місце розташування	– Нагорода.sol:36

Опис

TransferInfo[], структура, визначена в рядку 36, безпосередньо після змінних стану. Керівництво по стилю Solidity рекомендує розміщувати оголошення структур раніше.

Пом'якшення

Перемістіть оголошення структури безпосередньо на початок контракту, перед змінними стану.