Репост из: Протестировал
Tavis Ormandy, исследователь из Google Project Zero, сегодня в своем блоге раскрыл новую уязвимость в процессорах AMD Zen 2. Уязвимость Zenbleed затрагивает весь стек продуктов Zen 2, от процессоров AMD EPYC для центров обработки данных до процессоров Ryzen 3000, и может использоваться для кражи конфиденциальных данных, хранящихся в процессоре, включая ключи шифрования и учетные данные для входа. Атака может быть осуществлена даже удаленно через JavaScript на веб-сайте, а это означает, что злоумышленнику не нужно иметь физический доступ к компьютеру или серверу. Если у вас процессор AMD, то обязательно обновите микрокод в процессоре.
Все, дальше не буду отбирать хлеб у ресурсов на тему информационной безопасности и лучше напишу как именно уязвимость была обнаружена.
Производители регулярно используют фаззинг для тестирования своих процессоров, для такого тестирования есть даже отдельный термин — Post-Silicon Validation. Успех этой уязвимости был обусловлен использованием нетипичного источника обратной связи для фаззера и нетипичным тестовым оракулом.
Современные фаззеры используют источник обратной связи, чтобы генерировать данные, которые будут увеличивать покрытие. Проблема в том, что ничего похожего на покрытие кода в процессорах нет. Вместо счётчиков о покрытии использовали счетчики производительности, которые изначально предназначались для профилирования производительности программ. Некоторые из этих счетчиков срабатывают когда происходят всевозможные интересные архитектурные события. Это позволило находить интересные последовательности инструкций CPU.
Самый простой тестовый оракул в генеративном тестировании это "упадет"/"не упадет": передавать в программу сгенерированные данные и проверять, что нет необработанных исключений, нет аварийных завершений программы и т.д. При нормальном поведении программа не должна давать сбоев, этот постулат и используется в тестовом оракуле. С использованием такого тестового оракула для тестирования ПО всё понятно, но как узнать, что CPU правильно выполняет случайно сгенерированную программу? Один из подходов называется реверси. Общая идея состоит в том, что для каждой случайной инструкции, которую вы генерируете, вы также генерируете обратную ей (например, ADD r1, r2 → SUB r1, r2). Любое отклонение от начального состояния в конце выполнения должно быть ошибкой. Реверсивный подход хорош, но он усложняет создание тестовых сценариев для архитектуры CISC, такой как x86.
В случае с Zenbleed использовался другой тестовый оракул, который назвали "сериализованный оракул". Во время фаззинга отслеживается макроархитектурное состояние, как например значения регистров. Существует также микроархитектурное состояние, которое в основном невидимо для нас, например, предсказатель ветвлений, состояние спекулятивного выполнения инструкций и конвейер инструкций. Сериализация позволяет иметь некоторый контроль над этим, указывая CPU отключить параллельное выполнение инструкций. Основная идея сериализованного оракуласостоит в том, чтобы сгенерировать случайную программу, а затем автоматически преобразовывать её в сериализованную форму. Случайно сгенерированная последовательность инструкций и та же последовательность, но с добавлением рандомизированного выравнивания (см. пример инструкций), сериализации и спекулятивных ограждений. Эти две программы могут иметь разные характеристики производительности, но они должны выдавать одинаковый результат. Если конечные состояния не совпадают, то, должно быть, была какая-то ошибка в том, как они были выполнены на уровне микроархитектуры, что может указывать на ошибку. Так Zenbleed и обнаружили - вывод сериализованного оракула не совпал.
via
Все, дальше не буду отбирать хлеб у ресурсов на тему информационной безопасности и лучше напишу как именно уязвимость была обнаружена.
Производители регулярно используют фаззинг для тестирования своих процессоров, для такого тестирования есть даже отдельный термин — Post-Silicon Validation. Успех этой уязвимости был обусловлен использованием нетипичного источника обратной связи для фаззера и нетипичным тестовым оракулом.
Современные фаззеры используют источник обратной связи, чтобы генерировать данные, которые будут увеличивать покрытие. Проблема в том, что ничего похожего на покрытие кода в процессорах нет. Вместо счётчиков о покрытии использовали счетчики производительности, которые изначально предназначались для профилирования производительности программ. Некоторые из этих счетчиков срабатывают когда происходят всевозможные интересные архитектурные события. Это позволило находить интересные последовательности инструкций CPU.
Самый простой тестовый оракул в генеративном тестировании это "упадет"/"не упадет": передавать в программу сгенерированные данные и проверять, что нет необработанных исключений, нет аварийных завершений программы и т.д. При нормальном поведении программа не должна давать сбоев, этот постулат и используется в тестовом оракуле. С использованием такого тестового оракула для тестирования ПО всё понятно, но как узнать, что CPU правильно выполняет случайно сгенерированную программу? Один из подходов называется реверси. Общая идея состоит в том, что для каждой случайной инструкции, которую вы генерируете, вы также генерируете обратную ей (например, ADD r1, r2 → SUB r1, r2). Любое отклонение от начального состояния в конце выполнения должно быть ошибкой. Реверсивный подход хорош, но он усложняет создание тестовых сценариев для архитектуры CISC, такой как x86.
В случае с Zenbleed использовался другой тестовый оракул, который назвали "сериализованный оракул". Во время фаззинга отслеживается макроархитектурное состояние, как например значения регистров. Существует также микроархитектурное состояние, которое в основном невидимо для нас, например, предсказатель ветвлений, состояние спекулятивного выполнения инструкций и конвейер инструкций. Сериализация позволяет иметь некоторый контроль над этим, указывая CPU отключить параллельное выполнение инструкций. Основная идея сериализованного оракуласостоит в том, чтобы сгенерировать случайную программу, а затем автоматически преобразовывать её в сериализованную форму. Случайно сгенерированная последовательность инструкций и та же последовательность, но с добавлением рандомизированного выравнивания (см. пример инструкций), сериализации и спекулятивных ограждений. Эти две программы могут иметь разные характеристики производительности, но они должны выдавать одинаковый результат. Если конечные состояния не совпадают, то, должно быть, была какая-то ошибка в том, как они были выполнены на уровне микроархитектуры, что может указывать на ошибку. Так Zenbleed и обнаружили - вывод сериализованного оракула не совпал.
via