Back to Blog

Безопасность экосистемы Solana (7) — Смешение типов

April 29, 2022
4 min read

0. Обзор

1. Обзор

В предыдущем блоге мы представили реализацию общей мультиподписи. В этом посте мы обсудим еще одну проблему безопасности — подмену типов (Type Confusion).

2. Десериализация/Сериализация

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

3. Обзор кода (Подмена типов)

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

В тестовой программе мы реализовали две структуры данных: User и Metadata. Обе они записывают открытый ключ аккаунта (разных аккаунтов).

Программа имеет три различные инструкции. Инструкция InitializeUser предназначена для создания аккаунта User и установки авторизованного аккаунта (т.е. authority). Аналогично, инструкция InitializeMeta вызывается для создания аккаунта MetaData и установки обычного аккаунта (т.е. account). Инструкция Test демонстрирует, что злоумышленник может обойти логику верификации программы и провести атаку с помощью контролируемого аккаунта MetaData.

Давайте разберем инструкцию Test(). Программа гарантирует, что владельцем переданного аккаунта User является сама программа (строки 86–89). После десериализации (строка 92) программа сравнивает открытый ключ переданного аккаунта authority с открытым ключом, хранящимся в аккаунте User. Если они не совпадают, программа делает откат (строки 93–96). Последняя проверка гарантирует, что аккаунт authority подписал транзакцию. Однако, если злоумышленник передаст контролируемый им аккаунт Metadata, все проверки все равно могут быть обойдены. Причина в том, что программа не проверяет тип аккаунтов. Она получает массив байтов и десериализует его непосредственно в типы структур, определенные в программе.

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

3.1 Отправка транзакции

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

Сначала мы вызываем InitializeUser и InitializeMeta. Обратите внимание, что мы установили наш собственный открытый ключ в качестве account, хранящегося в аккаунте Metadata.

В функции test() мы передаем аккаунт Metadata в качестве аккаунта User, а наш собственный аккаунт — как authority_info (строки 347–348). Программа десериализовала Metadata как структуру User, и все проверки были обойдены.

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

4. Итоги

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

Читать другие статьи этой серии:


О компании BlockSec

BlockSec — передовая компания в сфере безопасности блокчейнов, основанная в 2021 году группой всемирно известных экспертов по безопасности. Компания стремится повысить безопасность и удобство использования развивающегося мира Web3, чтобы способствовать его массовому внедрению. Для этого BlockSec предоставляет услуги аудита безопасности смарт-контрактов и EVM-сетей, платформу Phalcon для разработки систем безопасности и проактивной блокировки угроз, платформу MetaSleuth для отслеживания и расследования транзакций, а также расширение MetaSuites для эффективной работы Web3-разработчиков в криптомире.

На сегодняшний день компания обслужила более 300 уважаемых клиентов, таких как MetaMask, Uniswap Foundation, Compound, Forta и PancakeSwap, и получила десятки миллионов долларов США в рамках двух раундов финансирования от выдающихся инвесторов, включая Matrix Partners, Vitalbridge Capital и Fenbushi Capital.

Официальный сайт: https://blocksec.com/

Официальный аккаунт в Twitter: https://twitter.com/BlockSecTeam

Sign up for the latest updates
~$5.98M Потеряно: Aztec, Raydium и другие | Еженедельник BlockSec
Security Insights

~$5.98M Потеряно: Aztec, Raydium и другие | Еженедельник BlockSec

Еженедельный отчёт о безопасности блокчейна (8–15 июня 2026 г.): 4 инцидента в Ethereum и Solana, общие потери ~$5,98 млн. Aztec Connect: отсутствие валидации входных данных привело к рассинхронизации rollup и L1. Raydium: уязвимость в AMM v3 позволила дренировать 4 пула.

Санкции OFAC против картеля Синалоа: отслеживание средств в блокчейне

Санкции OFAC против картеля Синалоа: отслеживание средств в блокчейне

OFAC ввёл санкции против сети картеля Синалоа за отмывание доходов от фентанила. Мы отследили шесть адресов в MetaSleuth: средства проходят почти исключительно через депозитные адреса централизованных бирж.

Анализ уязвимости Zcash Orchard | Еженедельник BlockSec
Security Insights

Анализ уязвимости Zcash Orchard | Еженедельник BlockSec

Критическая уязвимость в цепи Orchard Zcash: отсутствие ограничения равенства в гаджете ECC halo2 позволяло незаметно подделывать ZEC через двойное расходование. Уязвимость существовала 4+ лет, обнаружена ИИ-аудитом (Anthropic Opus 4.8, исследователь Тейлор Хорнби), устранена экстренным обновлением NU6.2.