A small tool to view real-world ActivityPub objects as JSON! Enter a URL
or username from Mastodon or a similar service below, and we'll send a
request with
the right
Accept
header
to the server to view the underlying object.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://idealists.su/schemas/litepub-0.1.jsonld",
{
"@language": "und"
}
],
"actor": "https://idealists.su/users/grumb",
"attachment": [],
"attributedTo": "https://idealists.su/users/grumb",
"cc": [
"https://idealists.su/users/grumb/followers"
],
"content": "<p>У тех же VLIW-процессоров типа «Эльбрус» нет загружаемого микрокода, а потому и неожиданностей гораздо меньше (для эксплуатирующих организаций).</p><p>Вот множество примеров того, что именно прячется в некорректной работе с микрокодом. Это только самые громкие и за последние пару лет.</p><hr/><p>Исследователи безопасности из компании Google опубликовали информацию об уязвимости (CVE-2024-56161) в процессорах AMD, затрагивающей загрузчик микрокода и позволяющей обойти механизм проверки цифровой подписи при обновлении микрокода. Загрузка модифицированного микрокода позволяет скомпрометировать механизм AMD <a class=\"hashtag\" data-tag=\"sev\" href=\"https://idealists.su/tag/sev\">#SEV</a> (Secure Encrypted Virtualization), применяемый в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы.</p><p>Уязвимость вызвана использованием небезопасной хэш-функции в коде, выполняющем проверку цифровой подписи после загрузки микрокода в CPU. Для совершения атаки необходимо наличие прав администратора в локальной системе (возможности выполнить код на уровне нулевого кольца защиты <a class=\"hashtag\" data-tag=\"ring0\" href=\"https://idealists.su/tag/ring0\">#ring0</a>, находясь не в виртуальной машине).</p><p>В ходе атаки можно вклиниться в работу гостевых систем, защищённых при помощи расширений AMD SEV (Secure Encrypted Virtualization) и SEV-SNP (Secure Nested Paging), предоставляющих гарантии целостности памяти виртуальных машин, изолирующих процессорные регистры и обеспечивающих безопасную работу со вложенными таблицами страниц памяти. Механизм AMD SEV создавался для того, чтобы персонал датацентров и облачных провайдеров не мог изменить или проанализировать содержимое памяти защищённых гостевых систем, а также исказить вычисления.</p><p>Исследователями подготовлен прототип эксплоита, позволяющий загрузить в CPU произвольный микрокод, не заверенный цифровой подписью. Для демонстрации опасности уязвимости предложено обновление микрокода, меняющее логику работы инструкции <a class=\"hashtag\" data-tag=\"rdrand\" href=\"https://idealists.su/tag/rdrand\">#RDRAND</a>, применяемой в качестве одного из источников энтропии в генераторах псевдослучайных чисел, используемых в процессе формирования ключей, при выполнении криптографических операций и для генерации случайных идентификаторов.</p><p>Изменение приводит к возвращению инструкцией RDRAND только числа 4, вместо случайной последовательности. Для предотвращения совершения реальных атак на системы конфиденциальных вычислений изменённый микрокод обнуляет флаг CF (carry flag), т.е. помечает выдаваемое значение ошибочным. Дополнительные детали и инструменты для генерации изменённого микрокода планируют опубликовать 5 марта, чтобы дать пользователям время на установку исправления на своих системах. Успешный пример атаки продемонстрирован для серверов с процессорами AMD <a class=\"hashtag\" data-tag=\"epyc\" href=\"https://idealists.su/tag/epyc\">#EPYC</a> 7B13 <a class=\"hashtag\" data-tag=\"milan\" href=\"https://idealists.su/tag/milan\">#Milan</a> и AMD Ryzen 9 7940HS <a class=\"hashtag\" data-tag=\"phoenix\" href=\"https://idealists.su/tag/phoenix\">#Phoenix</a>.</p><p>В отчёте компании AMD указано, что уязвимость проявляется в процессорах AMD на базе 1-4 поколений микроархитектуры Zen. Обновление микрокода с устранением уязвимости было выпущено 13 декабря 2024 года для процессоров серий AMD EPYC 7001, 7002 и 7003 (#Naples, <a class=\"hashtag\" data-tag=\"rome\" href=\"https://idealists.su/tag/rome\">#Rome</a>, <a class=\"hashtag\" data-tag=\"milan\" href=\"https://idealists.su/tag/milan\">#Milan</a> и <a class=\"hashtag\" data-tag=\"milan\" href=\"https://idealists.su/tag/milan\">#Milan</a>-X), а 16 декабря для процессоров серии AMD EPYC 9004 (#Genoa, <a class=\"hashtag\" data-tag=\"genoa\" href=\"https://idealists.su/tag/genoa\">#Genoa</a>-X и <a class=\"hashtag\" data-tag=\"bergamo\" href=\"https://idealists.su/tag/bergamo\">#Bergamo</a>/#Siena). Для устранения уязвимости на системах, в которых используется аттестация <a class=\"hashtag\" data-tag=\"sev\" href=\"https://idealists.su/tag/sev\">#SEV</a>-SNP, дополнительно требуется обновление прошивки AMD SEV (поставляется вместе с обновлениями BIOS от производителей оборудования).</p><hr/><p>Дополнительно сообщается об ещё одной уязвимости в процессорах AMD, допускающей проведение атаки по сторонним каналам для извлечения информации о вычислениях в гостевых системах, защищённых с использованием механизма AMD SEV. Проблема затрагивает 1-4 поколения процессов AMD EPYC и связана с возможностью извлечения из процессорного кэша данных, оседающих в процессе работы защищённых гостевых систем. Для анализа содержимого кэша может использоваться метод Prime+Probe, подразумевающий заполнение кэша эталонным набором значений и определение изменений через измерение времени доступа к ним при повторном заполнении. </p><hr/><p>В <a class=\"hashtag\" data-tag=\"linux\" href=\"https://idealists.su/tag/linux\">#Linux</a> обнаружен механизм обхода защиты от уязвимости <a class=\"hashtag\" data-tag=\"spectre\" href=\"https://idealists.su/tag/spectre\">#Spectre</a> на процессорах <a class=\"hashtag\" data-tag=\"intel\" href=\"https://idealists.su/tag/intel\">#Intel</a> и <a class=\"hashtag\" data-tag=\"amd\" href=\"https://idealists.su/tag/amd\">#AMD</a></p><p>Новой уязвимости подвержены потребительские процессоры Intel Core 12, 13 и 14 поколений, серверные <a class=\"hashtag\" data-tag=\"xeon\" href=\"https://idealists.su/tag/xeon\">#Xeon</a> 5 и 6 поколений, а также чипы AMD <a class=\"hashtag\" data-tag=\"zen\" href=\"https://idealists.su/tag/zen\">#Zen</a> 1, Zen 1+ и Zen 2</p><p>Обнаруженная исследователями Швейцарской высшей технической школы Цюриха (ETH Zurich) схема атаки позволяют обойти защитный механизм <a class=\"hashtag\" data-tag=\"ibpb\" href=\"https://idealists.su/tag/ibpb\">#IBPB</a> (Indirect Branch Predictor Barrier), не позволяющий злоупотреблять спекулятивным выполнением</p><p>Швейцарские учёные подтвердили возможность перехватывать результаты спекулятивного выполнения даже после срабатывания механизма IBPB, то есть с обходом существующих средств защиты и с утечкой конфиденциальной информации — в частности, это может быть извлечённый из процесса suid хэш пароля root</p><p>В случае процессоров Intel механизм IBPB не в полной мере устраняет результат выполнения недействительной функции после смены контекста</p><p>У процессоров AMD метод IBPB-on-entry в ядре <a class=\"hashtag\" data-tag=\"linux\" href=\"https://idealists.su/tag/linux\">#Linux</a> срабатывает неправильно, из-за чего результаты работы устаревших функций не удаляются после <a class=\"hashtag\" data-tag=\"ibpb\" href=\"https://idealists.su/tag/ibpb\">#IBPB</a></p><p>О своём открытии исследователи сообщили <a class=\"hashtag\" data-tag=\"intel\" href=\"https://idealists.su/tag/intel\">#Intel</a> и <a class=\"hashtag\" data-tag=\"amd\" href=\"https://idealists.su/tag/amd\">#AMD</a> в июне 2024 года</p><p>В Intel ответили, что к тому моменту проблема уже была обнаружена силами самой компании — соответствующей уязвимости присвоили номер <a class=\"hashtag\" data-tag=\"cve\" href=\"https://idealists.su/tag/cve\">#CVE</a>-2023-38575</p><p>Ещё в марте Intel выпустила обновление микрокода, но, как установили исследователи, это не помогло исправить ошибку во всех операционных системах, включая Ubuntu</p><p>В AMD также подтвердили факт наличия уязвимости и заявили, что она уже была задокументирована и зарегистрирована под номером CVE-2022-23824</p><p>При этом производитель включил в список уязвимых архитектуру Zen 3, которую швейцарские учёные в своей работе не отметили</p><p>В AMD ошибку охарактеризовали как программную, а не аппаратную; учитывая, что производитель знает о ней давно, и она затрагивает только старые микроархитектуры, в компании приняли решение не выпускать закрывающее уязвимость обновление микрокода</p><p>Таким образом, оба производителя знали о механизме обхода уязвимости, но в документации они отметили его как потенциальный</p><p>Швейцарские учёные, однако, продемонстрировали, что атака срабатывает на Linux 6.5 с защитой IBPB-on-entry, которая считается наиболее эффективной против эксплойтов типа <a class=\"hashtag\" data-tag=\"spectre\" href=\"https://idealists.su/tag/spectre\">#Spectre</a></p><p>И поскольку AMD отказалась закрывать её, исследователи связались с разработчиками ядра Linux с намерением самостоятельно разработать патч для «красных» процессоров</p><hr/><p>Процессоры компании AMD на архитектурах Zen 2 и Zen 3 оказались уязвимы к атаке <a class=\"hashtag\" data-tag=\"faultpm\" href=\"https://idealists.su/tag/faultpm\">#faulTPM</a>, позволяющей взломать их через модуль <a class=\"hashtag\" data-tag=\"tpm\" href=\"https://idealists.su/tag/tpm\">#TPM</a>, пишут порталы Tom’s Hardware и TechSpot. Ирония здесь в том, что <a class=\"hashtag\" data-tag=\"tpm\" href=\"https://idealists.su/tag/tpm\">#TPM</a> сам по себе отвечает за безопасность – это доверенный платформенный модуль.</p><p>Уязвимость процессоров AMD на перечисленных архитектурах нельзя устранить – можно лишь отказаться от их переключиться на решения Intel – ее <a class=\"hashtag\" data-tag=\"cpu\" href=\"https://idealists.su/tag/cpu\">#CPU</a> в неспособности противостоять атаке <a class=\"hashtag\" data-tag=\"faultpm\" href=\"https://idealists.su/tag/faultpm\">#faulTPM</a> пока не уличили.</p><p>Проблему в чипах AMD выявили специалисты по кибербезопасности из Берлинского технического университета. В их отчете говорится о результатах тестирования процессоров <a class=\"hashtag\" data-tag=\"ryzen\" href=\"https://idealists.su/tag/ryzen\">#Ryzen</a> на Zen 2 и Zen 3 – очень востребованных в России и мире. Первое поколение Ryzen с первой же версией архитектуры Zen в документе не упоминается – видимо, эти CPU в тестах не участвовали, так как к маю 2023 г. они давно морально устарели. С момента их выхода прошло шесть лет.</p><p>Вломиться в чип AMD они смогли через встроенный в него сопроцессор безопасности <a class=\"hashtag\" data-tag=\"psp\" href=\"https://idealists.su/tag/psp\">#PSP</a>. Эксперты выудили из него данные, позволяющие расшифровать информацию в модуле ТРМ, а это – прямой путь ко всей информации на компьютере и полным над ним контролем даже при наличии в нем аппаратного модуля безопасности. По сути, из-за уязвимости процессоров AMD к атаке faulTPM хакеры могут скомпрометировать любую программу или шифрование, включая базовое шифрование в Windows – <a class=\"hashtag\" data-tag=\"bitlocker\" href=\"https://idealists.su/tag/bitlocker\">#BitLocker</a>.</p><hr/><p>Линус <a class=\"hashtag\" data-tag=\"торвальдс\" href=\"https://idealists.su/tag/торвальдс\">#Торвальдс</a> заявил, что в сбоящих операционных системах виноваты разработчики «железа», в особенности Intel</p><p>Он считает, что из-за кишащих уязвимостями процессоров Intel разработчикам Linux приходится вносить слишком много правок в ядро, и что именно из-за процессоров в современных ОС так много «дыр»</p><p>Первопричиной всего этого стал негатив Торвальдса в сторону технологии линейной адресной маскировки (Linear Address Masking, <a class=\"hashtag\" data-tag=\"lam\" href=\"https://idealists.su/tag/lam\">#LAM</a>) в процессорах Arrow Lake и Lunar Lake</p><p>За счет нее в CPU могут использоваться нетранслированные биты адреса для хранения метаданных</p><p>Нововведение впервые появилось в процессорах Intel Core 12 поколения, вышедших в конце 2021 г. – оно нужно для повышения безопасности памяти, но при этом, как оказалось, оно мешает быстрой и стабильной работе ядра Linux</p><p>Информация о гневе Торвальдса дошла до Intel, и ее инженер Кирилл Шутемов (Kirill Shitemov) прокомментировал высказывание создателя Linux</p><p>Он сообщил, что технология <a class=\"hashtag\" data-tag=\"lam\" href=\"https://idealists.su/tag/lam\">#LAM</a> действительно имеет свои недочеты, и что они будут устранены с релизом новой технологии – <a class=\"hashtag\" data-tag=\"lass\" href=\"https://idealists.su/tag/lass\">#LASS</a> или Linear Space Separation Support</p><p>Это новая функция безопасности для защиты адресного пространства</p><p>К слову, у AMD есть похожая на LAM технология – Upper Address Ignore <a class=\"hashtag\" data-tag=\"uai\" href=\"https://idealists.su/tag/uai\">#UAI</a></p><p>Она появилась с переходом AMD на процессорную архитектуру Zen 4 и впервые была внедрена в чипы <a class=\"hashtag\" data-tag=\"ryzen\" href=\"https://idealists.su/tag/ryzen\">#Ryzen</a> 7000</p><p><a class=\"hashtag\" data-tag=\"эльбрус\" href=\"https://idealists.su/tag/эльбрус\">#Эльбрус</a> <a class=\"hashtag\" data-tag=\"vliw\" href=\"https://idealists.su/tag/vliw\">#VLIW</a> <a class=\"hashtag\" data-tag=\"cybersec\" href=\"https://idealists.su/tag/cybersec\">#cybersec</a> <a class=\"hashtag\" data-tag=\"infosec\" href=\"https://idealists.su/tag/infosec\">#infosec</a> <a class=\"hashtag\" data-tag=\"иб\" href=\"https://idealists.su/tag/иб\">#ИБ</a> <a class=\"hashtag\" data-tag=\"microcode\" href=\"https://idealists.su/tag/microcode\">#microcode</a></p>",
"contentMap": {
"ru": "<p>У тех же VLIW-процессоров типа «Эльбрус» нет загружаемого микрокода, а потому и неожиданностей гораздо меньше (для эксплуатирующих организаций).</p><p>Вот множество примеров того, что именно прячется в некорректной работе с микрокодом. Это только самые громкие и за последние пару лет.</p><hr/><p>Исследователи безопасности из компании Google опубликовали информацию об уязвимости (CVE-2024-56161) в процессорах AMD, затрагивающей загрузчик микрокода и позволяющей обойти механизм проверки цифровой подписи при обновлении микрокода. Загрузка модифицированного микрокода позволяет скомпрометировать механизм AMD <a class=\"hashtag\" data-tag=\"sev\" href=\"https://idealists.su/tag/sev\">#SEV</a> (Secure Encrypted Virtualization), применяемый в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы.</p><p>Уязвимость вызвана использованием небезопасной хэш-функции в коде, выполняющем проверку цифровой подписи после загрузки микрокода в CPU. Для совершения атаки необходимо наличие прав администратора в локальной системе (возможности выполнить код на уровне нулевого кольца защиты <a class=\"hashtag\" data-tag=\"ring0\" href=\"https://idealists.su/tag/ring0\">#ring0</a>, находясь не в виртуальной машине).</p><p>В ходе атаки можно вклиниться в работу гостевых систем, защищённых при помощи расширений AMD SEV (Secure Encrypted Virtualization) и SEV-SNP (Secure Nested Paging), предоставляющих гарантии целостности памяти виртуальных машин, изолирующих процессорные регистры и обеспечивающих безопасную работу со вложенными таблицами страниц памяти. Механизм AMD SEV создавался для того, чтобы персонал датацентров и облачных провайдеров не мог изменить или проанализировать содержимое памяти защищённых гостевых систем, а также исказить вычисления.</p><p>Исследователями подготовлен прототип эксплоита, позволяющий загрузить в CPU произвольный микрокод, не заверенный цифровой подписью. Для демонстрации опасности уязвимости предложено обновление микрокода, меняющее логику работы инструкции <a class=\"hashtag\" data-tag=\"rdrand\" href=\"https://idealists.su/tag/rdrand\">#RDRAND</a>, применяемой в качестве одного из источников энтропии в генераторах псевдослучайных чисел, используемых в процессе формирования ключей, при выполнении криптографических операций и для генерации случайных идентификаторов.</p><p>Изменение приводит к возвращению инструкцией RDRAND только числа 4, вместо случайной последовательности. Для предотвращения совершения реальных атак на системы конфиденциальных вычислений изменённый микрокод обнуляет флаг CF (carry flag), т.е. помечает выдаваемое значение ошибочным. Дополнительные детали и инструменты для генерации изменённого микрокода планируют опубликовать 5 марта, чтобы дать пользователям время на установку исправления на своих системах. Успешный пример атаки продемонстрирован для серверов с процессорами AMD <a class=\"hashtag\" data-tag=\"epyc\" href=\"https://idealists.su/tag/epyc\">#EPYC</a> 7B13 <a class=\"hashtag\" data-tag=\"milan\" href=\"https://idealists.su/tag/milan\">#Milan</a> и AMD Ryzen 9 7940HS <a class=\"hashtag\" data-tag=\"phoenix\" href=\"https://idealists.su/tag/phoenix\">#Phoenix</a>.</p><p>В отчёте компании AMD указано, что уязвимость проявляется в процессорах AMD на базе 1-4 поколений микроархитектуры Zen. Обновление микрокода с устранением уязвимости было выпущено 13 декабря 2024 года для процессоров серий AMD EPYC 7001, 7002 и 7003 (#Naples, <a class=\"hashtag\" data-tag=\"rome\" href=\"https://idealists.su/tag/rome\">#Rome</a>, <a class=\"hashtag\" data-tag=\"milan\" href=\"https://idealists.su/tag/milan\">#Milan</a> и <a class=\"hashtag\" data-tag=\"milan\" href=\"https://idealists.su/tag/milan\">#Milan</a>-X), а 16 декабря для процессоров серии AMD EPYC 9004 (#Genoa, <a class=\"hashtag\" data-tag=\"genoa\" href=\"https://idealists.su/tag/genoa\">#Genoa</a>-X и <a class=\"hashtag\" data-tag=\"bergamo\" href=\"https://idealists.su/tag/bergamo\">#Bergamo</a>/#Siena). Для устранения уязвимости на системах, в которых используется аттестация <a class=\"hashtag\" data-tag=\"sev\" href=\"https://idealists.su/tag/sev\">#SEV</a>-SNP, дополнительно требуется обновление прошивки AMD SEV (поставляется вместе с обновлениями BIOS от производителей оборудования).</p><hr/><p>Дополнительно сообщается об ещё одной уязвимости в процессорах AMD, допускающей проведение атаки по сторонним каналам для извлечения информации о вычислениях в гостевых системах, защищённых с использованием механизма AMD SEV. Проблема затрагивает 1-4 поколения процессов AMD EPYC и связана с возможностью извлечения из процессорного кэша данных, оседающих в процессе работы защищённых гостевых систем. Для анализа содержимого кэша может использоваться метод Prime+Probe, подразумевающий заполнение кэша эталонным набором значений и определение изменений через измерение времени доступа к ним при повторном заполнении. </p><hr/><p>В <a class=\"hashtag\" data-tag=\"linux\" href=\"https://idealists.su/tag/linux\">#Linux</a> обнаружен механизм обхода защиты от уязвимости <a class=\"hashtag\" data-tag=\"spectre\" href=\"https://idealists.su/tag/spectre\">#Spectre</a> на процессорах <a class=\"hashtag\" data-tag=\"intel\" href=\"https://idealists.su/tag/intel\">#Intel</a> и <a class=\"hashtag\" data-tag=\"amd\" href=\"https://idealists.su/tag/amd\">#AMD</a></p><p>Новой уязвимости подвержены потребительские процессоры Intel Core 12, 13 и 14 поколений, серверные <a class=\"hashtag\" data-tag=\"xeon\" href=\"https://idealists.su/tag/xeon\">#Xeon</a> 5 и 6 поколений, а также чипы AMD <a class=\"hashtag\" data-tag=\"zen\" href=\"https://idealists.su/tag/zen\">#Zen</a> 1, Zen 1+ и Zen 2</p><p>Обнаруженная исследователями Швейцарской высшей технической школы Цюриха (ETH Zurich) схема атаки позволяют обойти защитный механизм <a class=\"hashtag\" data-tag=\"ibpb\" href=\"https://idealists.su/tag/ibpb\">#IBPB</a> (Indirect Branch Predictor Barrier), не позволяющий злоупотреблять спекулятивным выполнением</p><p>Швейцарские учёные подтвердили возможность перехватывать результаты спекулятивного выполнения даже после срабатывания механизма IBPB, то есть с обходом существующих средств защиты и с утечкой конфиденциальной информации — в частности, это может быть извлечённый из процесса suid хэш пароля root</p><p>В случае процессоров Intel механизм IBPB не в полной мере устраняет результат выполнения недействительной функции после смены контекста</p><p>У процессоров AMD метод IBPB-on-entry в ядре <a class=\"hashtag\" data-tag=\"linux\" href=\"https://idealists.su/tag/linux\">#Linux</a> срабатывает неправильно, из-за чего результаты работы устаревших функций не удаляются после <a class=\"hashtag\" data-tag=\"ibpb\" href=\"https://idealists.su/tag/ibpb\">#IBPB</a></p><p>О своём открытии исследователи сообщили <a class=\"hashtag\" data-tag=\"intel\" href=\"https://idealists.su/tag/intel\">#Intel</a> и <a class=\"hashtag\" data-tag=\"amd\" href=\"https://idealists.su/tag/amd\">#AMD</a> в июне 2024 года</p><p>В Intel ответили, что к тому моменту проблема уже была обнаружена силами самой компании — соответствующей уязвимости присвоили номер <a class=\"hashtag\" data-tag=\"cve\" href=\"https://idealists.su/tag/cve\">#CVE</a>-2023-38575</p><p>Ещё в марте Intel выпустила обновление микрокода, но, как установили исследователи, это не помогло исправить ошибку во всех операционных системах, включая Ubuntu</p><p>В AMD также подтвердили факт наличия уязвимости и заявили, что она уже была задокументирована и зарегистрирована под номером CVE-2022-23824</p><p>При этом производитель включил в список уязвимых архитектуру Zen 3, которую швейцарские учёные в своей работе не отметили</p><p>В AMD ошибку охарактеризовали как программную, а не аппаратную; учитывая, что производитель знает о ней давно, и она затрагивает только старые микроархитектуры, в компании приняли решение не выпускать закрывающее уязвимость обновление микрокода</p><p>Таким образом, оба производителя знали о механизме обхода уязвимости, но в документации они отметили его как потенциальный</p><p>Швейцарские учёные, однако, продемонстрировали, что атака срабатывает на Linux 6.5 с защитой IBPB-on-entry, которая считается наиболее эффективной против эксплойтов типа <a class=\"hashtag\" data-tag=\"spectre\" href=\"https://idealists.su/tag/spectre\">#Spectre</a></p><p>И поскольку AMD отказалась закрывать её, исследователи связались с разработчиками ядра Linux с намерением самостоятельно разработать патч для «красных» процессоров</p><hr/><p>Процессоры компании AMD на архитектурах Zen 2 и Zen 3 оказались уязвимы к атаке <a class=\"hashtag\" data-tag=\"faultpm\" href=\"https://idealists.su/tag/faultpm\">#faulTPM</a>, позволяющей взломать их через модуль <a class=\"hashtag\" data-tag=\"tpm\" href=\"https://idealists.su/tag/tpm\">#TPM</a>, пишут порталы Tom’s Hardware и TechSpot. Ирония здесь в том, что <a class=\"hashtag\" data-tag=\"tpm\" href=\"https://idealists.su/tag/tpm\">#TPM</a> сам по себе отвечает за безопасность – это доверенный платформенный модуль.</p><p>Уязвимость процессоров AMD на перечисленных архитектурах нельзя устранить – можно лишь отказаться от их переключиться на решения Intel – ее <a class=\"hashtag\" data-tag=\"cpu\" href=\"https://idealists.su/tag/cpu\">#CPU</a> в неспособности противостоять атаке <a class=\"hashtag\" data-tag=\"faultpm\" href=\"https://idealists.su/tag/faultpm\">#faulTPM</a> пока не уличили.</p><p>Проблему в чипах AMD выявили специалисты по кибербезопасности из Берлинского технического университета. В их отчете говорится о результатах тестирования процессоров <a class=\"hashtag\" data-tag=\"ryzen\" href=\"https://idealists.su/tag/ryzen\">#Ryzen</a> на Zen 2 и Zen 3 – очень востребованных в России и мире. Первое поколение Ryzen с первой же версией архитектуры Zen в документе не упоминается – видимо, эти CPU в тестах не участвовали, так как к маю 2023 г. они давно морально устарели. С момента их выхода прошло шесть лет.</p><p>Вломиться в чип AMD они смогли через встроенный в него сопроцессор безопасности <a class=\"hashtag\" data-tag=\"psp\" href=\"https://idealists.su/tag/psp\">#PSP</a>. Эксперты выудили из него данные, позволяющие расшифровать информацию в модуле ТРМ, а это – прямой путь ко всей информации на компьютере и полным над ним контролем даже при наличии в нем аппаратного модуля безопасности. По сути, из-за уязвимости процессоров AMD к атаке faulTPM хакеры могут скомпрометировать любую программу или шифрование, включая базовое шифрование в Windows – <a class=\"hashtag\" data-tag=\"bitlocker\" href=\"https://idealists.su/tag/bitlocker\">#BitLocker</a>.</p><hr/><p>Линус <a class=\"hashtag\" data-tag=\"торвальдс\" href=\"https://idealists.su/tag/торвальдс\">#Торвальдс</a> заявил, что в сбоящих операционных системах виноваты разработчики «железа», в особенности Intel</p><p>Он считает, что из-за кишащих уязвимостями процессоров Intel разработчикам Linux приходится вносить слишком много правок в ядро, и что именно из-за процессоров в современных ОС так много «дыр»</p><p>Первопричиной всего этого стал негатив Торвальдса в сторону технологии линейной адресной маскировки (Linear Address Masking, <a class=\"hashtag\" data-tag=\"lam\" href=\"https://idealists.su/tag/lam\">#LAM</a>) в процессорах Arrow Lake и Lunar Lake</p><p>За счет нее в CPU могут использоваться нетранслированные биты адреса для хранения метаданных</p><p>Нововведение впервые появилось в процессорах Intel Core 12 поколения, вышедших в конце 2021 г. – оно нужно для повышения безопасности памяти, но при этом, как оказалось, оно мешает быстрой и стабильной работе ядра Linux</p><p>Информация о гневе Торвальдса дошла до Intel, и ее инженер Кирилл Шутемов (Kirill Shitemov) прокомментировал высказывание создателя Linux</p><p>Он сообщил, что технология <a class=\"hashtag\" data-tag=\"lam\" href=\"https://idealists.su/tag/lam\">#LAM</a> действительно имеет свои недочеты, и что они будут устранены с релизом новой технологии – <a class=\"hashtag\" data-tag=\"lass\" href=\"https://idealists.su/tag/lass\">#LASS</a> или Linear Space Separation Support</p><p>Это новая функция безопасности для защиты адресного пространства</p><p>К слову, у AMD есть похожая на LAM технология – Upper Address Ignore <a class=\"hashtag\" data-tag=\"uai\" href=\"https://idealists.su/tag/uai\">#UAI</a></p><p>Она появилась с переходом AMD на процессорную архитектуру Zen 4 и впервые была внедрена в чипы <a class=\"hashtag\" data-tag=\"ryzen\" href=\"https://idealists.su/tag/ryzen\">#Ryzen</a> 7000</p><p><a class=\"hashtag\" data-tag=\"эльбрус\" href=\"https://idealists.su/tag/эльбрус\">#Эльбрус</a> <a class=\"hashtag\" data-tag=\"vliw\" href=\"https://idealists.su/tag/vliw\">#VLIW</a> <a class=\"hashtag\" data-tag=\"cybersec\" href=\"https://idealists.su/tag/cybersec\">#cybersec</a> <a class=\"hashtag\" data-tag=\"infosec\" href=\"https://idealists.su/tag/infosec\">#infosec</a> <a class=\"hashtag\" data-tag=\"иб\" href=\"https://idealists.su/tag/иб\">#ИБ</a> <a class=\"hashtag\" data-tag=\"microcode\" href=\"https://idealists.su/tag/microcode\">#microcode</a></p>"
},
"context": "https://idealists.su/contexts/9edc537c-fbb0-453b-be27-4af28ae4bdca",
"conversation": "https://idealists.su/contexts/9edc537c-fbb0-453b-be27-4af28ae4bdca",
"id": "https://idealists.su/objects/e3a19000-c1a7-427e-9163-c77eec5decfa",
"published": "2025-02-07T16:06:58.475269Z",
"repliesCount": 1,
"sensitive": true,
"source": {
"content": "У тех же VLIW-процессоров типа «Эльбрус» нет загружаемого микрокода, а потому и неожиданностей гораздо меньше (для эксплуатирующих организаций).\r\n\r\nВот множество примеров того, что именно прячется в некорректной работе с микрокодом. Это только самые громкие и за последние пару лет.\r\n\r\n---\r\nИсследователи безопасности из компании Google опубликовали информацию об уязвимости (CVE-2024-56161) в процессорах AMD, затрагивающей загрузчик микрокода и позволяющей обойти механизм проверки цифровой подписи при обновлении микрокода. Загрузка модифицированного микрокода позволяет скомпрометировать механизм AMD #SEV (Secure Encrypted Virtualization), применяемый в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы.\r\n\r\nУязвимость вызвана использованием небезопасной хэш-функции в коде, выполняющем проверку цифровой подписи после загрузки микрокода в CPU. Для совершения атаки необходимо наличие прав администратора в локальной системе (возможности выполнить код на уровне нулевого кольца защиты #ring0, находясь не в виртуальной машине).\r\n\r\nВ ходе атаки можно вклиниться в работу гостевых систем, защищённых при помощи расширений AMD SEV (Secure Encrypted Virtualization) и SEV-SNP (Secure Nested Paging), предоставляющих гарантии целостности памяти виртуальных машин, изолирующих процессорные регистры и обеспечивающих безопасную работу со вложенными таблицами страниц памяти. Механизм AMD SEV создавался для того, чтобы персонал датацентров и облачных провайдеров не мог изменить или проанализировать содержимое памяти защищённых гостевых систем, а также исказить вычисления.\r\n\r\nИсследователями подготовлен прототип эксплоита, позволяющий загрузить в CPU произвольный микрокод, не заверенный цифровой подписью. Для демонстрации опасности уязвимости предложено обновление микрокода, меняющее логику работы инструкции #RDRAND, применяемой в качестве одного из источников энтропии в генераторах псевдослучайных чисел, используемых в процессе формирования ключей, при выполнении криптографических операций и для генерации случайных идентификаторов.\r\n\r\nИзменение приводит к возвращению инструкцией RDRAND только числа 4, вместо случайной последовательности. Для предотвращения совершения реальных атак на системы конфиденциальных вычислений изменённый микрокод обнуляет флаг CF (carry flag), т.е. помечает выдаваемое значение ошибочным. Дополнительные детали и инструменты для генерации изменённого микрокода планируют опубликовать 5 марта, чтобы дать пользователям время на установку исправления на своих системах. Успешный пример атаки продемонстрирован для серверов с процессорами AMD #EPYC 7B13 #Milan и AMD Ryzen 9 7940HS #Phoenix.\r\n\r\nВ отчёте компании AMD указано, что уязвимость проявляется в процессорах AMD на базе 1-4 поколений микроархитектуры Zen. Обновление микрокода с устранением уязвимости было выпущено 13 декабря 2024 года для процессоров серий AMD EPYC 7001, 7002 и 7003 (#Naples, #Rome, #Milan и #Milan-X), а 16 декабря для процессоров серии AMD EPYC 9004 (#Genoa, #Genoa-X и #Bergamo/#Siena). Для устранения уязвимости на системах, в которых используется аттестация #SEV-SNP, дополнительно требуется обновление прошивки AMD SEV (поставляется вместе с обновлениями BIOS от производителей оборудования).\r\n\r\n---\r\nДополнительно сообщается об ещё одной уязвимости в процессорах AMD, допускающей проведение атаки по сторонним каналам для извлечения информации о вычислениях в гостевых системах, защищённых с использованием механизма AMD SEV. Проблема затрагивает 1-4 поколения процессов AMD EPYC и связана с возможностью извлечения из процессорного кэша данных, оседающих в процессе работы защищённых гостевых систем. Для анализа содержимого кэша может использоваться метод Prime+Probe, подразумевающий заполнение кэша эталонным набором значений и определение изменений через измерение времени доступа к ним при повторном заполнении. \r\n\r\n---\r\nВ #Linux обнаружен механизм обхода защиты от уязвимости #Spectre на процессорах #Intel и #AMD\r\n\r\nНовой уязвимости подвержены потребительские процессоры Intel Core 12, 13 и 14 поколений, серверные #Xeon 5 и 6 поколений, а также чипы AMD #Zen 1, Zen 1+ и Zen 2\r\n\r\nОбнаруженная исследователями Швейцарской высшей технической школы Цюриха (ETH Zurich) схема атаки позволяют обойти защитный механизм #IBPB (Indirect Branch Predictor Barrier), не позволяющий злоупотреблять спекулятивным выполнением\r\n\r\nШвейцарские учёные подтвердили возможность перехватывать результаты спекулятивного выполнения даже после срабатывания механизма IBPB, то есть с обходом существующих средств защиты и с утечкой конфиденциальной информации — в частности, это может быть извлечённый из процесса suid хэш пароля root\r\n\r\nВ случае процессоров Intel механизм IBPB не в полной мере устраняет результат выполнения недействительной функции после смены контекста\r\n\r\nУ процессоров AMD метод IBPB-on-entry в ядре #Linux срабатывает неправильно, из-за чего результаты работы устаревших функций не удаляются после #IBPB\r\n\r\nО своём открытии исследователи сообщили #Intel и #AMD в июне 2024 года\r\n\r\nВ Intel ответили, что к тому моменту проблема уже была обнаружена силами самой компании — соответствующей уязвимости присвоили номер #CVE-2023-38575\r\n\r\nЕщё в марте Intel выпустила обновление микрокода, но, как установили исследователи, это не помогло исправить ошибку во всех операционных системах, включая Ubuntu\r\n\r\nВ AMD также подтвердили факт наличия уязвимости и заявили, что она уже была задокументирована и зарегистрирована под номером CVE-2022-23824\r\n\r\nПри этом производитель включил в список уязвимых архитектуру Zen 3, которую швейцарские учёные в своей работе не отметили\r\n\r\nВ AMD ошибку охарактеризовали как программную, а не аппаратную; учитывая, что производитель знает о ней давно, и она затрагивает только старые микроархитектуры, в компании приняли решение не выпускать закрывающее уязвимость обновление микрокода\r\n\r\nТаким образом, оба производителя знали о механизме обхода уязвимости, но в документации они отметили его как потенциальный\r\n\r\nШвейцарские учёные, однако, продемонстрировали, что атака срабатывает на Linux 6.5 с защитой IBPB-on-entry, которая считается наиболее эффективной против эксплойтов типа #Spectre\r\n\r\nИ поскольку AMD отказалась закрывать её, исследователи связались с разработчиками ядра Linux с намерением самостоятельно разработать патч для «красных» процессоров\r\n\r\n---\r\n\r\nПроцессоры компании AMD на архитектурах Zen 2 и Zen 3 оказались уязвимы к атаке #faulTPM, позволяющей взломать их через модуль #TPM, пишут порталы Tom’s Hardware и TechSpot. Ирония здесь в том, что #TPM сам по себе отвечает за безопасность – это доверенный платформенный модуль.\r\n\r\nУязвимость процессоров AMD на перечисленных архитектурах нельзя устранить – можно лишь отказаться от их переключиться на решения Intel – ее #CPU в неспособности противостоять атаке #faulTPM пока не уличили.\r\n\r\nПроблему в чипах AMD выявили специалисты по кибербезопасности из Берлинского технического университета. В их отчете говорится о результатах тестирования процессоров #Ryzen на Zen 2 и Zen 3 – очень востребованных в России и мире. Первое поколение Ryzen с первой же версией архитектуры Zen в документе не упоминается – видимо, эти CPU в тестах не участвовали, так как к маю 2023 г. они давно морально устарели. С момента их выхода прошло шесть лет.\r\n\r\nВломиться в чип AMD они смогли через встроенный в него сопроцессор безопасности #PSP. Эксперты выудили из него данные, позволяющие расшифровать информацию в модуле ТРМ, а это – прямой путь ко всей информации на компьютере и полным над ним контролем даже при наличии в нем аппаратного модуля безопасности. По сути, из-за уязвимости процессоров AMD к атаке faulTPM хакеры могут скомпрометировать любую программу или шифрование, включая базовое шифрование в Windows – #BitLocker.\r\n\r\n---\r\nЛинус #Торвальдс заявил, что в сбоящих операционных системах виноваты разработчики «железа», в особенности Intel\r\n\r\nОн считает, что из-за кишащих уязвимостями процессоров Intel разработчикам Linux приходится вносить слишком много правок в ядро, и что именно из-за процессоров в современных ОС так много «дыр»\r\n\r\nПервопричиной всего этого стал негатив Торвальдса в сторону технологии линейной адресной маскировки (Linear Address Masking, #LAM) в процессорах Arrow Lake и Lunar Lake\r\n\r\nЗа счет нее в CPU могут использоваться нетранслированные биты адреса для хранения метаданных\r\n\r\nНововведение впервые появилось в процессорах Intel Core 12 поколения, вышедших в конце 2021 г. – оно нужно для повышения безопасности памяти, но при этом, как оказалось, оно мешает быстрой и стабильной работе ядра Linux\r\n\r\nИнформация о гневе Торвальдса дошла до Intel, и ее инженер Кирилл Шутемов (Kirill Shitemov) прокомментировал высказывание создателя Linux\r\n\r\nОн сообщил, что технология #LAM действительно имеет свои недочеты, и что они будут устранены с релизом новой технологии – #LASS или Linear Space Separation Support\r\n\r\nЭто новая функция безопасности для защиты адресного пространства\r\n\r\nК слову, у AMD есть похожая на LAM технология – Upper Address Ignore #UAI\r\n\r\nОна появилась с переходом AMD на процессорную архитектуру Zen 4 и впервые была внедрена в чипы #Ryzen 7000\r\n\r\n#Эльбрус #VLIW #cybersec #infosec #ИБ #microcode",
"mediaType": "text/markdown"
},
"summary": "Зачем нам свои процессоры",
"tag": [
{
"href": "https://idealists.su/tags/zen",
"name": "#zen",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/xeon",
"name": "#xeon",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/cve",
"name": "#cve",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/microcode",
"name": "#microcode",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/иб",
"name": "#иб",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/genoa",
"name": "#genoa",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/cpu",
"name": "#cpu",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/ibpb",
"name": "#ibpb",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/intel",
"name": "#intel",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/lam",
"name": "#lam",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/rdrand",
"name": "#rdrand",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/tpm",
"name": "#tpm",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/linux",
"name": "#linux",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/milan",
"name": "#milan",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/amd",
"name": "#amd",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/sev",
"name": "#sev",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/psp",
"name": "#psp",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/vliw",
"name": "#vliw",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/uai",
"name": "#uai",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/торвальдс",
"name": "#торвальдс",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/epyc",
"name": "#epyc",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/bergamo",
"name": "#bergamo",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/ring0",
"name": "#ring0",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/lass",
"name": "#lass",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/bitlocker",
"name": "#bitlocker",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/эльбрус",
"name": "#эльбрус",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/cybersec",
"name": "#cybersec",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/faultpm",
"name": "#faultpm",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/rome",
"name": "#rome",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/ryzen",
"name": "#ryzen",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/spectre",
"name": "#spectre",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/infosec",
"name": "#infosec",
"type": "Hashtag"
},
{
"href": "https://idealists.su/tags/phoenix",
"name": "#phoenix",
"type": "Hashtag"
}
],
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"type": "Note"
}