Контракты Ethereum становятся привлекательными для хакеров

Ethereum обещает, что по умолчанию контракты будут «вечными». Кроме того, если контракт не содержит пункт о самоуничтожении, фактически он не может быть аннулирован.

Контракты Ethereum становятся привлекательными для хакеров

Это палка о двух концах. С одной стороны, способом самоуничтожения контракта по умолчанию является возврат владельцу всех средств, заложенных в контракт; естественно, что система с «нулевым доверием», в которой владелец контракта может по своему усмотрению затребовать все деньги, нереалистична.
Поэтому полезно дать людям возможность самостоятельно определять срок жизни контракта. С другой стороны, недавно я анализировал некоторые контракты Ethereum, и качество кода, который должен работать «вечно», оказалось где-то между «оптимистично достаточным» и «ужасным».

Дэн Майер опубликовал результаты исследования, согласно которым в отрасли в среднем на 1000 строк кода приходится 15–50 ошибок; в коде Microsoft их 0,5 на 1000, а в программах NASA — 0 (!) в 500 000 строках кода, но при условии очень дорогостоящего и длительного процесса программирования.
В умных контрактах Ethereum число ошибок на 1000 строк кода превышает 100!

Мой обзор умных контрактов Ethereum, опубликованный на сайте dapps.ethercasts.com, показал такую же или чуть более высокую частоту ошибок, то есть около 100 на 1000.

Определения ошибок

Я делю ошибки на три категории:

  1. Бреши в системе безопасности: возможность потери денег или контроля для пользователей или владельцев.
  2. Код не решает задачу, заявленную в описании или комментариях.
  3. Код расходует много ресурсов/неэффективен.

Перед началом этого краткого исследования я ожидал, что чаще будут встречаться проблемы 3-го типа, а иногда — 2-го. Однако, к своему удивлению, я обнаружил несколько важных случаев 1-го типа, которые часто сочетались с проблемами 2-го типа.

Как следствие, возник риторический вопрос: «Если контракты являются незыблемыми и постоянными, а частота ошибок не стремится к нулю, то под чем подписываются люди?»

В более поздней статье я выдвинул ряд предложений.

Пример контракта с проблемами

Ethstick — это финансовая пирамида, которая стимулирует участников («осликов») размещать деньги на депозите, чтобы получить выплату («морковку»). При появлении очередного платежа выбирается его получатель из списка правомочных «осликов» — «удачливый ослик».

Выплаты варьируются в диапазоне от 1,1 x до 1,2 x, причем коэффициент регулируется владельцем контракта. (В коде он называется «свинкой».) «Свинка»/владелец может продать контракт и передать его новому владельцу; это общая схема для контрактов, которые создаются как микробизнес.

Вы можете просмотреть код контракта 0xbA6284cA128d72B25f1353FadD06Aa145D9095Af на сайте etherscan.io.

Случайность

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

  1. Пользовательское целое, используемое в качестве случайного фактора и жестко закодированное в контракте.
  2. Хэш предыдущего блока.
  3. Длина списка правомочных «осликов».

Это случайное число используется для определения «ослика» — получателя выплаты. Блоки Ethereum появляются примерно каждые 45 секунд, так что у атакующего достаточно времени, чтобы вычислить, будет ли он получателем выплаты, и активировать контракт с выплатой, только если он будет получателем.

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

Не так просто снизить риск даже с помощью хеша блока, в котором производится майнинг транзакции: атакующий майнер или пул может включать в блоки только «хорошие» транзакции, соответствующие расчету; остальные транзакции исключаться и не разглашаются остальному миру.

Эта атака дает преимущества ушлому покупателю контракта, а следующая «помогает» владельцу.

Насколько длинным будет список?

С помощью функции changeEligibleDonkeys владелец контракта может сократить или расширить список «осликов». Простая атака, осуществляемая владельцем, может выглядеть так:

  1. Добавить себя в список правомочных «осликов», возможно несколько раз.
  2. Сократить список, если «киты» находятся в его конце.

Я не упомянул ряд ошибок, связанных с «эффективностью», и не утверждаю, что выявил все логические ошибки в данном коде; если вы хотите исследовать собственные пограничные случаи, обратитесь к разделу с комментарием //Ranking logic: mindfuck edition.

Учитывая пробелы и объявления данных, всего здесь около 350 строк кода. Я обнаружил две серьезные ошибки, и есть по крайней мере пять мест в коде с проблемами, связанными с округлением или эффективностью. Фактическая логика в данном коде занимает менее 100 строк.

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

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

Улучшение

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

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

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

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

Peter Vessenes

Категория: 
Безопасность
10
Средняя: 10 (1 оценка)
0
Ваша оценка: Нет
2421 / 0
Аватар пользователя admin
Публикацию добавил: admin
Дата публикации: пт, 06/10/2016 - 17:43

Что еще почитать:

Комментарии:

Аватар пользователя Buterium

Buterium

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

пт, 06/10/2016 - 17:59

Аватар пользователя Yago

Yago

И не только это, вот еще уязвимости Этериума http://vessenes.com/more-ethereum-attacks-race-to-empty-is-the-real-deal/

пн, 06/13/2016 - 19:42

Аватар пользователя Анонимус

Анонимус

Да хомякам фиолетово, их уязвимости не интересуют совершенно, курс растет - и это для них главное

вт, 06/14/2016 - 11:32

Аватар пользователя admin

admin

Ну вот, DAO уже попал под раздачу. Дальше будет только хуже

пт, 06/17/2016 - 14:39

Аватар пользователя Анонимус

Анонимус

Ждем новых уязвимых контрактов, а то старые все уже вычистили :))

пт, 07/08/2016 - 16:51

Добавить комментарий