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

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

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

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

За період дослідження тривалістю 15 днів аудиту ми виявили 3 уразливості та 1 інформаційну примітку в перевіреному договорі.
Жодне з цих знахідок не вважається критичним, контракт можна розгорнути як є. Усі знахідки були адресовані та виправлені командою 1inch.

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

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

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

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

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

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

1inch підвищення ефективності операцій у середовищі блокчейну рівня 2. З огляду на те, що операції з більшими даними викликів, як правило, дорожчі на Рівні 2, основна увага полягає в зменшенні розміру даних викликів. Щоб досягти цього, використовується стратегія стиснення даних викликів, ця стратегія в основному передбачає операції поза ланцюгом і використовує механізм, званий DecompressorExtension, який дозволяє відновлювати стиснуті дані викликів.

Для стиснення даних виклику використовується кілька ключових методів:

1. Стиснення послідовних нульових байтів: ця техніка зменшує загальний розмір даних виклику шляхом консолідації послідовних нульових байтів у більш компактний формат.
2. Копіювання послідовних байтів: у деяких випадках реплікація послідовних байтів використовується як стратегія стиснення даних.
3. Заміна на основі словника: два різні методи використовуються для заміни сегмента даних виклику індексом із попередньо визначеного словника, що забезпечує більш ефективне представлення даних.

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

Ризик централізації

Опис

Якщо _setData функція надається власнику контракту, що, здається, є запланованим способом використання контракту відповідно до README, це створює ризик централізації для кожного проекту, який використовує DecompressorExtension.

function _setData(uint256 offset, bytes32 data) internal
validDictAccess(offset) {
    unchecked {
        _dict[offset] = data;
    }
}

Власник може передати виклик від користувача та змінити відповідний ключ dict перед виконанням виклику, що дозволяє йому довільно змінювати дані виклику. Таким чином, користувачеві стає неможливо перевірити (розпаковані) дані виклику перед викликом.

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

Пом'якшення

Одним із рішень для цього було б заборонити змінювати існуючі словникові статті, але потрібне краще розуміння бізнес-потреб і варіантів.

Немає власної реалізації

Опис

У README кілька разів зазначено про впровадження Власна форма OpenZeppelin. Насправді контракт не реалізує та не розширює Owneable, що може заплутати та ввести в оману власників проекту.

З README:

This contract provides a `DecompressorExtension` abstract
contract that extends `Ownable` from the OpenZeppelin
library.

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

Пом'якшення

Реалізуйте функцію власності, успадкувавши від Ownable, або оновіть README, щоб указати, що користувач – це той, хто має піклуватися про контроль доступу

Газова DoS-атака

Опис

Дуже легко подати (короткий) вхід decompress що призводить до величезних розпакованих даних виклику, тобто еквівалента a zip бомба.

Наприклад, багато 00111111 байтів, за якими слідують інші дані, можна надіслати за допомогою case 0, що призводить до величезних витрат на розширення пам’яті:

case 0 {
    let size := add(byte(0, data), 1)
    calldatacopy(outptr, calldatasize(), size)
    inptr := add(inptr, 1)
    outptr := add(outptr, size)
    continue
}

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

Однак є деякі сценарії, коли це може призвести до атаки. Наприклад, у нас може бути контракт ретранслятора, який викликає смарт-контракт, де розробники подбали про те, щоб використання газу для кожної функції було обмеженим. Якщо цей смарт-контракт тепер починає використовувати розширення, використання газу стає необмеженим, як data змінна є введенням, керованим користувачем.

Пом'якшення

Уникнути цієї вразливості буде важко, необхідно краще розуміти потреби бізнесу.

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

Несумісність з ERC-2771/мета-транзакціями

Опис

Розширення несумісне зі стандартом ERC-2771, де ретранслятор додає вихідного відправника до даних виклику (оскільки це призведе до помилок стиснення).

Це не повинно бути великою проблемою, оскільки контракти все ще підтримують звичайні (нестиснені) виклики, але це означає, що стиснення не можна використовувати разом із мета-транзакціями.

Ми припускаємо, що в якийсь момент цей контракт стане базовим будівельним блоком для інших протоколів, які можуть використовувати ERC-2771, який тоді більше не працюватиме при використанні стиснутих даних виклику.

Пом'якшення

Якщо це актуально, запровадьте ERC-2771