vl4dr/cve-2024-42642Доказательства концепции эксплойтов для трех уязвимостей в механизме обновления прошивки SSD Crucial MX500, позволяющих переполнение буфера и потенциальное выполнение кода с помощью ATA-команд.
Рассматриваемое устройство — любой SSD серии MX500. Этими SSD управляет микроконтроллер Silicon-Motion SM2259 (в более старых партиях использовался более старый контроллер, Silicon-Motion SM2258, но основное внимание в этом документе уделяется новому).
SM2259 — это 4-канальный SATA 6 Гбит/с микроконтроллер с 32-битным little-endian процессором на архитектуре ARC.
При анализе последней прошивки, актуальной на дату написания документа, а именно M3CR046, было выявлено и подтверждено как статически, так и динамически несколько проблем.
Все проблемы были найдены в механизме обновления прошивки контроллера, который соответствует обработчику микроконтроллера команды ATA PIO DOWNLOAD-MICROCODE (0x92), а именно в логике загрузки прошивки методом смещений (офсетов) для подкоманд 0x03 и 0x0E.
Все ошибки, описанные в данном документе, были проверены на Crucial MX500 500GB SSD (CT500MX500SSD1), контроллере SM2259H-AC с прошивкой M3CR046 и чипами флэш-памяти NY112 на ПК с процессором x86_64.
Код прошивки отображается на базовый адрес 0x80020000, а уязвимый обработчик ATA находится по адресу 0x80024A9C. Декомпилированная версия функции для удобства приведена в файле resources/download_microcode_handler.c.
Для тех, кто не хочет вникать в технические детали, а предпочитает понять суть, обратитесь к разделу FAQ внизу.
Поскольку M3CR046 содержит несколько образов прошивки, из которых механизм обновления выбирает подходящий (возможно, в зависимости от используемых чипов флэш-памяти или других аппаратных характеристик), в этом документе будут описаны особенности первого варианта прошивки (так как именно эта прошивка поддерживается на нашем конкретном диске, и мы могли проверить только её). Однако представленные в документе ошибки, по-видимому, применимы ко всем вариантам прошивки, хотя при их воспроизведении могут быть некоторые различия в деталях.
Эта проблема относится к случаям, когда первый отправленный чанк имеет размер более 0x200 секторов. Если заглянуть внутрь обработчика ATA-команды, а именно в логику, выполняемую, когда размер чанка превышает размер сектора и чанк является первым:
Здесь устанавливаются некоторые переменные на основе следующего смещения (которое в нашем случае, поскольку мы отправили только один чанк, равно длине чанка в секторах) и переменной с именем lower_bound_fw_offset — смещения блока (т.е. смещения в единицах секторов) внутри загружаемого образа, где, как ожидается, будет найдена наша прошивка. Это жёстко заданное значение для каждого варианта прошивки; в нашем случае (первый вариант) оно равно 0.
В этом случае при вычислении разности для some_index возникает переполнение (underflow), в результате чего some_index становится равным 0xFFFF. Это неожиданное поведение, поскольку, судя по логике перемещения данных в буфер загрузки:
Мы видим, что исходный адрес, с которого копируются данные, может быть недействительным из-за неожиданного значения some_index.
При динамическом тестировании, когда был отправлен запрос на обновление прошивки с первым чанком размером более 0x200 секторов, контроллер зависает и даже не отправляет ответ на исходный запрос. Это стабильно воспроизводится.
Вероятно, это происходит из-за некорректной ссылки на вычисленный исходный адрес, что вызывает исключение, приводящее к зависанию контроллера. Это не доказано, а лишь гипотеза, объясняющая зависание.
Загружаемый образ (для M3CR046) имеет размер 0x242400 байт, и внутри этого образа находятся 3 внутренних образа прошивки, из которых только один в итоге записывается во флэш-память после процесса обновления; каждый такой образ имеет размер 0xC0C00 байт (или 0x606 секторов).
Это означает, что когда механизм обновления прошивки извлекает правильную копию прошивки из загружаемого образа, он должен убедиться, что её размер не превышает 0xC0C00 байт.
Контроллер действительно пытается это сделать, но есть некоторые краевые случаи, которые могут привести к неожиданному поведению. Взглянем на следующий фрагмент (который частично совпадает с кодом предыдущей ошибки):
Если текущий чанк имеет размер более 0x200 секторов и не является первым в последовательности, то за один раз копируется 0x200 секторов (0x40000 байт). Затем выполняется проверка, цель которой — обрезать лишние байты из количества копируемых байт, если общий размер образа прошивки превышает higher_bound_fw_offset (который в нашем случае равен 0x606 секторам, поскольку размер прошивки должен быть именно таким).
В целом эта логика имеет смысл, но есть недостаток: если последний отправленный чанк приводит к тому, что следующее смещение становится слишком большим, так что количество лишних байт превышает 0x200 секторов (или 0x40000 байт), то curr_bytes_to_copy получает «отрицательное» значение, которое переполняется (underflow) до примерно ~4 ГБ (~0xFFFFFFFF). Как мы видели ранее, эта переменная используется для определения количества байт, передаваемых в буфер загрузки.
Если заглянуть внутрь r_maybe_some_efficient_data_transfer, мы видим следующий фрагмент кода:
Это означает, что размер копирования урезается до 32 МБ (с исходного ~4 ГБ), но это всё ещё большое число, которое также может вызвать неопределённое поведение, если диапазон памяти, начинающийся с 0x40000000, имеет размер менее 32 МБ.
При динамическом тестировании, когда отправлялись ATA-чанки для достижения смещения 0x600, а затем отправлялся большой чанк размером 0x207 секторов для вызова переполнения (underflow), контроллер снова зависает, вероятно, из-за недопустимого обращения к памяти во время копирования.
Эта ошибка интереснее предыдущей, потому что, хотя у нас нет контролируемой перезаписи (а есть большая перезапись, которая, возможно, вызывает исключение, вешающее контроллер), если функция, перемещающая данные в буфер загрузки, всё же успеет передать такое количество данных до сбоя (перезаписав диапазон памяти, расположенный сразу после буфера загрузки в основной памяти), то поведение обработчика исключений может измениться на основе перезаписанных данных. Это может произойти, например, если обработчик исключений читает указатель из перезаписанной области и затем переходит по нему (данный конкретный случай маловероятен, но при дальнейших исследованиях может быть обнаружено нечто подобное).
Как уже говорилось, размер загружаемого образа составляет 0x242400 (или 0x1212 секторов). Прошивка проверяет, что общий размер переданного образа не превышает этот размер, проверяя, что следующее смещение не превышает 0x1212 секторов. Эта проверка имеет смысл, но вычисление следующего смещения содержит ошибку:
Если текущее смещение равно 0x600 секторов, а следующая обрабатываемая ATA-команда имеет достаточно большой размер (скажем, 0xFC00 секторов, что допускается стандартом ATA), то следующее смещение переполняется (wraps around), и вышеупомянутая проверка работает некорректно:
