Необычная функция

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

Я постараюсь разложить ее "по полочкам". Итак, вот сам контракт, если вдруг кому будет интересно.

И там есть такая функция (я ее обрезал, убрав не интересные части):

function stake (
AssetType _assetType,
uint256 _timelockId,
uint256,
uint256,
uint256
) external nonReentrant {

uint256 timelockOption = timelockOptions[_assetType][_timelockId];

function (uint256) _s1 = _stakeS1Citizen;
function (uint256) _s2 = _stakeS2Citizen;
function (uint256) _b = _stakeBytes;
function (uint256) _lp = _stakeLP;

function (uint256) _stake;

assembly {
switch _assetType
case 0 {
_stake := _s1
}
case 1 {
_stake := _s2
}
case 2 {
_stake := _b
}
case 3 {
_stake := _lp
}
default {}
}

_stake(timelockOption);
}

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

Обратите внимание, что в параметрах функции 5 аргументов, 3 из которых обозначены просто как тип uint256 без переменных.

Далее, я не совсем разобрался, как называется это действие, но мы создаем некие поинтеры на другие функции в контракте и кладем их в переменные _s1, _s2, _b, _lp.

_stakeS1Citizen, _stakeS2Citizen, _stakeBytes, _stakeLP - да, это все функции в данном контракте, например:

function _stakeS1Citizen (uint256 _timelock) private {}

Также нужно учесть, что в данном примере, один из аргументов в функции, assetType - это enum. Вот как он выглядит:

enum AssetType {S1_CITIZEN, S2_CITIZEN, BYTES, LP}

Т.е. вы поняли, что происходит в функции?

Мы создали поинтеры на другие функции в контракте, а затем через assembler прогнались по enum и переопределили в поинтер _stake необходимую для нас опцию!

Другими словами, исполнение данной функции продолжится уже в другой функции, учитывая значения AssetType!

Дальше еще круче!

Помните те 3 безыменных аргумента uint256 в функции?

Они передаются в последующие функции, как calldata! Например, одна из функция такая:

function _stakeBytes (uint256) ) private {

uint256 amount;
uint256 citizenId;
uint256 seasonId;

assembly{
amount := calldataload(0x44)
citizenId := calldataload(0x64)
seasonId := calldataload(0x84)
}

}

Эта calldata из безымянных uint256 передается в другие функции и расшифровывается в assembly. И что самое интересное, во всех 4 функциях _stakeS1Citizen, _stakeS2Citizen, _stakeBytes, _stakeLP - расшифровываются разные calldata в зависимости от полученных в главное функции stake!

В общем, меня впечатлил данный контракт! Надеюсь и вам он понравится.

#function

Как стать хорошим аудитором

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

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

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

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

#мысливслух

Аудит вне рамок - 11

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

Обращаем внимание при аудите

Больше всего в данном отчете меня привлекло то, что, несмотря на огромное количество проверок при создании предложений (proposals) в Dao, всегда можно найти несколько критический уязвимостей.

Когда мы имеем дело с proposals, то должны проверять не малое количество сценариев и нюансов работы с ними:

1) В какие временные рамки можно создавать предложения? Можно ли указать прошедшее время?
2) Кто может создавать предложения?
3) Можно ли перезаписывать предложения?
4) Кто может голосовать?
5) Как фиксируются голоса: на основе баланса, по snapshot или как-то еще?
6) Можно ли создавать предложение и сразу активировать его, или есть период охлаждения?
7) Можно ли создавать несколько предложений с одного аккаунта?
8) Что будет если создающий предложение может быть в нескольких ролях: например, хакер и он же владелец NFT, пользователь и он же участник Dao, пользователь и он же покупатель NFT и т.д.

При этом особое внимание нужно обращать на проверки, типа require и if, продумывая, как и кто может обойти их.

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

#audit #outofbox

Стрим от Патрика

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

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

Для тех, кто не знал, Патрик недавно ушел с ChainLink и открыл свою аудиторскую компанию. Полагаю, так он хочет привлечь к ней внимание.

Ну, а для нас, это будет хорошим поводом посмотреть, как проходит работа аудитора: от подготовки до просмотра кода.

