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

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

1inch связалась с Sayfer для проведения аудита безопасности их смарт-контракта.

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

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

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

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

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

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

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

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

1inch повышает эффективность операций в среде блокчейна второго уровня. Учитывая, что операции с большими данными вызовов, как правило, являются более затратными на уровне 2, основное внимание уделяется уменьшению размера данных вызовов. Для этого используется стратегия сжатия данных вызовов. Эта стратегия в основном включает в себя операции вне цепочки и использует механизм, называемый DecompressorExtension, который позволяет восстанавливать сжатые данные вызовов.

Для сжатия данных вызова используются несколько ключевых методов:

1. Сжатие последовательных нулевых байтов. Этот метод уменьшает общий размер данных вызова за счет объединения последовательных нулевых байтов в более компактный формат.
2. Копирование последовательных байтов. В некоторых случаях репликация последовательных байтов используется в качестве стратегии сжатия данных.
3. Замена на основе словаря. Для замены сегмента данных вызова индексом, взятым из предопределенного словаря, используются два разных метода, что приводит к более эффективному представлению данных.

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

Риск централизации

Описание

Если же линия индикатора _setData Функция доступна владельцу контракта, что, по-видимому, является предполагаемым способом использования контракта в соответствии с README. Это создает риск централизации для каждого проекта, использующего DecompressorExtension.

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

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

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

риска

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

Нет собственной реализации

Описание

В README несколько раз говорится о реализации Собственная форма OpenZeppelin. На самом деле контракт не реализует и не расширяет Owneable, что может сбивать с толку и вводить в заблуждение владельцев проектов.

Из README:

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

Это опасно, поскольку владельцы проекта могут предположить, что существует механизм контроля доступа, которого не существует.

риска

Реализуйте функциональность владения путем наследования от Ownable или обновите README, чтобы указать, что именно пользователь должен заботиться об управлении доступом.

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

Описание

Очень легко отправить (короткий) ввод в decompress в результате получаются огромные распакованные данные вызова, т.е. эквивалент почтовая бомба.

Например, многие байты 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.