Чуть больше о Yul (assembly)

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

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

Я нашел интересную статью о yul для начинающих, хоть и на английском языке.

Очень длинная, но хорошо объясняющая базовые опкоды.

Оставлю ее здесь на самостоятельное изучение. А если захотите, сможем сделать день yul и разобрать статью по частям.

#yul #assembly #opcode

Читаем отчеты вместе. 6

Сегодня на очереди отчет от прекрасного аудитора и одного из наблюдателей Sherlock - Trust. В конце прошлого года он занимал лидирующие позиции на популярных платформах и заслужил доверие многих компаний.

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

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

Итак, читаем отчет вместе!

#report #audit

Как читать calldata?

Вчера в сообществе задавали вопрос про calldata и я вспомнил, что несколько раз натыкался на статью, но почему-то не придавал ей значение. А вчера нашел ее и стал читать внимательно.

Автор, DeGatchi, прекрасно рассказывает и показывает на примерах, как правильно читать, да и вообще, из чего состоит calldata.

Предлагаю и вам прочитать данную статью.

Вкратце говоря, автор показывает, что calldata состоит из набора строк по 32 байта и разбивает несколько примеров построчно. Более того, он разбирает несколько вариантов calldata: со статическими переменными, с динамическими и смешанными, а также multicall.

Очень много примеров и скринов. Классная статья!

#calldata

Правило 1/64

До введения стандарта EIP-150, вызывающий (caller) из одного контракта передавал вызываемому (callee) в другой контракт весь свой имеющийся газ.

Тогда, для того, чтобы предотвратить ошибку "stack too deep", максимальное количество вызовов (calls) могло быть не больше 1024, после чего последний вызов обрывался (возвращал fail).

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

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

Правило 1/64 означает, что при любых обстоятельствах у вызывающего останется 1/64 часть от всего доступного газа.

Другой особенность EIP-150 было то, что опкод call теперь имел не фиксированное количество газа, а максимально возможное. При этом, если операция требовала больше газа, чем было возможно по формуле, то транзакция все равно не откатывалась.

Перевод подготовлен на основе ветки Твиттера.

#gas #eip150

Скрин к предыдущему посту

Read-only-reentrancy

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

Теперь аудиторы должны научиться распознавать подобные штуки в контрактах.

Пользователь под ником Bytes32 в Твиттере сделал прекрасную ветку, где расписал эту уязвимость не только на простом примере, но и показал реальный контракт, где это было возможно.

Обязательно к прочтению для всех аудиторов!

#security #reentracy

Учебная группа от Web3SecurityDao

Вчера появилась информация о том, что Web3SecurityDao запускает учебные группы по вопросам безопасности. Созвоны будут проходить на их Дискорд сервере, начало 1 февраля.

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

В общем, меня заинтересовало, может будет также и вам.

Вот ссылка на информационную страницу и Дискорд.

#study

Читаем отчеты вместе. 7

Сегодня подумал о том, что есть некая тонкая черта между bug hunter и white hat hacker, баг хантером и белым хакером.

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

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

Позабавило еще то, что в обучении процесс идет как-то так:

1) Сначала мы учимся популярным уязвимостям, читая просто их описание (баг хантер);
2) Затем играемся с CTF и другими задачами (хакер);
3) Идем на популярные конкурсные платформы (баг хантер);
4) Переходим на уровень Immunefi и работы на сетях (хакер);

т.е. идет чередование навыков.  

Но это отступление от темы. А сегодня мы вернемся к Шерлоку и прочитаем еще один не очень сложный отчет.

Итак, читаем вместе!

#report #audit

Манипуляции  с block.timestamp

В одной из веток Твиттера наткнулся на интересное рассуждение о манипуляциях хакеров / майнеров с timestamp.

Например, если взглянуть на код в примере, то в нем существует уязвимость. Майнер может спокойно манипулировать block.timestamp в течение 7 секунд, чтобы его транзакция могла соответствовать условию для выигрыша.

Тем не менее, по утверждения автора, в текущих условиях реализации GETH подобные действия могут происходить только в промежутке 15 секунд от блока до блока. Другими словами, если timestamp будет больше, скажем 30 секунд, по нужному условию в контракте, то это будет более безопасно.

Более подробно в по этой ссылке.

#timestamp

Объединение строк

Начиная с версии 0.8.12 в Solidity есть встроенная функция для объединения строк.

#strings

Еще раз все сначала

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

И вот сегодня я решил немного систематизировать их, так как перечитывать стало слегка проблематично. Ну, знаете эту штуку, когда информации много, она вся в куче и, читая пункты, в голове ничего не укладывается.

