АПИК/ЭПИК! Чипы Intel раскрывают секреты, которые не должно видеть даже ядро…

Вот BWAIN этой недели, наш шутливый термин для Ошибка с впечатляющим названием.

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

Этот дублирован ЭПИК Утечка, каламбур на словах APIC и EPIC.

Первое сокращение от Расширенный программируемый контроллер прерываний, а последнее — просто слово «эпический», как в гигант, массивный, экстремальный, мега, Humongous.

Буква Æ не использовалась в письменном английском языке с саксонских времен. Его имя æsc, произносится пепел (как в дереве), и это в значительной степени представляет звук A in в современном слове ASH. Но мы предполагаем, что вы должны произнести слово ЭПИК здесь либо как «АПИК-слеш-ЭПИК», либо как «а!-а?-ПИК».

Что все это значит?

Все это поднимает пять увлекательных вопросов:

• Что такое АПИК, а зачем мне это надо?
• Откуда у вас могут быть данные, которые даже ядро не могу заглянуть?
• В чем причина этого эпического провала в АПИК?
• Ли ЭПИК Утечка повлиять на меня?
• Что делать об этом?

Что такое АПИК?

Давайте вернемся в 1981 год, когда впервые появился IBM PC.

ПК включал в себя чип под названием Программируемый контроллер прерываний Intel 8259A, или ПОС. (Более поздние модели, начиная с PC AT, имели два PIC, соединенных вместе, для поддержки большего количества событий прерывания.)

Целью PIC было буквально прерывать программу, работающую на центральном процессоре ПК (ЦП), всякий раз, когда происходило что-то критичное по времени, требующее немедленного внимания.

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

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

Как вы можете себе представить, за PIC вскоре последовал модернизированный чип под названием APIC, продвинутый своего рода PIC, встроенный в сам процессор.

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

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

И сегодняшние чипы Intel, если мы можем сильно упростить, обычно могут быть сконфигурированы для работы двумя разными способами, известными как xAPIC-режим и режим x2APIC.

Здесь, хАПИК это «устаревший» способ извлечения данных из контроллера прерываний, и x2APIC это более современный способ.

Еще больше упрощая, xAPIC опирается на то, что называется ММИО, Короче для ввод/вывод с отображением памяти, для считывания данных из APIC при регистрации интересующего события.

В режиме MMIO вы можете узнать, что вызвало событие APIC, читая из определенной области памяти (ОЗУ), которая отражает регистры ввода/вывода самого чипа APIC.

Эти данные xAPIC отображаются в блок памяти размером 4096 байт где-то в физической оперативной памяти компьютера.

Это упрощает доступ к данным, но требует раздражающего, сложного (и, как мы увидим, потенциально опасного) взаимодействия между чипом APIC и системной памятью.

Напротив, x2APIC требует от вас считывать данные APIC напрямую от самого чипа, используя то, что известно как Специальные регистры модели (МСР).

Согласно Intel, избегая части процесса MMIO «обеспечивает значительно улучшенную адресацию процессора и некоторые улучшения в доставке прерываний».

Примечательно, что извлечение данных APIC непосредственно из встроенных регистров означает, что общий объем поддерживаемых данных и максимальное количество ядер ЦП, которыми можно управлять одновременно, не ограничены 4096 байтами, доступными в режиме MMIO.

Как у вас могут быть данные, которые даже ядро ​​​​не может просмотреть?

Вы, наверное, уже догадались, что данные, которые попадают в область памяти MMIO, когда вы используете режим xAPIC, не всегда управляются так тщательно, как следовало бы…

… и, таким образом, некая «утечка данных» в эту область MMIO является сердцевиной этой проблемы.

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

…почему данные других людей по ошибке отображаются в области данных APIC MMIO? эпический утечка?

На практике это может немного облегчить некоторые виды атак с кражей данных или очисткой ОЗУ, но, конечно же, это не даст вам больше возможностей для отслеживания памяти, которые у вас уже были в теории?

К сожалению, это предположение неверно, если какое-либо программное обеспечение в системе использует Intel SGX, сокращение от Расширения Software Guard.

---

УЗНАТЬ БОЛЬШЕ О SGX

---

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

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

После установки «блокировки» SGX анклава только программный код, работающий внутри изолированной области памяти, может читать и записывать содержимое этой оперативной памяти.

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

В том числе и само ядро.

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

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

Как вы можете себе представить, если данные, которые должны быть запечатаны внутри анклава SGX, случайно дублируются в ОЗУ MMIO, которое используется для «зеркала» данных APIC, когда вы используете режим «отображения памяти» xAPIC…

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

Что вызывает этот эпический провал в APIC?

Исследователи, стоящие за ÆPIC Герметичная бумага обнаружил, что, организовав считывание данных APIC с помощью хитроумной и необычной последовательности обращений к памяти…

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

Такое поведение является побочным эффектом того факта, что хотя размер страницы памяти APIC MMIO составляет 4096 байт, микросхема APIC в режиме xAPIC на самом деле не производит данных объемом 4096 байт, а ЦП не всегда правильно нейтрализует неиспользуемые части области MMIO, предварительно заполнив ее нулями.

Вместо этого старые данные, оставшиеся в кеше ЦП, записывались вместе с новыми данными, полученными от самого чипа APIC.

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

Влияет ли на меня утечка ÆPIC?

Полный список затронутых чипов см. собственный совет Intel.

Насколько мы можем судить, если у вас процессор Intel 10-го или 11-го поколения, вы, вероятно, пострадали.

Но если у вас новенький ЦП 12-го поколения (самый последний на момент написания статьи), то похоже, что затронуты только чипы серверного класса.

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

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

И ошибка, названная CVE-2022-21233, может использовать только злоумышленник, у которого уже есть локальный доступ на уровне администратора (root) к вашему компьютеру.

Обычные пользователи не может получить доступ к блоку данных APIC MMIO и, следовательно, не имеет возможности заглянуть туда вообще, не говоря уже о секретных данных, которые могли просочиться из анклава SGX.

Таким образом, гостевые виртуальные машины (VM), работающие под управлением операционной системы хоста в гипервизоре, таком как HyperV, VMWare или VirtualBox, почти наверняка не могут использовать этот трюк для кражи секретов от других гостей или самого хоста.

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

Что делать?

Не паникуйте.

На ноутбуке или настольном компьютере вы можете вообще не подвергаться риску, либо потому, что у вас старый (или, к счастью, совершенно новый!) Компьютер, либо потому, что вы все равно не полагаетесь на SGX.

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

Если у вас есть уязвимые серверы и вы полагаетесь на SGX как часть своей операционной безопасности, ознакомьтесь с советами по безопасности Intel. ИНТЕЛ-SA-00657 для защиты и смягчения информации.

По мнению исследователей, написавших это, «Intel [выпустила] обновления микрокода и SGX Software Development Kit, чтобы решить эту проблему».

Команда ядра Linux, похоже, сейчас работает над патчем, который позволит вам настроить вашу систему так, чтобы она всегда использовала x2APIC (который, как вы помните ранее, не передает данные APIC через разделяемую память), и изящно предотвратит принудительный возврат системы в режим xAPIC после загрузки.

---