Первый стрим уже был вчера. Сегодня будет новый в 23:30 по мск.

Записи изначально сохраняются на Твитч, но он планирует позже выложить их на Ютуб.

Ссылка на канал Патрика на Твитч.

Всем приятного просмотра.

#audit

Соберем воркшоп / шеринг / конфу? Часть 2

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

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

Настало время собрать спикеров.

На данный момент, есть несколько человек, которые готовы раскрыть темы аудита, абстрактных аккаунтов и lens протокола.

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

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

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

Кто готов?

P.S. Буду признателен, если сделаете репост в свои каналы и чаты, или просто продублируете сообщение о наборе спикеров для онлайн конференции.

#conf #workshop

По следам аудита zkSync Era. Часть 1

Вчера закончился вышеназванный конкурсный аудит и мне хотелось бы сказать несколько слов о нем.

Для начала, упомяну, что я пропустил февральский аудит Optimism, так после первого взгляда решил, что он еще "не моего поля ягода". А зря...

По своей сути, zkSync, так же как и Optimism, является layer 2 от Эфира. Другими словами, вы проводите аудит смарт контрактов другого уровня, нежели популярные протоколы с nft и токенами.

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

1. Чтение документации происходит на всех уровнях аудита.

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

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

Только так вы сможете понять сразу несколько вещей:

- Что делает эта конкретная функция?
- Какой результат ее исполнения должен быть?

И что самое главное:

- Что подразумевал разработчик, когда ее писал?
- Какой ход исполнения, может нарушить результат?

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

#zksync #era #audit #feedback

По следам аудита zkSync Era. Часть 2

Далее еще один момент, который редко где упоминают.

2. Задавайте вопросы разработчикам и общайтесь в чатах конкурса.

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

За время аудита я задал более 20 различных вопросов по zkSync одному из разработчиков. И на каждый был получен детальный ответ! Это сильно помогло мне понять идею некоторых действий и функций.

Не бойтесь писать им в личку! Используйте гугл переводчик, если есть проблемы с английским. Во-первых, это в их интересах дать качественные ответы, которые, возможно, помогут сделать их проект безопаснее. А, во-вторых, это поможет вам лично разобраться с деталями, возможно, найти баг и получить вознаграждение.

#zksync #era #audit #feedback

По следам аудита zkSync Era. Часть 3

Ну, и последний, не совсем очевидный момент, но:

3. На следующий аудит вы потратите меньше сил.

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

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

И все это вы получите, не говоря уж о том, что знатно прокачаете свои навыки.

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

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

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

Это помогает мне развиваться. Надеюсь и вы сможете найти для себя пару новых идеи для следующего своего аудита.

#zksync #era #audit #feedback

Найденный баг в Optimism

Хочу тут еще сделать пост о найденном баге, который принес Trust и Obront + 150к в конкурсном аудите. Вот ссылка на сам баг.

Мне пришлось перечитывать его несколько раз, что понять его смысл. Вероятно, вы сможете осознать его быстрее.

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

Так вот, тут расчеты основывали на проверке:

require(gasleft() >= _tx.gasLimit + 20000, "...");

которая была перед вызовом:

bool success = SafeCall.call(
   _tx.target,
   gasleft() - 20000,
   _tx.value,
   _tx.data
);

и все бы ничего, если между ними не было установки переменной: l2Sender = _tx.sender.

Разработчики не учли, что и это тоже требует расхода газа.

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

Если газа не хватало, то активы пользователя навсегда блокировались бы на контракте.

Вот такая маленькая деталь принесла такие большие деньги!

#audit #optimism

По следам аудита от Патрика Коллинса

Выше я делал пост о том, что создатель 32-часового курса по Solidity, Патрик Коллинс, открыл свою аудиторскую компанию и решил провести марафон на несколько дней, делая аудит одного из проектов вживую на стриме.

Я посмотрел его стримы и, таки, мне есть, что сказать.

Точнее обратиться к новичкам и "вечно обучающимся". Не тратьте время на 101% изучения языка, способов проведения тестов и постоянного надумывания, что у вас не хватает какого-нибудь опыта. Всего у вас хватает!

