Контроллер ASMedia создает проблему безопасности AMD Ryzen

Согласно отчету SafeFirmware од­ной из не­при­ят­ных осо­бен­но­с­тей про­б­ле­мы без­о­пас­нос­ти контроллеров ASMedia яв­ля­ет­ся их при­сут­ст­вие не толь­ко в дис­крет­ных чи­пах, но и в про­г­рам­мной мо­де­ли цен­т­раль­ных про­цес­со­ров AMD Ry­zen. При про­ек­ти­ро­ва­нии по­след­них бы­ла за­дей­ст­во­ва­на ин­тел­лек­ту­аль­ная соб­ст­вен­ность ASMedia, что и по­вли­я­ло на си­ту­а­цию.

История болезни и диагноз

Уязвимость состоит в использовании bus-master функциональности USB-кон­т­рол­ле­ра для незаконного доступа к памяти. Bus-master операции состоят в об­ра­ще­нии периферийного устройства к опе­ра­тив­ной памяти в обход центрального процессора (правильнее — в обход ядра центрального процессора, поскольку DRAM-контроллер физически также входит в составе микросхемы CPU).

К счастью и к несчастью

К счастью, назначение адресов, по которым bus-master устройство имеет право обратиться к ОЗУ, находится под уп­рав­ле­ни­ем драйвера устройства, а драйвер работает в режиме привилегий Kernel Mode (ring 0). Иначе такое ус­т­рой­ст­во, обращаясь к памяти в обход защиты сегментов и страниц, неизбежно станет «тараном», дающим воз­мож­ность чи­тать и писать по любому адресу ОЗУ.

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

Вместе с тем, в режиме аппаратной виртуализации ввода-вывода, когда благодаря подсистеме IOTLB, защита памяти и трансляция страниц распространяется на bus-master устройства, незаконный доступ будет перехвачен или как ми­ни­мум затруднен.

Эффективность IOTLB, как защитного механизма, зависит от сценария его ис­поль­зо­ва­ния сис­тем­ным про­грам­мным обеспечением. В типовом случае блок IOTLB способен предотвратить такие обращения к памяти, которые незаконно пересекают границы, установленные гипервизором виртуализации. Например, попытки одной из гостевых ОС по­лу­чить до­ступ к памяти хост-платформы или памяти другой гостевой ОС. При этом операции, нарушающие при­ви­ле­гии вну­три одной ОС (как хостовой, так и гостевой), обычно не блокируются средствами IOTLB.

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

Корни проблемы

Сложные периферийные контроллеры, в частности — контроллеры USB3 xHCI, нерационально строить на «жесткой ло­ги­ке» — решение выходит слишком громоздким. (Справедливости ради, на другой чаше весов в данном случае мо­жет быть увеличение производительности контроллера). Кроме того, разработчик лишается возможности исправлять ошибки проекта методом обновления микрокода. Если так, то обязательный компонент USB-кон­т­рол­ле­ра — встро­ен­ный процессор, которому требуется микрокод. Наличие микрокода означает необходимость его «прошивки». А из этого следует возможность запрограммировать bus-master устройство на доступ к памяти. И не только для об­ме­на с па­мя­тью при вы­пол­не­нии команд хоста, но и по собственному вредоносному сценарию.

Очевидно, вышесказанное относится не только к USB xHCI, и тем более не только к чипам ASMedia. Позволим себе пред­по­ло­жить, что повышенное внимание к разработкам этой компании связано с интеграцией ее решений в сис­тем­ную логику и процессоры AMD, что предъявляет более жесткие требования к надежности и безопасности, чем ста­тус про­из­во­ди­те­ля дискретных чипов.