Comments 25
Жаль, реакцию Asus / Gb не опубликовали, теперь не понятно кого брать на апгрейд.
Если руковдствоваться этим докладом при выборе железа, то от апгрейда придется вообще отказаться т.к. тут в списке считай все вендоры.
Я про саму реакцию: судя по статье, Phoenix, Intel и Huawei отреагировали быстро, MS не очень.
Железки ASRock, похоже, при нахождении стоит сжечь, а СБ начать расследование с целью установления вредителя. И со стороны ASRock, и со стороны коммерческих клиентов. /irony
Железки ASRock, похоже, при нахождении стоит сжечь, а СБ начать расследование с целью установления вредителя. И со стороны ASRock, и со стороны коммерческих клиентов. /irony
Dell, HP и Lenovo в корпоративных сериях серьёзно относятся к безопасности, жаль до сих пор к ним никто не присоединился.
Gigabyte не советую, у их материнок (а ещё у MSI) даже дескриптор и регион Management Engine не заблокированы на запись, вопреки рекомендациям производителя (Intel). Производители десктопных материнок вообще относятся к безопасности прошивок отвратительно (исключение — Dell и HP благодаря тому, что они работают ещё и на корпоративный сегмент), но эта парочка хуже прочих.
ASUS иногда подкидывает сюрпризы: в прошивке своей платы я обнаружил модуль Computrace. Но в отключённом виде, что свидетельствует о том, что это издержки унификации кодовой базы, поскольку это средство удалённого доступа обычно применяется в ноутбуках. Да и в более новых версиях прошивки его вообще вырезали. Вообще, ASUS пытается хоть как-то защитить пользователя: например, в прошивке последнего поколения плат у них появился модуль, который обнаруживает попытки понижения версии прошивки Management Engine (до более старой, содержащей уязвимости) и возвращает более свежую прошивку на место.
ASUS иногда подкидывает сюрпризы: в прошивке своей платы я обнаружил модуль Computrace. Но в отключённом виде, что свидетельствует о том, что это издержки унификации кодовой базы, поскольку это средство удалённого доступа обычно применяется в ноутбуках. Да и в более новых версиях прошивки его вообще вырезали. Вообще, ASUS пытается хоть как-то защитить пользователя: например, в прошивке последнего поколения плат у них появился модуль, который обнаруживает попытки понижения версии прошивки Management Engine (до более старой, содержащей уязвимости) и возвращает более свежую прошивку на место.
UFO just landed and posted this here
А с новыми AMD с прошивками очень сложно накосячить. Если у вас есть PSP в камне (а оно стало у них практически повсеместным года с 2014), то неподписанная прошивка тупо не будет выполнена, поскольку с камня не будет снят сигнал сброса. Ну и AMD обещает адовы муки тем вендорам, которые оставят PSP в режиме разработчика.
Ничерта не понятно. Это нарушение chain of trust для подписанного кода? Или priveleged escalation? Если первое — это теоретическая головная боль для UEFI-фанбоев. Если второе — серьёзная уязвимость.
Непонятно, что именно непонятно.
Одного kernel virtual memory access хватит за глаза для поднятия привилегий до SYSTEM, если Virtualization-based security не включена. Запись в UEFI посредством MMIO access — это на сдачу уже.
Одного kernel virtual memory access хватит за глаза для поднятия привилегий до SYSTEM, если Virtualization-based security не включена. Запись в UEFI посредством MMIO access — это на сдачу уже.
userspace access от пользователя root с правом записи на устройство? Если от root'а, то их попытки оградить ядро от рута — это мишура и фигня.
Если пользователь без права доступа к устройству, посредством файловой системы и или bt-стека и т.д. — тогда ой, тогда это проблема.
Вот какой из сценариев — я пока не понимаю.
У юзера/софта, который имеет доступ к девайсу с такими драйверами появляется полный доступ ко всей системе. Рассматривайте это как [не]давнодырявые пропиетарные дрова от nvidia и злобного юзера который состоит в группе video, а в результате может спокойно нагадить куда угодно и чем угодно (ну а что, все порты ввода-вывода, вся физическая память и т.д. (если не стоит PaX+Grsecurity, хотя там для работоспособной пропиетарки надо было очень много чего делать)).
Ага, т.е. privelege escalation. Хотя я бы всё, что связано с x'ами считал бы ужасом и не обращал внимания. Если же оно доступно и через wayland, вот тогда — уже беда-беда.
Ну да, только это повышение уровня доступа таково, что многие защиты против него бесполезны. А с дырами — можно это рассмотреть как уже почти десять лет как открытую дыру про дамп оперативной памяти через FireWire, только тут даже подключать ничего не надо. Собственно говоря не nvidia единой в линуксе можно оттянуться, в дыру вполне себе попадают всякие closed source и недостаточно качественно написанные open source драйвера. Чисто теоретически дырявым может быть даже драйвер usb контроллера, а уж не давать себе любимому доступа к usb без рута весьма неудобно.
Эмм, ну это какбэ халявный мост Ring 3 -> Ring 0 с полным доступом ко всему железу.
Нет программ без уязвимостей. Есть программы, которые никто не исследовал
Ну тут есть ещё нюанс.
Некоторые производители любят вещать бла-бла-бла нам мельдоний не грозит.
Некоторые производители любят вещать бла-бла-бла нам мельдоний не грозит.
Это другой вопрос. Есть и третий — подавляющее число уязвимостей не будут использованы никогда. Как минимум в массовых атаках. Смысл использовать те же аппаратные уязвимости, если для этого нужно как минимум проникнуть в систему. А если уж проникли, то наверняка там будет вагон более простых для эксплуатации уязвимостей. По нашей статистике самая популярная уязвимость — от 12го года. В Офисе. Кому нужны навороченные уязвимости, когда тупо нет апдейтов до сих пор на офис у огромного количества народа
был написан более гибким способом, который позволяет выполнять произвольные действия от имени пространства пользователя без учета необходимых уровней безопасности.Живо вспоминается античит компании Innova, представлявший собой, по сути, руткит (пусть и созданный с целью защиты их игр от читов). Всё бы ничего, вот только программисты Инновы забыли реализовать хоть какую-то проверку того, кто управляет руткитом: игра или кто-то левый. Совершенно любой софт мог отдавать их драйверу команды, а драйвер послушно их выполнял.
Вообще, в 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.
Опять же, как будто кто-то ожидал что-то иное… Даешь всяким гражданам с горы доступ к ядру ОС — не удивляйся, что там теперь вакханалия, потому что граждане с горы решают свои собственные задачи максимально прямым и эффективным для них способом, а понять, что этот способ ломает всю модель безопасности — это надо быть специалистом по ней, и знать как эта самая модель выглядит, а специалисты эти — дорогие, и не хотят идти к китайским ОЕМам за миску риса.
Кстати говоря, есть ещё такая чЮдесная штука как Jungo Windriver (в том числе и для линукса, гыгыгы), которая максимум логики драйвера выносит в userspace (вроде как для упрощения разработки и отладки) и имеет цифровую подпись. И вот интересно, её в рамках этого исследования рассматривали?
Sign up to leave a comment.
У 17 вендоров найдены серьезные уязвимости в драйверах