Патрик, не смотря на его опыт и знания, разрешает себе заглядывать в документацию Foundry, EVM, wikipedia, чтобы посмотреть, как реализовать конкретный тест или, что значит этот "сдвиг".

Это нормально! Вы не обязаны знать все, что связано с языком и работой Эфира, чтобы начать что-то делать. Просто невозможно держать все в голове.

Поэтому, немного расслабьтесь и приступайте к практике прямо сегодня.

#audit #feedback

Аудит вне рамок - 12

Интересный аудиторский отчет протокола Rysk, который попросил Trust посмотреть один единственный контракт, который напрямую связан с UniswapV3.

Стоит отметить, что только в этом одном контракте аудитор нашел 2 High, 4 Medium и 4 Low проблемы. И, не смотря на то, что некоторые ошибки можно было найти просто внимательно вчитываясь в код и его логику, несколько нюансов нужно было знать наверняка и исследовать прицельно.

Обращаем внимание при аудите

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

Также и с sqrtPriceX96 в UniswapV3. Вот кто из вас, не заглядывая в доки, может сказать, за что он отвечает? В моем случае, мне будет трудно объяснить это даже, заглянув в документацию...

Два бага в контракте были основаны на том, что разработчики не до конца понимали особенностей работы с sqrtPriceX96 (TRST-M-1, TRST-M-3).

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

#audit #outofbox

Аудит вне рамок - 13

Ранее в некоторых отчетах я натыкался на проблемы с работой enumerable контрактов с ERC721. В этом отчете можно найти прекрасные описания других проблем, но уже с 1155.

Вообще, как я понял, если в аудите вы встречаете не самый популярный контракт, те же enumerable, metadata, необычные eip, то всегда нужно уделять дополнительное время для его изучения.

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

#audit #outofbox

Аудит вне рамок - 14

Еще один интересный баг, основанный на abi.encodeWithSignature() и рефанде неиспользованного газа обратно пользователю.

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

#audit #outofbox

Аудит вне рамок - 15

Необычная особенность стандарта 4337, которая гласит, что "... to prevent replay attacks ... the signature should depend on chainid".

Другими словами, если вы используете этот eip, то в проверку подписи нужно включать еще и id блокчейн сети, так как без нее появляется возможность Cross-Chain Signature Replay Attack.

#audit #outofbox

ERC2612, ERC20Permit, аппрув без газа, EIP712

На канале у Ильи вышел новый интересный урок. Смотрим и учимся.

#erc2612 #permit #approve

ReentrancyGuard в прокси?

Необычный способ реализации ReentrancyGuard предложила одна из команд на мероприятии ETHDenver 2023 Hackathon.

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

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

Более подробно можно прочитать в этой статье.

Возможно, мы скоро увидим этот концепт в конкурсных аудитах.

#reentrancy #security #proxy

Обновления и патчи Openzeppelin

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

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

#openzeppelin

Больше о побитовых операциях

На днях в одном из конкурсных аудитов встретил следующий код:

function hasBeenDistributed(uint256 _index) public view returns (bool) {

    uint256 distributedWordIndex = _index / 256;
    uint256 distributedBitIndex = _index % 256;
    uint256 distributedWord = distributedBitMap[distributedWordIndex];
    uint256 mask = (1 << distributedBitIndex);

    return distributedWord & mask == mask;
}

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

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

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

Во-первых, читаем эту статью на Медиум.

Потом читаем пост с Solidity Developer. Спасибо @SovaSlava, что показал мне ее.

И в конце, получаем небольшой разбор с операциями со скрина.

Надеюсь, после этого вам, как и мне, станет более понятна логики таких действий.

#bitmap #bit

Интервью с Zach Obront

Недавно вышло интервью с Заком, тем самым аудитором, который вместе с Trust нашел крутой критический баг в сети Optimism.

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

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

Смотрим видео и вдохновляемся!

Приятного просмотра.

#obront

Not So-Famous Solidity Attack Vectors

Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.

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

Тем не менее, видео достойное для изучения.

#security #ethdubai