Griefing атаки. Часть 2

Могут ли операции контракта быть манипулированы с помощью точного указания лимита газа?

Злоумышленники могут указывать тщательно рассчитанные объемы газа, чтобы принудительно направить выполнение контракта по определенному пути, тем самым манипулируя его поведением неожиданным образом.

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

Ярким примером такой манипуляции является "груминг" (намеренное причинение вреда) из-за недостаточного газа при внешних вызовах. Хотя в рекомендациях по устранению упоминаются «явные проверки газа», которые часто означают require(gasleft() > MIN_GAS_NEEDED), данная конкретная атака, связанная с внешними вызовами, наиболее эффективно предотвращается иным способом.

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

Продемонстрируем это на примере контракта Relayer:

1. Функция forward контракта Relayer предназначена для выполнения действия через внешний вызов контракта Target.

2. Ключевой момент: функция forward обновляет внутреннее состояние (помечает запрос _data как выполненный для защиты от повторного выполнения), прежде чем совершается внешний вызов или подтверждается его успешность.

3. Функция не проверяет статус успешности, возвращаемый вызовом target.call(...).

4. Злоумышленник вызывает forward, указывая тщательно рассчитанный лимит газа: достаточно для прохождения проверки require и обновления executed[_data] = true, но недостаточно для успешного завершения последующего вызова target.call(...) внутри контракта Target.

5. Вызов target.call исчерпывает выделенный газ и молча завершается с ошибкой (с точки зрения контракта Relayer, поскольку его успешность не проверяется). Однако функция forward завершается «успешно».

6. В результате возникает несогласованное состояние: отображение executed в контракте Relayer показывает, что действие выполнено, но необходимая внешняя операция в контракте Target фактически не произошла. Конкретная транзакция легитимного пользователя (_data) теперь навсегда заблокирована из-за механизма защиты от повторного выполнения, который по сути подвергся цензуре со стороны злоумышленника, воспользовавшегося механикой газа и отсутствием проверки ошибок.