Исследователи из трёх европейских университетов раскрыли детали первой известной атаки на SGX.Набор инструкций SGX (Software Guard eXtensions) позволяет приложению создавать анклавы — области в виртуальном адресном пространстве, защищённые от чтения и записи извне этой области другими процессами, включая ядро операционной системы. Анклавы изолированы на аппаратном и программном уровне: эта память физически отделена от остальной памяти процессора и зашифрована.
Атака Plundervolt (CVE-2019-11157) использует интерфейс ОС для управления напряжением и частотой процессора Intel — тот же интерфейс, который используется для разгона CPU при оверклокинге. Изменяя напряжение CPU, она за несколько минут извлекает данные из анклава, в том числе ключи шифрования.
Код демонстрационного эксплоита опубликован на GitHub. Уязвимые процессоры:
- Intel Core 6, 7, 8, 9 и 10 поколений
- Intel Xeon E3 v5 и v6
- Intel Xeon E-2100 и E-2200
Исследователям удалось объединить концепции двух известных атак:
- Rowhammer: изменение битового значения ячейки памяти DRAM с 1 на 0 и наоборот путём записи данных в соседние ячейки.
- CLKSCREW манипуляции энергопитанием процессора Dynamic Voltage and Frequency Scaling (DVFS).
Plundervolt сочетает в себе принципы, лежащие в основе этих двух атак. Через DVFS она изменяет напряжение в ячейках памяти SGX, что приводит к нежелательным изменениям данных в анклаве.
Работа основана на проведённом ранее реверс-инжиниринге процессоров Intel. Тот выявил, какие регистры MSR (ModelSpecific Register) отвечают за динамическое изменение напряжения CPU после программной команды. Такие регистры есть во всех процессорах Intel.
Схема недокументированного регистра MSR c адресом 0x150
Как выяснилось, в уязвимых процессорах происходит предсказуемая замена бит. Например, в процессоре Core i3-7100U при понижении напряжения на 118 мВ операция
0x80D36 * 0x21 = 0x109b3f6 даёт предсказуемо сбойное значение 0xffffffffe109b417 на частоте 2 ГГц. Другие примеры сбойных умножений в Core i3-7100U на частоте 2 ГГц:
Эти небольшие изменения не нарушают секретность SGX. Вместо этого они вводят ошибки в операции SGX по обработке данных. Другими словами, Plundervolt не взламывает SGX, а изменяет результат: «Понижение напряжения индуцирует изменение битов в инструкциях процессора, таких как умножение или раунды шифрования AES (AES-NI)», — объясняет Дэвид Освальд, академик из Бирмингемского университета, один из авторов научной работы. — Поскольку SGX шифрует данные только при чтении и записи в память (но не внутри процессора), то защита памяти SGX не предотвращает эти ошибки (так как неисправные значения сами записываются в память)».
Plundervolt позволяет увидеть шифрованные сообщения на выходе из анклава SGX, а затем восстановить секретный ключ, который изначально использовался для шифрования данных.
Исследователи продемонстрировали эффективность атаки, введя ошибки в реализации Intel RSA-CRT и AES-NI, работающие в анклаве SGX. Им удалось восстановить полные криптографические ключи с незначительными вычислительными усилиями.
Код для проверки атаки (репозиторий на GitHub)
Описанная атака не требует радикального повышения напряжения, так что не угрожает физической безопасности чипа. На самом деле этой свойство Plundervolt делает атаку ещё опаснее. Ещё одно опасное свойство — она гораздо быстрее, чем большинство других атак на процессоры Intel, таких как Spectre, Meltdown, Zombieload, RIDL и прочие. В таблице указано количество итераций до появления ошибки умножения (
0xAE0000 * 0x18) на разных значениях пониженного напряжения в I3-7100U на 2 ГГц:
Изменение битов в умножениях AES осуществляются очень быстро. Например, извлечение ключа AES занимает несколько минут, включая вычисление, необходимое для получения ключа из неисправного шифротекста, говорит Освальд.
К сожалению для злоумышленников, атаку Plundervolt трудно провести удалённо. Нельзя заманить пользователя на веб-сайт и запустить JavaScript. Напряжение CPU таким методом не изменяется. Для работы Plundervolt требует наличия на компьютере жертвы приложения на с правами root или admin. Это требует социальной инженерии и применения дополнительных эксплоитов.
Plundervolt не работает в виртуализированных средах, таких как виртуальные машины и службы облачных вычислений, где у гостевой ОС нет доступа к интерфейсу, управляющему напряжением процессора.
Тем не менее, Plundervolt является серьёзной проблемой. Исследовательская группа уведомила Intel об уязвимости в июне 2019 года, и с тех пор производитель CPU работал над патчами. Обновления микрокода и BIOS выпущены 10 декабря 2019 года в рамках рекомендаций по безопасности INTEL-SA-00289. После установки патчей в BIOS можно отключить интерфейс по управлению напряжением и тактовой частотой.
Техническое описание атаки см. в научной статье (pdf), которая выйдет в сборнике Proceedings of the 41st IEEE Symposium on Security and Privacy.
Комментарии (57)
Sabubu
16.12.2019 18:13+8Это как раз пример хорошей уязвимости.
Единственное назначение таких "анклавов" — это запуск кода, неконтролируемого администратором системы. Например, код DRM для генерации ключей, проверка подлинности игр, "закладки", итд. Соответственно, эта уязвимость лишь возвращает администратору машины потерянную власть и позволяет "заглянуть" внутрь анклава. Что тут плохого?
Воспользоваться уявзимостью можно только из режима ядра, с высокими привилегиями. Таким образом, риск она создает только для правоторговцев, что их алгоритмы защиты вытащат на белый свет.
Мне кажется, с этой фичей надо бороться. На процессоре не должно быть неподконтрольного администратору кода, как бы правообладатели и правительства этого не хотели.
Tangeman
16.12.2019 19:04На процессоре не должно быть неподконтрольного администратору кода, как бы правообладатели и правительства этого не хотели.
Т.е. клиенты облачного провайдера не должны иметь права на приватность в своих виртуалках?
vanxant
16.12.2019 19:22+1Виртуалку можно легко эмулировать полностью, так что всё, что вы отдали в облако считается опубликованным на заборе в интернете, если только в вашем договоре с облаком явно не указаны классы защиты информации типа PSI DSS и конские штрафы за любые утечки по вине облака (ну и с конским ценником за услуги разумеется).
Tangeman
17.12.2019 21:54При наличии умысла со стороны провайдера — ясный пень, возможно обойти почти всё, но речь идёт хотя бы о том чтобы защитить виртуалки от чрезмерно любопытных или неадекватных админов (или кул-хацкеров) в нормальных ДЦ. Думаю, один админ из десятков не сможет такое замутить незаметно от остальных, да и полностью эмулированная виртуалка проявит себя как минимум в очень низкой производительности.
Это же, кстати, применимо и d банальных собственных ДЦ — чтобы слишком любопытные не совали нос куда не следует, даже если получили где-то админские права.sergeyns
18.12.2019 09:30-1Ой, как обычно меня минусуют за недовольство тем, что многий промышленный софт хранит ключи в незашифрованном виде на диске… Мол все равно доступ к диску только у админов…
defuz
17.12.2019 03:15+1Теоретически, если мой код или данные зашифрованы публичным ключем, подписанным Intel, приватный ключ которого доступен только из защищенного анклава целевого процессора, стоящего в стойке облачного провайдера, то как бы провайдер не эмулировал мою виртуалку, он не получит доступ к моим данным и коду. Теоретически.
tbl
18.12.2019 01:54PCI DSS накладывает ограничение на весь АПК, а не только одну его часть, даже если она сразу по мановению волшебной палочки делает всю систему «защищенной».
PCI DSS — это в первую очередь про процессы и регламенты, а уж только потом про архитектуру и инфраструктуру.
Так же, массовые серверные интелловские процы архитектуры x86/x86_64 никогда не будут использованы в HSM, которые поставляются для организаций попадающих под требования PCI DSS Level 1 и 2, потому что такие HSM не пройдут аудит.
vanxant
18.12.2019 05:35Не могли бы вы пояснить мне и 99% остальных читателей, почему облачный провайдер не сможет внезапно эмулировать вашу виртуалку? Некий особо-секретный-ключ зашит прямо в процессор (чипсет)? Если он уникален, то как быть с оркестрацией? Если не уникален, то что мешает эмулировать или считать-кому-надо?
Sabubu
16.12.2019 19:26Если вы хотите приватности, дешевле поставить дома старый компьютер и купить белый IP.
Tangeman
17.12.2019 22:12Конечно. Только два компьютера, для резерва. А ещё купить пару независимых каналов минимум по гигабиту каждый (сервер же), мощную железную дверь и толстые стены из армированного бетона, решетки на окна (хотя лучше их вообще замуровать), сигнализацию и видеонаблюдение поставить, нанять круглосуточную охрану, и не забыть хороший дизельный генератор с батареей в качестве UPS — очень дешево, и правда, да и соседям нескучно будет.
Приватность, знаете-ли, не ограничивается бытовыми потребностями, и не всегда речь о своей собственной, к тому же.Sabubu
17.12.2019 02:11+1SGX не защищает всю память или диск вашей виртуалки, а только анклав (в котором алгоритм с каким-то ключом и данными). Хостер по-прежнему может ковыряться в памяти и на диске. Зачем вам такая псевдозащита?
Для того, чтобы убедиться, что вы работаете с реальным анклавом, а не с эмулятором, процессор умеет делать подпись, которую можно проверить через Intel — но это стоит денег.
Так что давайте подумаем еще раз, для каких целей он придуман?
Я, впрочем, читал, что его можно как-то использовать для удаленной верификации машины, что например в ней не подменили ядро ОС или что-то такое.
Tangeman
17.12.2019 04:00Хостер по-прежнему может ковыряться в памяти и на диске.
Только если диск не защищен ключом который как раз можно спрятать в анклаве, как и прочие ненужные любопытным вещи, благо туда влезет как минимум 90M (и это явно временное ограничение).
Самое очевидное применение — это загрузка системы с полным шифрованием, без SGX (или SME/SEV от AMD) трудно гарантировать что ключи не будут перехвачены.
Впрочем, если уж хостер настроен на целевую атаку, то бороться с ним будет сложно, но с другой стороны, тот у кого действительно остро стоит вопрос с доверием вряд ли будет хостится в облаке, и уж тем более у провайдера который потенциально может оказаться слишком любопытным.
На самом деле высказывания против таких технологий (в духе «админ должен иметь возможность...») чем-то напоминают телодвижения некоторых властей, которые против шифрования и приватности, не находите?Sabubu
18.12.2019 10:48-1Только если диск не защищен ключом который как раз можно спрятать в анклаве,
А как ключ попадет в анклав при загрузке? Анклав это же RAM. Также, анклав не защищает всю память, где хранятся данные в открытом виде.
Это явно сделано для DRM. Если у вас настолько важные и секретные данные, то вы можете позволить себе свой сервер.
На самом деле высказывания против таких технологий (в духе «админ должен иметь возможность...») чем-то напоминают телодвижения некоторых властей, которые против шифрования и приватности, не находите?
Нет. Надо быть айтишником, чтобы на полном серьезе сравнивать компьютер и государство. А то вас начнет совесть мучать при "убийстве" зависшего процесса. Мой компьютер это вещь, в котором находятся бездушные байты, а в государстве живые люди с правами.
И, если уж на то пошло, SGX скорее удобен государству — внедрить вам "анклав" и следить за вами оттуда.
Tangeman
18.12.2019 13:43+1А как ключ попадет в анклав при загрузке?
Я не сильно углублялся в детали, но принцип такой же как и в случае TPM — есть код (без секретов) который аттестируется и привязывается к CPU (каждый имеет свой уникальный ключ), а имея код которому можно доверять уже можно и приватными ключами заняться, например, путём передачи этому коду другого кода или секретного/приватного ключа посредством публичного ключа в изначальном коде.
Это явно сделано для DRM.
DRM — это всего лишь частный случай применения. Эдак можно сказать что некоторые кухонные ножи явно сделаны для убийств, с учётом их размеров и остроты.
Мой компьютер это вещь, в котором находятся бездушные байты, а в государстве живые люди с правами.
Наверное, именно так рассуждают в Facebook & co, приторговывая данными пользователей — это ведь всего лишь бездушные байты.
Как-то страшновато доверять свою информацию и даже процессы хостеру если он считает что всё что хранится и выполняется в его компе — всего лишь «бездушные байты». В конце концов, тот процесс который он может захотеть убить может быть для меня (или моего бизнеса) жизненно важным, не говоря уже о моих данных в которые он лезть не должен, а я ведь вполне живой человек с правами.
Jammarra
17.12.2019 20:06+1Кто то на Хабре верит в приватность данных на облаке?).
Tangeman
17.12.2019 22:04SGX & co. позволяют эту приватность обеспечить, хотя бы в принципе. И да, пока ещё есть в мире страны и провайдеры, где «заплатки» в ДЦ ну очень маловероятны.
AgentRX
18.12.2019 09:47Ну еще есть разные математические технологии типа доказательств с нулевым разглашением. Но они имеею много ограничений и ньюансов.
grishkaa
16.12.2019 23:23По такой логике этот набор инструкций должен существовать только в серверных процессорах. Но те же i3 в сервера никто не ставит, насколько мне известно.
Am0ralist
18.12.2019 09:58+1Вам не верно известно, i3-i5 (а так же celeron и pentium) в версиях T могут иметь официальную поддержку ECC и использоваться в серверах. Самое известное — Microserver Gen8 в минимальной конфигурации имел как раз целерон, затем пенёк и только в максимальной конфиге ксеон е3 в2, а совместимость реальная была с большим количеством процессоров. У самого в нём i5-T стоит.
splix
17.12.2019 20:06SGX также позволял скрыть ключи от соседнего админа на машине, который, к слову, мог получить право неправомерное, т.е. через другую уязвимость.
HardWrMan
18.12.2019 07:50-1Дык, может поэтому и подняли бучу, чтобы люди повыкидывали невыгодные процессоры и побежали заносить в кассу за новые защищённые от пользователя?
MaximRV
18.12.2019 10:27+1ну, это если бы не было конкурента
HardWrMan
18.12.2019 12:14А разве есть уверенность, что у конкурента безопаснее? Если ещё не нашли это не означает что нету. Хоть бери и сам делай свой процессор, но при этом нет уверенности даже в FPGA, т.к. они тоже у заинтересованных лиц производятся.
Am0ralist
18.12.2019 12:23Ну пока все предыдущие дыры на АМД оказались вроде как слабее, чем у Интела и прошивками были поправлены, тогда как Интел так и не выкатил пока новых чипов с исправлениями.
Так что вполне вариант, что эту дыру сразу же и на АМД проверили и схожей возможности не нашли.
AgentRX
18.12.2019 09:44+1Извините за смежный пример, но вот та же атомная электростанция. Вы считаете, что оператор пульта должен иметь возможность ремонтировать ядро?
SGX предназначен в первую очередь не для настольных ПК, а в тех местах, где данные могут быть скомпроментированы.
Я не сотрудник Интел, но использовал SGX в своей практике много раз. Считаю — отличное решение для многих бизнес задач.
powerman
18.12.2019 12:57А можно конкретные примеры этих "многих бизнес задач"?
А насчёт "не для настольных ПК" — так что тогда эта фича делает в настольных линейках процессоров? Как по мне, версия с DRM звучит довольно логично.
Am0ralist
18.12.2019 13:10Тем, что разделение на настольные и серверные — условно?
powerman
18.12.2019 13:38И что с того? Оно ведь на практике есть, часть фич есть только в серверных процах. Так что вопрос почему данная фича есть не только в серверных вполне уместен.
Am0ralist
18.12.2019 13:57Потому что часть пользовательских процессоров используется в серверах с ECC в реальности? Ну там, где даже те же виртуалки могут крутиться и прочие серверные выполняться задачи?
Не говоря уже о том, что фичи возможно есть, просто выключены на самом деле (или как с процами «T», официально ECC, кстати, может и не быть, но работать будут, как и ставиться оем-сборщиками в системы).
Вот, например, сравнение трех процессоров успешно работающих на серверной мамке с одним и тем же набором прочего железа, с анбуферед-ECC планками памяти.
Т.е. деление — чистый маркетинг ради искусственного выделения более дорогих линеек. А вы просите у них усложнить разработку и делать процы по разному.
AgentRX
18.12.2019 14:01+1Потоковая дешифрация и обработка траффика
Кассовые аппараты с генерацией заказа прямо на кассе без необходимости связываться с сервером.
Печать защищённых изображений с расшифровкой прямо на принтере и т.д.
Что касается настольного ПК — от привязываться к компьютеру по ключу проца? Не очень удобно, но тоже годный кейс.
powerman
18.12.2019 20:41Я не до конца понимаю эти кейсы. Речь ведь о том, что владельцу устройства нельзя доверять, верно?
Потоковая дешифрация и обработка траффика
Как конкретно получилось так, что устройство, занимающееся не просто потоковой передачей, а именно обработкой трафика, находится во владении человека, который не должен иметь доступ к результатам обработки?
Кассовые аппараты с генерацией заказа прямо на кассе без необходимости связываться с сервером.
Если этот кассовый аппарат принимает оплату картой, то ему всё-равно связь с сервером нужна. Если же в него человек купюры засовывает, а кассовый аппарат печает некий QR-код дающий возможность получить заказ, то у человека расхаживающего с таким кассовым аппаратом море возможностей его надурить даже если он не может выковырять из него ключ подписывающий заказы (сразу вспоминаются советские уличные телефоны, в которые монетку на верёвочке опускали :)).
Печать защищённых изображений с расшифровкой прямо на принтере и т.д.
Учитывая, что распечатанное изображение владелец принтера может без проблем отсканировать, мы снова упираемся в DRM — владелец изображения хочет контролировать кто, когда, с каким качеством и водяными знаками может его печатать.
привязываться к компьютеру по ключу проца
Есть способы и по-проще. Но история показала, что эти привязки опять же нарушают законы (напр. права пользователей на резервные копии) и создают проблем намного больше, чем решают. Плюс и без этого полно вариантов к чему привязываться в компе, если очень надо.
AgentRX
18.12.2019 12:06Ох, давайте кратко отвечу по пунктам, а то разрастается диалог)))) Хочу сразу сказать, что эти кейсы взяты из реальных заказов.
Как конкретно получилось так, что устройство, занимающееся не просто потоковой передачей, а именно обработкой трафика, находится во владении человека, который не должен иметь доступ к результатам обработки?
Сервер шифрования трафика для клиента с помощью ключа клиента. Чтобы не хранить N копий, хранится одна. Сервер, понятно дело, может быть чей угодно, просто как сервис.
Если этот кассовый аппарат принимает оплату картой, то ему всё-равно связь с сервером нужна.
Можно и без оплаты печатать промо коды. Новогодние, например. Но они будут все подписаны кассой и в дальнейшем отосланы на сервер.
Учитывая, что распечатанное изображение владелец принтера может без проблем отсканировать
Извините, там кейс по сканированию был, я неверно описал. Вы сканируете документ и он сразу уходит защищенным с железа.
Если же развить печать, то кейс с печатью документов защищает от перехвата документов посредине. Например, принтер стоит в Белом Доме и данные передаются по сети.
По домашнему компу не было кейсов, это я вашу мысль развил.
PS. По поводу SGX, подумайте о шикарной связке SGX+PKCS#7 — вот они отлично входят в эти кейсы.powerman
18.12.2019 21:55+1Простите, но я всё ещё не понимаю. Не поймите неправильно, я не издеваюсь, а честно не вижу где в этих кейсах от данной защиты есть хоть какой-то толк, и хочу в этом разобраться.
Сервер шифрования трафика для клиента с помощью ключа клиента.
Если он шифрует трафик, значит трафик на него приходит с одной стороны не шифрованный. И чего ради тогда прятать ключ шифрования от админа этого сервера?
Можно и без оплаты печатать промо коды.
И зачем в этом случае прятать ключ от имеющего физический доступ к кассовому аппарату, если он и так может напечатать просто нажимая кнопку на аппарате сколько хочет этих кодов?
Вы сканируете документ и он сразу уходит защищенным с железа.
Вот именно. Я сканирую. Т.е. у меня в руках одновременно и сканер и оригинал документа. Смысл от меня же скрывать ключ шифрования?
Если же развить печать, то кейс с печатью документов защищает от перехвата документов посредине.
От MITM отлично помогает обычный https.
AgentRX
19.12.2019 12:59Если он шифрует трафик, значит трафик на него приходит с одной стороны не шифрованный. И чего ради тогда прятать ключ шифрования от админа этого сервера?
Нет, хранится одна шифрованная копия и поточно перешивровывается для пользователя.
И зачем в этом случае прятать ключ от имеющего физический доступ к кассовому аппарату, если он и так может напечатать просто нажимая кнопку на аппарате сколько хочет этих кодов?
Коды могут быть хэшем PKCS#7, которое содержит дополнительную инфу, такую как время, место, идентификационные данные и т.д. Все это можно легко в шифрованном виде хранить и передавать далее.
Отличие от нешифрованного вида в том, что данные защищены по всей цепочке.
Вот именно. Я сканирую. Т.е. у меня в руках одновременно и сканер и оригинал документа. Смысл от меня же скрывать ключ шифрования?
Даю вам подсказку: публичный сканнер, которым пользуется множество людей и который защищает ваши электронные документы, даже если к ним получили доступ злоумышлинники (взяли и похитили сканер с эшем данных).
От MITM отлично помогает обычный https.
Если на вашем компе вредоносное ПО заменит корневые сертификаты, это не поможет. А «ваш комп», например, комп бухгалтерии. SGX более надежный в этом плане.powerman
19.12.2019 15:28Нет, хранится одна шифрованная копия и поточно перешивровывается для пользователя.
Что такое "перешифровывается"? Если с неё шифрование сначала снимается, то админ этого сервера в любом случае может получить доступ к данным в середине этого процесса. Или SGX содержит оба ключа, и у него шифротекст как на входе, так и на выходе, т.е. OS доступа к открытому тексту вообще не имеет ни на каком этапе?
Впрочем, даже в последнем случае, разве OS не может добавить в SGX новый ключ, и запросить перешифрование этим ключом (а дальше зная этот ключ расшифровать не проблема)? Или для внесения любых изменений такого рода в SGX нужно эти изменения подписывать ключом производителя SGX?
Отличие от нешифрованного вида в том, что данные защищены по всей цепочке.
Для защиты по всей цепочке достаточно данные подписать, шифровать их при этом не обязательно.
Ну и всё ещё неясно, каким именно действиям человека, желающего злоупотребить имеющимся у него в руках кассовым аппаратом, помешает наличие в нём SGX. Если он имеет возможность его использовать как угодно, плюс может даже разобрать и подключиться к нему с правами админа, то что в этих условиях он не сможет сделать полезного для себя из-за SGX? (Ключ из SGX он не достанет, но зачем он ему, если он и так может шифровать/подписывать этим ключом всё, что хочет?)
похитили сканер с эшем данных
Кэш — это другая история. Зачем там кеш? Чтобы нажатием одной кнопки повторить отправку документа? Ну так эту кнопку просто нажмут, и напечатают секретный документ повторно. Чтобы защитить данные в таком кеше их надо шифровать не ключом устройства, а паролем юзера, который сканировал документ.
Если на вашем компе вредоносное ПО заменит корневые сертификаты, это не поможет.
От этого придумали certificate pinning.
AgentRX
19.12.2019 15:52админ этого сервера в любом случае может получить доступ к данным в середине этого процесса
Не может. В этом суть SGX анклава.
он и так может шифровать/подписывать этим ключом всё, что хочет?
Только то, что позволит программа, выполняющаяся в анклаве.
От этого придумали certificate pinning.
Теперь расскажите как вы с помощью SSL и certificate pinning защитите каналы между принтерами и пользовательскими машинами, с которых печатают что угодно в корпоративной сети?
welga
17.12.2019 21:31Например, в процессоре Core i3-7100U при понижении напряжения на 118 мВ операция 0x80D36 * 0x21 = 0x109b3f6 даёт предсказуемо сбойное значение 0xffffffffe109b417 на частоте 2 ГГц.
На первый взгляд понижение напряжения должно дать случайный сбой, а здесь сбой четко предсказуемый. Была проделана огромная работа, чтобы это выявить. Для разработчиков дополнительный стимул для устранения этой ошибки.alsoijw
18.12.2019 07:46-1Была проделана огромная работа, чтобы это выявить
Куда интереснее какая работа была чтобы это создать
BubaVV
18.12.2019 14:18А ведь при такой просадке проц должен уходить в reset
S-trace
18.12.2019 15:03Как показывает практика — под полной нагрузкой можно и до -225mV скинуть, и машина продолжит работать как ни в чём ни бывало, без ошибок (mprime мне свидетель)).
А вот если при этом после снижения напряжения и нагрузку скинуть — мгновенно зависнет, да. Похоже, на низких частотах «запас прочности» по питанию существенно меньше, и с андервольтингом на -225mV «на минималках» проц уже не тянет.
firk
Что за глупости.
Ядро ОС (и те кому оно дало доступы к настройке железа) может прочитать память? Всё в порядке.
Не в порядке сама идея прятать пользовательский процесс в памяти от ядра, затея заведомо провальная, даже без этих "уязвимостей". Потому как всю эту чушь можно просто виртуализировать (вплоть до эмуляции нужных узлов проца, отвечающих за эту "защиту") и запустить исследуемое приложение в такой песочнице. Очередное security through obscurity.
AgentRX
Хорошо, вот я производитель процессоров и у меня есть приватный мастер ключ, который шифрует с помощью сессионного приложения во время компиляции.
Сэмулируйте выполнение этого приложения и подпись нужных контейнеров ключами, зашитыми в процессор?
firk
Достаточно один раз отреверсить проц чтобы вытащить из него этот самый ключ и дальше использовать везде. Да, это совсем не дёшево, но суть не меняется — security through obsurity. Ключ просто спрятан в чипе с надеждой что его там никто не сможет подсмотреть.
Причем какой-то реверсинг уже делали, если верить этой статье, значит были близко к правильной нейтрализации этой фигни.
Defersa
Отреверсить чип на 14нм и несколько миллиардов транзисторов — удачи вам, наберете когда получится.
AgentRX
У него не получится, Интел просто выпустит новый дочерний сертификат и обновит процы.
PS. Да, они умеют обновляться)))
firk
Я и не собирался. Но теоретическая возможность имеется. Повторюсь, безопасность, построенная на "они не смогут разобраться в устройстве" называется security through obsurity и это общепризнанно плохой подход.
Какой ещё сертификат? Речь идёт о приватном ключе шифрования. Обновление прошивки, скачиваемое с сайта, тут не поможет — из него точно так же (даже ещё намного проще) вытащат этот приватный ключ (если надо — сэмулируют проц, качающий себе обновление, хотя по-моему до этого ещё не дошли и скачивается оно средствами ОС).
Или они всем покупателям предложат бесплатно заменить чипы на новые? А всем поставщикам зашифрованного софта придётся его перешифровывать и изымать с жёстких дисков клиентов старые версии?
Я вообще не пойму кому пришла в голову идиотская идея что можно доверять железу, полностью находящемуся в руках предполагаемого злоумышленника. Точнее, для производителя то резон понятен: "впарим ка ещё и это, заодно цену повысим". А вот те, кто этому верит — странные.
AgentRX
Учите матчасть!