Вместе с этим я решил пересмотреть старые посты, где решал задачи Ethernaut, DVD, CTE и другие. И понял, что некоторые я забыл как решать. В том смысле, что попадись подобный пример кода в реальном аудите, я просто бы прошел мимо.

В общем, перекапывал все свои старые заметки и убил полдня.

При этом нашел ссылку, которую сохранял ранее, где опубликован весь курс Secureum, и подумал, что может стоит пройти его?

Хотите ли вы вместе со мной пройти курс Secureum? Там около 30 уроков и куча текстового материала. Как я понял, там вообще с нуля вся подача, типа как с 0 до аудитора.

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

Что думаете?

#secureum

Читаем отчеты вместе. 8

Ну, и по традиции, на вечер выкладываю очередной отчет. На этот раз - это новый отчет с code4rena.

Без дополнительные речей, читаем отчет вместе.

#report #audit

Solidity полон сюрпризов

А знали ли вы, что mapping могут держать функции в качестве значения? Или, что функции могут принимать функции в качестве параметров?

Лично для меня это было в диковинку. Наткнулся на эту картинку, опять же, в Твиттере и сначала подумал, что это какой-то прикол. Более того, по указанной ссылке, да и в поиске я не смогу найти информации об этом.

Переписав код со скрина в Ремикс, он скомпилировался без проблем. Да и потом исполнился на раз!

Удивительно! Ни разу: ни в аудитах, ни в задачах, ни где, я не встречал таких примеров.

В комментариях оставляю код, чтобы вы могли скопипастить его в Ремикс и поиграться самим.

#mapping #function

Пара слов о курсе Secureum

Вчера я спрашивал на канале, стоит ли выкладывать лекции с буткемпа и проходить курс всем вместе. Посмотрел первую лекцию и...

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

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

Если будет что-то новое, то чего ранее не было на канале, то буду делать мини посты.

#secureum

Читаем отчеты вместе. 9

Если вы читаете отчеты вместе со мной, то можете смело похвалить себя! Вы прочитали на 9 отчетов больше, чем если бы делали все сами!

Лично я нашел для себя несколько интересных моментов, на которые теперь буду обращать при аудитах.

Готовы к финальному на этой неделе? Если да, то поехали! На сегодня у нас отчет от Trust.

Читаем отчет вместе!

#report #audit

День задач на канале!

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

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

Первая задача на сегодня довольно сложная. Здесь представлена именно логическая уязвимость. Сможете понять какая?

Решение

passThruGate() проверяет, чтобы пользователь отправил сумму большую, чем gate.ethCost. Однако остатки от требуемой суммы никак не обрабатываются и не возвращаются пользователю, поэтому они остаются заблокированными на контракте. Это считается High risk issue на code4rena.

#task

Задача от Immunefi

Прекрасная задача от Immunefi, которая показывает, что всегда нужно следить за обновлениями и делать дополнительные проверки. Поняли, в чем дело?

Решение

Из-за того, что в коде пропущено обновление listings.deposit в функции withdraw(), пользователь может вызывать ее сколько угодно раз, пока контракт не будет опустошен.

#task

Задача от code4rena

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

В общем, еще одна задача на мышление хакера. С кодом все в порядке (насколько это возможно для примера), но дело в другом. Сможете сломать контракт?

Решение

Тут показан пример DoS атаки. Если хакер создаст слишком большой массив withddrawals, то цикл может просто израсходовать весь газ и прервать выполнение функции.

#task

Простая, но опасная

Задача была помечена, как High Risk. Достаточно прочитать код внимательно, чтобы понять, в чем тут дело.

Решение

А решение уместиться в три слова: memory не storage. Обновление данных во временных переменных, не приводит к их обновлениям в основной памяти.

#task

Задача с двумя проблемами

В данной задаче существует две проблемы: одна официальная из отчета, другая, замеченная пользователями. Вероятнее, всего вторая проблема была защищена в не представленном коде, но это не точно. Сможете найти обе?

Решение

Официальный баг тот, что значение to не было проверено на нулевой адрес. В принципе популярная проблема. Вторая более сложная и заметить ее могут только опытные разработчики. Дело в незащищенном преобразовании (casting) с uint256 в uint96, из-за чего итоговая сумма может быть не такой, как планировалось.

#task

Задача для новичков

Еще одна простая задача, которая имеет статус Med Risk. Ее также можно назвать логической.

Решение

Ранее созданный market может быть переписан, так как нет проверок на существующие.

#task