На конференции DEF CON 2019 в Лас-Вегасе (штат Невада, США) эксперты по безопасности из компании Eclypsium представили доклад о стандартных ошибках и уязвимостях при разработке ПО, которые они нашли в 42 драйверах режима ядра, исследовав программное обеспечение почти двух десятков различных производителей. Причем, их обращения и вопросы по этому исследованию некоторые производители оборудования просто проигнорировали.
Специалисты по безопасности Джесси Майкл (Jesse Michael) и Микки Шкатов (Mickey Shkatov) компании Eclypsium изучили более 40 драйверов различных вендоров и обнаружили типовые ошибки ПО и уязвимости, которые позволяют приложениям с низким уровнем доступа использовать заложенные в драйверы функции для выполнения злонамеренных действий в наиболее «чувствительных» зонах операционной системы, таких как ядро ОС.
В список вендоров оборудования, драйвера которых имеют серьезные и схожие уязвимости входят:
— American Megatrends International (AMI);
— ASRock;
— ASUSTeK Computer;
— ATI Technologies (AMD);
— Biostar;
— EVGA;
— Getac;
— GIGABYTE;
— Huawei;
— Insyde;
— Intel;
— Micro-Star International (MSI);
— NVIDIA;
— Phoenix Technologies;
— Realtek Semiconductor;
— SuperMicro;
— Toshiba.
«Существует ряд аппаратных ресурсов, которые обычно доступны только с помощью привилегированного программного обеспечения, такого как ядро ??ОС, и должны быть защищены от вредоносного режима чтения или записи из приложений пользовательского пространства», — заявил в своем выступлении Микки Шкатов, специалист по безопасности компании Eclypsium.
«Однако, в ряде рассмотренных нами случаев был обнаружен схожий и определенный «дефект» в механизме работы драйверов, заложенный еще на стадии их создания и компиляции, когда подписанные драйверы предоставляют функциональные возможности, которые могут неправильно использоваться приложениями пользовательского пространства для произвольного чтения или записи этих конфиденциальных ресурсов без каких-либо ограничений или проверок со стороны ОС», — рассказал Микки Шкатов.
В заключении своего выступления эксперты по безопасности из компании Eclypsium утверждают, что обнаруженные ими ошибки и уязвимости в драйверах многих вендоров — это результат «плохой» практики при разработке ПО, которая не учитывает необходимые уровни безопасности при разработке драйверов и дальнейших их проверок перед выпуском в производство.
Оказывается, что многими вендорами при разработке драйверов использовался общий шаблон проектирования программного обеспечения, который вместо того, чтобы в каждом отдельном случае заставлять драйвер выполнять только определенные и конкретные задачи, был написан более гибким способом, который позволяет выполнять произвольные действия от имени пространства пользователя без учета необходимых уровней безопасности.
А ведь такая практика может привести к печальным последствиям как для пользователей, так и для разработчиков драйверов и производителей оборудования.
Полную версию своего исследования с примерами использования уязвимостей в драйверах вендоров Джесси Майкл и Микки Шкатов представили в своем докладе на конференции DEF CON 2019.
Прошу ознакомиться с этим pdf-файлом прежде, чем задавать технические вопросы в комментариях.
Ссылка на полную версию доклада «Get off the kernel if you cant drive».
Некоторые слайды из публикации «Get off the kernel if you cant drive» экспертов по безопасности из компании Eclypsium.
Как отреагировали различные Вендоры на исследование экспертов по безопасности из компании Eclypsium:
Комментарии (24)
amarao
12.08.2019 16:40Ничерта не понятно. Это нарушение chain of trust для подписанного кода? Или priveleged escalation? Если первое — это теоретическая головная боль для UEFI-фанбоев. Если второе — серьёзная уязвимость.
CodeRush
13.08.2019 01:30Непонятно, что именно непонятно.
Одного kernel virtual memory access хватит за глаза для поднятия привилегий до SYSTEM, если Virtualization-based security не включена. Запись в UEFI посредством MMIO access — это на сдачу уже.amarao
13.08.2019 10:54userspace access от пользователя root с правом записи на устройство? Если от root'а, то их попытки оградить ядро от рута — это мишура и фигня.
Если пользователь без права доступа к устройству, посредством файловой системы и или bt-стека и т.д. — тогда ой, тогда это проблема.
Вот какой из сценариев — я пока не понимаю.
JerleShannara
14.08.2019 01:31У юзера/софта, который имеет доступ к девайсу с такими драйверами появляется полный доступ ко всей системе. Рассматривайте это как [не]давнодырявые пропиетарные дрова от nvidia и злобного юзера который состоит в группе video, а в результате может спокойно нагадить куда угодно и чем угодно (ну а что, все порты ввода-вывода, вся физическая память и т.д. (если не стоит PaX+Grsecurity, хотя там для работоспособной пропиетарки надо было очень много чего делать)).
amarao
14.08.2019 11:32Ага, т.е. privelege escalation. Хотя я бы всё, что связано с x'ами считал бы ужасом и не обращал внимания. Если же оно доступно и через wayland, вот тогда — уже беда-беда.
JerleShannara
14.08.2019 16:35Ну да, только это повышение уровня доступа таково, что многие защиты против него бесполезны. А с дырами — можно это рассмотреть как уже почти десять лет как открытую дыру про дамп оперативной памяти через FireWire, только тут даже подключать ничего не надо. Собственно говоря не nvidia единой в линуксе можно оттянуться, в дыру вполне себе попадают всякие closed source и недостаточно качественно написанные open source драйвера. Чисто теоретически дырявым может быть даже драйвер usb контроллера, а уж не давать себе любимому доступа к usb без рута весьма неудобно.
JerleShannara
13.08.2019 03:44Эмм, ну это какбэ халявный мост Ring 3 -> Ring 0 с полным доступом ко всему железу.
teecat
12.08.2019 18:31Нет программ без уязвимостей. Есть программы, которые никто не исследовал
OnelaW
13.08.2019 10:00Ну тут есть ещё нюанс.
Некоторые производители любят вещать бла-бла-бла нам мельдоний не грозит.teecat
13.08.2019 10:22Это другой вопрос. Есть и третий — подавляющее число уязвимостей не будут использованы никогда. Как минимум в массовых атаках. Смысл использовать те же аппаратные уязвимости, если для этого нужно как минимум проникнуть в систему. А если уж проникли, то наверняка там будет вагон более простых для эксплуатации уязвимостей. По нашей статистике самая популярная уязвимость — от 12го года. В Офисе. Кому нужны навороченные уязвимости, когда тупо нет апдейтов до сих пор на офис у огромного количества народа
dartraiden
12.08.2019 22:22+1был написан более гибким способом, который позволяет выполнять произвольные действия от имени пространства пользователя без учета необходимых уровней безопасности.
Живо вспоминается античит компании Innova, представлявший собой, по сути, руткит (пусть и созданный с целью защиты их игр от читов). Всё бы ничего, вот только программисты Инновы забыли реализовать хоть какую-то проверку того, кто управляет руткитом: игра или кто-то левый. Совершенно любой софт мог отдавать их драйверу команды, а драйвер послушно их выполнял.zedroid
13.08.2019 07:51Вообще, в Linux driver development базовой книге по написанию драйверов предлагается следующий подход по написанию драйвера как основной:
As a programmer, you are able to make your own choices about your driver, and choose an acceptable trade-off between the programming time required and the flexibility of the result. Though it may appear strange to say that a driver is «flexible,» we like this word because it emphasizes that the role of a device driver is providing mechanism, not policy.
The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: «what capabilities are to be provided» (the mechanism) and «how those capabilities can be used» (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.
CodeRush
13.08.2019 01:35Опять же, как будто кто-то ожидал что-то иное… Даешь всяким гражданам с горы доступ к ядру ОС — не удивляйся, что там теперь вакханалия, потому что граждане с горы решают свои собственные задачи максимально прямым и эффективным для них способом, а понять, что этот способ ломает всю модель безопасности — это надо быть специалистом по ней, и знать как эта самая модель выглядит, а специалисты эти — дорогие, и не хотят идти к китайским ОЕМам за миску риса.
JerleShannara
13.08.2019 04:00«Ну а зачем мне в драйвере проверять, в какой порт он писать будет, онж только для моей пупержелезки»
JerleShannara
14.08.2019 16:38Кстати говоря, есть ещё такая чЮдесная штука как Jungo Windriver (в том числе и для линукса, гыгыгы), которая максимум логики драйвера выносит в userspace (вроде как для упрощения разработки и отладки) и имеет цифровую подпись. И вот интересно, её в рамках этого исследования рассматривали?
DrunkBear
Жаль, реакцию Asus / Gb не опубликовали, теперь не понятно кого брать на апгрейд.
oldbie
Если руковдствоваться этим докладом при выборе железа, то от апгрейда придется вообще отказаться т.к. тут в списке считай все вендоры.
DrunkBear
Я про саму реакцию: судя по статье, Phoenix, Intel и Huawei отреагировали быстро, MS не очень.
Железки ASRock, похоже, при нахождении стоит сжечь, а СБ начать расследование с целью установления вредителя. И со стороны ASRock, и со стороны коммерческих клиентов. /irony
navion
Dell, HP и Lenovo в корпоративных сериях серьёзно относятся к безопасности, жаль до сих пор к ним никто не присоединился.
CodeRush
Дорого это все очень, и продать потом очень трудно, потому что для обычного пользователя хватает «у нас точно все безопасное, мамой клянемся!» и «смотрите зато какая у нас RGB-подсветка моднючая!».
dartraiden
Gigabyte не советую, у их материнок (а ещё у MSI) даже дескриптор и регион Management Engine не заблокированы на запись, вопреки рекомендациям производителя (Intel). Производители десктопных материнок вообще относятся к безопасности прошивок отвратительно (исключение — Dell и HP благодаря тому, что они работают ещё и на корпоративный сегмент), но эта парочка хуже прочих.
ASUS иногда подкидывает сюрпризы: в прошивке своей платы я обнаружил модуль Computrace. Но в отключённом виде, что свидетельствует о том, что это издержки унификации кодовой базы, поскольку это средство удалённого доступа обычно применяется в ноутбуках. Да и в более новых версиях прошивки его вообще вырезали. Вообще, ASUS пытается хоть как-то защитить пользователя: например, в прошивке последнего поколения плат у них появился модуль, который обнаруживает попытки понижения версии прошивки Management Engine (до более старой, содержащей уязвимости) и возвращает более свежую прошивку на место.
Am0ralist
А с AMD нет ещё инфы кто как косячит?
JerleShannara
А с новыми AMD с прошивками очень сложно накосячить. Если у вас есть PSP в камне (а оно стало у них практически повсеместным года с 2014), то неподписанная прошивка тупо не будет выполнена, поскольку с камня не будет снят сигнал сброса. Ну и AMD обещает адовы муки тем вендорам, которые оставят PSP в режиме разработчика.