Анализ уязвимостей компилятора Solidity и стратегии реагирования
Компилятор является одной из основных частей современных компьютерных систем. Это программа, которая преобразует высокоуровневые языки программирования в команды, исполняемые компьютером. Хотя разработчики и эксперты по безопасности обычно сосредотачиваются на безопасности кода приложений, безопасность самого компилятора также имеет важное значение.
Компилятор как компьютерная программа также может иметь уязвимости безопасности, которые в некоторых случаях могут представлять собой серьезные риски для безопасности. Например, при разборе и выполнении JavaScript-кода браузер может подвергнуться атаке из-за уязвимости в движке JavaScript, когда пользователь получает доступ к вредоносным веб-страницам, что в конечном итоге может привести к тому, что злоумышленник получит контроль над браузером жертвы или даже над операционной системой.
Компиляторы Solidity не являются исключением. Согласно предупреждениям о безопасности команды разработчиков Solidity, в нескольких версиях компилятора Solidity существуют уязвимости.
Уязвимость компилятора Solidity
Компилятор Solidity предназначен для преобразования кода смарт-контракта в машинный код инструкций Ethereum Virtual Machine (EVM). Эти инструкции EVM упаковываются в транзакции и загружаются в Ethereum, а затем выполняются EVM.
Необходимо различать уязвимости компилятора Solidity и уязвимости самого EVM. Уязвимости EVM - это проблемы безопасности, возникающие при выполнении инструкций виртуальной машины, которые могут повлиять на всю сеть Ethereum. Уязвимости компилятора Solidity - это проблемы, возникающие при преобразовании Solidity в код EVM.
Уязвимости компилятора Solidity не повлияют напрямую на сеть Ethereum, но могут привести к несоответствию сгенерированного кода EVM ожиданиям разработчиков. Поскольку смарт-контракты обычно связаны с криптовалютными активами, любые ошибки, вызванные компилятором, могут привести к потере активов пользователей, что может иметь серьезные последствия.
Только по аудиту исходного кода контракта трудно обнаружить уязвимости компилятора. Необходимо провести анализ в сочетании с конкретной версией компилятора и паттернами кода, чтобы определить, подвержен ли контракт уязвимостям компилятора.
Пример уязвимости в компиляторе Solidity
Вот несколько примеров реальных уязвимостей компилятора Solidity, демонстрирующих конкретные формы, причины и угрозы.
SOL-2016-9 HighOrderByteCleanStorage
Уязвимость существует в более ранних версиях компилятора Solidity (>=0.1.6 <0.4.4).
Рассмотрите следующий код:
солидность
контракт C {
uint32 a = 0x12345678;
uint32 b = 0;
функция run() возвращает (uint256) {
a = a + 1;
вернуть b;
}
}
Переменная storage b не была изменена, функция run() должна вернуть значение по умолчанию 0. Однако в уязвимой версии компилятора функция run() вернет 1.
Такая ситуация, не соответствующая ожиданиям, может привести к серьезным последствиям, если переменная b используется для проверки прав доступа или учета активов.
Причина этого явления заключается в том, что EVM использует элементы стека и хранилища размером 32 байта, в то время как Solidity поддерживает более мелкие типы данных, такие как uint32. Компилятор должен очищать старшие биты при обработке этих типов, но он не обработал это правильно при переполнении целого числа, что привело к записи старшего бита 1 в хранилище и перезаписи переменной b.
Уязвимость присутствует в компиляторах версий >=0.8.13 <0.8.15.
Рассмотрите следующий код:
солидность
контракт C {
функция f() публичная чистая возвращает (uint) {
сборка {
mstore(0, 0x42)
}
uint x;
сборка {
x := mload(0)
}
вернуть x;
}
}
Этот уязвимость вызвана оптимизацией компилятора. Компилятор пытался удалить кажущиеся избыточными операции записи в память, но ошибочно пересек блоки assembly для анализа. В уязвимой версии функция f() вернет 0, а не правильное 0x42.
Уязвимость затрагивает компиляторы версии >= 0.5.8 и < 0.8.16.
Рассмотрите следующий код:
солидность
контракт C {
function f(string[1] calldata a) внешних чистых возвращает (string memory) {
вернуть abi.decode(abi.encode(a), (строка[1]))[0];
}
}
В нормальных условиях этот код должен возвращать значение переменной a "aaaa". Однако в уязвимой версии он будет возвращать пустую строку "".
Это произошло из-за того, что Solidity неправильно очистил некоторые данные при выполнении операции abi.encode с массивами типа calldata, что привело к изменению соседних данных и вызвало несоответствие между закодированными и декодированными данными.
Стоит отметить, что Solidity при выполнении внешнего вызова и эмитировании события неявно выполняет abi.encode, поэтому влияние таких уязвимостей может быть шире, чем ожидалось.
Рекомендации по безопасности
На основе анализа модели угроз уязвимостей компилятора Solidity и исторического обзора уязвимостей предлагаются следующие рекомендации для разработчиков и специалистов по безопасности:
Для разработчиков:
Используйте более новую версию компилятора Solidity. Новые версии обычно исправляют известные проблемы безопасности.
Улучшите модульные тесты. Большинство ошибок на уровне компилятора приводят к тому, что результат выполнения кода не соответствует ожиданиям, и повышение покрытия кода может помочь выявить такие проблемы на этапе тестирования.
Избегайте использования встроенной ассемблерной программы, сложной ABI кодировки и декодирования и других операций. Большинство исторических уязвимостей связано с этими сложными особенностями.
Для сотрудников безопасности:
Не игнорируйте потенциальные риски безопасности, которые могут быть вызваны компилятором во время аудита. Соответствующий элемент проверки классификации уязвимостей смарт-контрактов (SWC) - SWC-102.
Внутри процесса SDL необходимо побуждать команду разработчиков обновить версию компилятора Solidity и рассмотреть возможность внедрения автоматической проверки в CI/CD.
Не стоит чрезмерно беспокоиться о уязвимостях компилятора. Большинство уязвимостей срабатывают только в определенных кодовых паттернах, и необходимо оценивать фактическое влияние в зависимости от конкретной ситуации.
Практические ресурсы:
Безопасное предупреждение от команды Solidity:
Официальный список ошибок Solidity:
Список ошибок компилятора для всех версий:
Значок предупреждения в правом верхнем углу страницы кода контракта Etherscan может указывать на наличие у текущей версии компилятора уязвимостей безопасности.
Резюме
В данной статье рассматривается концепция уязвимостей компилятора Solidity, анализируются потенциальные риски безопасности, которые могут возникнуть в процессе реальной разработки на Ethereum, а также предлагаются практические рекомендации для разработчиков и специалистов по безопасности. Понимание характеристик и последствий уязвимостей компилятора поможет лучше защитить безопасность смарт-контрактов.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
3
Поделиться
комментарий
0/400
DataBartender
· 18ч назад
Безопасность не имеет конца, временные заплатки не выдержат.
Посмотреть ОригиналОтветить0
Ser_This_Is_A_Casino
· 18ч назад
Уязвимости — это причины, по которым кошелек улетает.
Анализ уязвимостей компилятора Solidity и стратегии безопасности
Анализ уязвимостей компилятора Solidity и стратегии реагирования
Компилятор является одной из основных частей современных компьютерных систем. Это программа, которая преобразует высокоуровневые языки программирования в команды, исполняемые компьютером. Хотя разработчики и эксперты по безопасности обычно сосредотачиваются на безопасности кода приложений, безопасность самого компилятора также имеет важное значение.
Компилятор как компьютерная программа также может иметь уязвимости безопасности, которые в некоторых случаях могут представлять собой серьезные риски для безопасности. Например, при разборе и выполнении JavaScript-кода браузер может подвергнуться атаке из-за уязвимости в движке JavaScript, когда пользователь получает доступ к вредоносным веб-страницам, что в конечном итоге может привести к тому, что злоумышленник получит контроль над браузером жертвы или даже над операционной системой.
Компиляторы Solidity не являются исключением. Согласно предупреждениям о безопасности команды разработчиков Solidity, в нескольких версиях компилятора Solidity существуют уязвимости.
Уязвимость компилятора Solidity
Компилятор Solidity предназначен для преобразования кода смарт-контракта в машинный код инструкций Ethereum Virtual Machine (EVM). Эти инструкции EVM упаковываются в транзакции и загружаются в Ethereum, а затем выполняются EVM.
Необходимо различать уязвимости компилятора Solidity и уязвимости самого EVM. Уязвимости EVM - это проблемы безопасности, возникающие при выполнении инструкций виртуальной машины, которые могут повлиять на всю сеть Ethereum. Уязвимости компилятора Solidity - это проблемы, возникающие при преобразовании Solidity в код EVM.
Уязвимости компилятора Solidity не повлияют напрямую на сеть Ethereum, но могут привести к несоответствию сгенерированного кода EVM ожиданиям разработчиков. Поскольку смарт-контракты обычно связаны с криптовалютными активами, любые ошибки, вызванные компилятором, могут привести к потере активов пользователей, что может иметь серьезные последствия.
Только по аудиту исходного кода контракта трудно обнаружить уязвимости компилятора. Необходимо провести анализ в сочетании с конкретной версией компилятора и паттернами кода, чтобы определить, подвержен ли контракт уязвимостям компилятора.
Пример уязвимости в компиляторе Solidity
Вот несколько примеров реальных уязвимостей компилятора Solidity, демонстрирующих конкретные формы, причины и угрозы.
SOL-2016-9 HighOrderByteCleanStorage
Уязвимость существует в более ранних версиях компилятора Solidity (>=0.1.6 <0.4.4).
Рассмотрите следующий код:
солидность контракт C { uint32 a = 0x12345678; uint32 b = 0; функция run() возвращает (uint256) { a = a + 1; вернуть b; } }
Переменная storage b не была изменена, функция run() должна вернуть значение по умолчанию 0. Однако в уязвимой версии компилятора функция run() вернет 1.
Такая ситуация, не соответствующая ожиданиям, может привести к серьезным последствиям, если переменная b используется для проверки прав доступа или учета активов.
Причина этого явления заключается в том, что EVM использует элементы стека и хранилища размером 32 байта, в то время как Solidity поддерживает более мелкие типы данных, такие как uint32. Компилятор должен очищать старшие биты при обработке этих типов, но он не обработал это правильно при переполнении целого числа, что привело к записи старшего бита 1 в хранилище и перезаписи переменной b.
SOL-2022-4 ВстраиваемаяАссемблернаяПамятьПобочныеЭффекты
Уязвимость присутствует в компиляторах версий >=0.8.13 <0.8.15.
Рассмотрите следующий код:
солидность контракт C { функция f() публичная чистая возвращает (uint) { сборка { mstore(0, 0x42) } uint x; сборка { x := mload(0) } вернуть x; } }
Этот уязвимость вызвана оптимизацией компилятора. Компилятор пытался удалить кажущиеся избыточными операции записи в память, но ошибочно пересек блоки assembly для анализа. В уязвимой версии функция f() вернет 0, а не правильное 0x42.
SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
Уязвимость затрагивает компиляторы версии >= 0.5.8 и < 0.8.16.
Рассмотрите следующий код:
солидность контракт C { function f(string[1] calldata a) внешних чистых возвращает (string memory) { вернуть abi.decode(abi.encode(a), (строка[1]))[0]; } }
В нормальных условиях этот код должен возвращать значение переменной a "aaaa". Однако в уязвимой версии он будет возвращать пустую строку "".
Это произошло из-за того, что Solidity неправильно очистил некоторые данные при выполнении операции abi.encode с массивами типа calldata, что привело к изменению соседних данных и вызвало несоответствие между закодированными и декодированными данными.
Стоит отметить, что Solidity при выполнении внешнего вызова и эмитировании события неявно выполняет abi.encode, поэтому влияние таких уязвимостей может быть шире, чем ожидалось.
Рекомендации по безопасности
На основе анализа модели угроз уязвимостей компилятора Solidity и исторического обзора уязвимостей предлагаются следующие рекомендации для разработчиков и специалистов по безопасности:
Для разработчиков:
Используйте более новую версию компилятора Solidity. Новые версии обычно исправляют известные проблемы безопасности.
Улучшите модульные тесты. Большинство ошибок на уровне компилятора приводят к тому, что результат выполнения кода не соответствует ожиданиям, и повышение покрытия кода может помочь выявить такие проблемы на этапе тестирования.
Избегайте использования встроенной ассемблерной программы, сложной ABI кодировки и декодирования и других операций. Большинство исторических уязвимостей связано с этими сложными особенностями.
Для сотрудников безопасности:
Не игнорируйте потенциальные риски безопасности, которые могут быть вызваны компилятором во время аудита. Соответствующий элемент проверки классификации уязвимостей смарт-контрактов (SWC) - SWC-102.
Внутри процесса SDL необходимо побуждать команду разработчиков обновить версию компилятора Solidity и рассмотреть возможность внедрения автоматической проверки в CI/CD.
Не стоит чрезмерно беспокоиться о уязвимостях компилятора. Большинство уязвимостей срабатывают только в определенных кодовых паттернах, и необходимо оценивать фактическое влияние в зависимости от конкретной ситуации.
Практические ресурсы:
Резюме
В данной статье рассматривается концепция уязвимостей компилятора Solidity, анализируются потенциальные риски безопасности, которые могут возникнуть в процессе реальной разработки на Ethereum, а также предлагаются практические рекомендации для разработчиков и специалистов по безопасности. Понимание характеристик и последствий уязвимостей компилятора поможет лучше защитить безопасность смарт-контрактов.