eXeLab
eXeL@B ВИДЕОКУРС !

ВИДЕОКУРС
выпущен 4 ноября!


УЗНАТЬ БОЛЬШЕ >>
Домой | Статьи | RAR-cтатьи | FAQ | Форум | Скачать | Видеокурс
Новичку | Ссылки | Программирование | Интервью | Архив | Связь

Русский / Russian English / Английский

Сейчас на форуме: rmn (+4 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS · SVN ·

 eXeL@B —› Оффтоп —› Meltdown и Spectre - названия двух атак на процессоры Intel/AMD/ARM64
<< . 1 . 2 . 3 . >>
Посл.ответ Сообщение


Ранг: 1120.2 (!!!!)
Статус: Участник

Создано: 4 января 2018 11:13 New!
Цитата · Личное сообщение · #1

Коллеги, а вот реализация уязвимости через JavaScript - это не то, за упоминание о чем в своё время высмеивали Криса?

Ранг: 136.6 (ветеран)
Статус: Участник

Создано: 6 января 2018 12:44 · Поправил: Alchemistry New!
Цитата · Личное сообщение · #2

difexacaw Я рад, что ты знаешь как это работает, молодец.



Есчо если кто хочет потестить, эти релоады тлб кэша должны дать доп нагрузку и проц слегка подогреется выше нормы. Потестить можно уже сейчас, нужна вин 10, с последним кумулятивным апдейтом.

Ранг: 0.0 (гость)
Статус: Участник

Создано: 6 января 2018 17:33 New!
Цитата · Личное сообщение · #3

Kindly пишет: Хомячкам, монтажерам и игроманам нет повода для беспокойства о критичной потере производительности.

Как и большинству простых смертных из за сложности реализации атаки, а корпоративному сектору да, есть повод для того, чтобы откладывать кирпичи.


Ранг: 655.4 (! !)
Статус: Участник
CyberMonk

Создано: 6 января 2018 17:51 New!
Цитата · Личное сообщение · #4

SpecuCheck --> Link <--

SpecuCheck is a Windows utility for checking the state of the software mitigations against CVE-2017-5754 (Meltdown) and hardware mitigations against CVE-2017-5715 (Spectre). It uses two new information classes that were added to the NtQuerySystemInformation API call as part of the recent patches introduced in January 2018 and reports the data as seen by the Windows Kernel.

An official Microsoft Powershell Cmdlet Module now exists as well, which is the recommended and supported way to get this information. --> Link <--

How to Check and Update Windows Systems for the Meltdown and Spectre CPU Flaws --> Link <--


Ранг: 1120.2 (!!!!)
Статус: Участник

Создано: 7 января 2018 01:52 · Поправил: Gideon Vi New!
Цитата · Личное сообщение · #5

*удалил


Ранг: 263.7 (наставник)
Статус: Участник
RBC

Создано: 7 января 2018 11:11 · Поправил: Kindly New!
Цитата · Личное сообщение · #6

вобщем, проблема не решается только фиксом ME драйвера, обновления подоспели для других систем еще 4 января:

7
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056897
8
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056898

а вообще, юзерам семерки надо ставить кумулятивный апдейт KB4056894, в который включен апдейт KB4056897:
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056894

счас поставим и посмотрим на попугаи...

небольшой тест CPU и также запускал факторизацию по всем ядрам и потокам 290 bit числа - результаты на уровне погрешностей, т.е. одинаковые, что до патча ядра, что после. может на процессорах с другой архитектурой или профессиональных задачах будут видимые просадки, но лично у меня разницы нет.


Ранг: 1993.2 (!!!!)
Статус: Модератор
retired

Создано: 7 января 2018 12:48 New!
Цитата · Личное сообщение · #7

Дык просадка должна быть при вызове ядра, типа при частых вызовах апи. Если оно чисто в юзермоде кряхтит в цикле, чего ему просаживаться-то.


Ранг: 316.1 (мудрец)
Статус: Участник

Создано: 7 января 2018 17:20 New!
Цитата · Личное сообщение · #8

Archer

Довольно редко переключается ап, по этой причине не использована аппаратная фича(tss). Это делает планировщик, он переключает базу трансляции. При этом сбрасываются все кэши, очереди и прочие механизмы. В данном же случае переключать ап нужно на каждом сервисе. Думаю вы понимаете что это не хорошо, точнее полный ппз.

Выше упомянули AMT, быть может на этом уровне может быть фикс, но нужно помнить что это всё глубокий андок и вендор не заинтересован в фиксах.

Ранг: 42.5 (посетитель)
Статус: Участник

Создано: 7 января 2018 22:23 New!
Цитата · Личное сообщение · #9

смена контекста не спасает

Ранг: 136.6 (ветеран)
Статус: Участник

Создано: 8 января 2018 09:30 · Поправил: Alchemistry New!
Цитата · Личное сообщение · #10

Не знаю че вы там меряете синтетикой и зачем, разве что от непонимания сути проблемы и её фикса. Я померял время сисколов в венде до и после KB4056892 составив множественные выборки на 2х конфигурациях xeon v2e5-2630 и i7 6700. Разница до и после впечатляющая, там разы просто. Разумеется это все еще недостаточно чтобы в аппаратно ускоренном интерфейсе венды вы заметили дроп "на глаз" но факт уменьшения производительности от этого никуда не денется. Вообще phoronix уже давно все потестил, вендузятники отдельно и на широком спектре ПО - не имею понятия, по-моему на венде если игори не тормозят больше обычного и авер не бсодит остальное не ипет широкую публику.


Ранг: 316.1 (мудрец)
Статус: Участник

Создано: 8 января 2018 17:35 New!
Цитата · Личное сообщение · #11

Alchemistry

Если у вас есть фикс, покажите плз как он реализован, дизасм сервисной обработки, это пока найти в сети не удаётся.

Ранг: 238.9 (наставник)
Статус: Участник

Создано: 9 января 2018 12:14 · Поправил: cppasm New!
Цитата · Личное сообщение · #12

difexacaw пишет:
Если у вас есть фикс, покажите плз как он реализован, дизасм сервисной обработки, это пока найти в сети не удаётся.

Как он реализован написано на каждом заборе, для этого ничего дизасмить не надо.
При возврате из ядра в юзермод каждый раз анмапится вся ядерная память.
Поэтому использование этой уязвимости не позволяет ничего прочитать из памяти ядра - т.к. если мы в юзермоде то читать уже просто нечего.
Соответственно при любом сисколе вначале всё мапится назад, потом уже отрабатывает сискол и анмапит всё снова.
Из-за этого и просадки при вызове ядра.

А так по-моему куча сказок вокруг этих уязвимостей.
Реализация на JavaScript?
Она как минимум будет крайне нестабильна, т.к. в js нет возможности вытеснить определённые адреса из кэша.
Без этого алгоритм будет вероятностным и вероятность далеко не 100%.
С учётом того что данные получаются по 1 биту - в итоге вместо данных там будет полная фигня.
Второй вопрос - прочитав всё тех описание уязвимостей я так и не понял как они позволяют получить данные из адресного пространства другого процесса.
По-моему никак и это просто раздули ради шумихи.

Ещё не очень понятно чего все поголовно (Windows, Linux, MacOS Х) решили анмапить ядро при возврате в юзермод, если достаточно просто сбросить кеш процессора чтобы эти атаки пошли лесом.
И просадка при этом намного меньше...


Ранг: 44.3 (посетитель)
Статус: Участник

Создано: 10 января 2018 03:21 New!
Цитата · Личное сообщение · #13

https://github.com/IAIK/meltdown/

Ранг: 136.6 (ветеран)
Статус: Участник

Создано: 10 января 2018 06:24 · Поправил: Alchemistry New!
Цитата · Личное сообщение · #14

https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/

Добавлено спустя 1 час 1 минуту
difexacaw
Масса этого нового говнокода находится в новой секции нтос KVASCODE, KiSystemCall64Shadow например. В ней же увидишь код для spectre вариант Branch Target Injection, блоки add rsp/call - переполнение буфера предсказателя. Подобный же код в обработчиках прерываний. Еще деградация производительности.

Там есть глобальные переменные которые включает это KiKvaShadow, KiKvaLeakage, функция KiEnableKvaShadowing итд.

Детект уязвимости осуществляется в KiInitializeBootStructures->KiSetFeatureBits->KiDetectKvaLeakage.
Для инфы в юзермод были запилены новые инфо классы для NtQuerySystemInformation, 196 и 201 (индексы взяты с последней десятки). Они возвращают набор флагов, имена полей можно рипнуть с повершел скрипта SpeculationControl от самой MS.

p.s. это 64 битная десятка 16299.192

| Сообщение посчитали полезным: difexacaw


Ранг: 238.9 (наставник)
Статус: Участник

Создано: 10 января 2018 12:29 New!
Цитата · Личное сообщение · #15

mak же постил выше: https://github.com/ionescu007/SpecuCheck
Там можно посмотреть инфо классы для NtQuerySystemInformation.


Ранг: 106.9 (ветеран)
Статус: Участник

Создано: 11 января 2018 12:22 · Поправил: Oott New!
Цитата · Личное сообщение · #16

cppasm пишет:
А так по-моему куча сказок вокруг этих уязвимостей.
Реализация на JavaScript?

ЯваСкрипт тут выступает в качестве способа создания удобного паттерна через JIT для эксплуатации spectre.

cppasm пишет:
Она как минимум будет крайне нестабильна, т.к. в js нет возможности вытеснить определённые адреса из кэша.
Без этого алгоритм будет вероятностным и вероятность далеко не 100%.

Предполагается что вытеснение кэша будет готовиться снаружи и у нас будет доступ к охлаждаемой памяти. Работать это 100% конечно не будет, но какие-то хорошие проценты можно получить.

cppasm пишет:
С учётом того что данные получаются по 1 биту - в итоге вместо данных там будет полная фигня.

Можно и по байту вычитывать, просто простукивать больше памяти, зависит от реализации.

cppasm пишет:
Второй вопрос - прочитав всё тех описание уязвимостей я так и не понял как они позволяют получить данные из адресного пространства другого процесса.
По-моему никак и это просто раздули ради шумихи.

Через адресное пространоство библиотек, таргет прогревает кэш памяти либы, а затем сплоит простукивает эту память. Или если есть шареный мапинг. В любом случае процессы должны иметь доступ к одной физической памяти. Еще теоретически может существовать кейс, когда с помощью каких-то внешних комманд можно заставить процесс обращаться к прогретой памяти таргета и замерять время доступа, но на практике очень сложно будет добиться здесь хорошей точности замера.

Ранг: 238.9 (наставник)
Статус: Участник

Создано: 11 января 2018 12:47 New!
Цитата · Личное сообщение · #17

Oott пишет:
ЯваСкрипт тут выступает в качестве способа создания удобного паттерна через JIT для эксплуатации spectre.

Без возможности управлять кэшем (вытеснять из него определённые регионы со 100% вероятностью) это всё вероятностные процессы.

Oott пишет:
Можно и по байту вычитывать, просто простукивать больше памяти, зависит от реализации.

По байту нельзя - не взлетит.
В кэше нет 256 линеек чтобы отличить все состояния.
Их обычно 32 или около того.
А так да, по три четыре бита за раз получать можно.

Oott пишет:
Через адресное пространоство библиотек, таргет прогревает кэш памяти либы, а затем сплоит простукивает эту память.

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

Одно дело возможность читать адресное пространство другого процесса по произвольным адресам (чего нет), а другое прочитать фиг знает что из шаред библиотеки и потом гадать что это вообще за данные...

Ранг: 136.6 (ветеран)
Статус: Участник

Создано: 11 января 2018 12:49 New!
Цитата · Личное сообщение · #18

cppasm пишет:
https://github.com/ionescu007/SpecuCheck

Этот балабол и рипнул их из официального повершел скрипта. Дальше были обильно насыпаны черепа и кости в консольке.


Ранг: 106.9 (ветеран)
Статус: Участник

Создано: 11 января 2018 15:14 New!
Цитата · Личное сообщение · #19

cppasm пишет:
Без возможности управлять кэшем (вытеснять из него определённые регионы со 100% вероятностью) это всё вероятностные процессы.


Управлять кэшом можно из своего процесса, т.е. все вермя забивать кэш, это 100% не дает, там так и пишут.

cppasm пишет:
По байту нельзя - не взлетит.
В кэше нет 256 линеек чтобы отличить все состояния.
Их обычно 32 или около того.

Скока?

Ну вот у меня машина с i5-2400, не самый новый проц:
#lshw -C memory
..
*-cache:0
description: L1 cache
physical id: a
slot: Internal Cache
size: 64KiB
..

64K / 64B = 1024 линейки, все хватает.


cppasm пишет:
Опять же - формально это память твоего процесса.
Т.е. всё что в него замаплено (библиотеки, шаред регионы и т.п.). Тут понятно.
Но писали же и про выход из-под ВМ в хостовую ОС, и про чтение памяти другого процесса и ещё кучу всяких сказок...

Чтение хост памяти из ВМ это отдельный разговор, вопрос же был о чтение памяти чужого процесса там используются немного разные техники. Для выхода из ВМ у нас должен быть полностью управляемый гость, далее ищется паттерн кода с индирект бранч предикшн, который будет исполняться после вызова гиперколла т.е. объекты атаки здесь ядреные модули на хосте обслуживающие виртуализацию. Далее по общей схеме, гость тренерует префетчер процессора, делается гиперколл там акцесится память доступная гостю и на выходе гость уже простукивает эту память.

cppasm пишет:
Одно дело возможность читать адресное пространство другого процесса по произвольным адресам (чего нет), а другое прочитать фиг знает что из шаред библиотеки и потом гадать что это вообще за данные...

Все есть. Шаред бибилотека это всего лишь канал передачи памяти чужого процесса, вскрывается именно приватная пямть чужого процесса. Не нужно делать поспешных выводов, тут более менее про ве это написано:
https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html

И POC для выхода из KVM гостя:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1272&t=1&cn=ZmxleGlibGVfcmVjcw%3D%3D&refsrc=email&iid=4601f5691854441e8ed24165977c0d98&uid=720236201446346752&nid=244+276893704

на vbox и других виртуалках коненчо же работать не будет.


Ранг: 316.1 (мудрец)
Статус: Участник

Создано: 14 января 2018 15:04 New!
Цитата · Личное сообщение · #20

Alchemistry

> KiKvaShadow, KiKvaLeakage, функция KiEnableKvaShadowing итд.

Спасибо, но мне имена ничего не говорят, хотелось бы посмотреть именно осевой код где это реализовано.

Oott

> вопрос же был о чтение памяти чужого процесса там используются немного разные техники.

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


Ранг: 655.4 (! !)
Статус: Участник
CyberMonk

Создано: 16 января 2018 12:32 · Поправил: mak New!
Цитата · Личное сообщение · #21

Haswell microcode 22h vs. 23h security (Spectre), performance and stability differences
--> Link <--



Ранг: 106.9 (ветеран)
Статус: Участник

Создано: 16 января 2018 15:34 New!
Цитата · Личное сообщение · #22

difexacaw пишет:

О каком чтении памяти другого процесса вы говорите, это невозможно, для этого нужно переключить адресное пространство и в нём выполниться. Сабж атака это не делает.


Я говорю о чтении памяти другого процесса через уязвимость Spectre, рассмотреть подробнее данный сабж Вы скорее всгео не потрудились. Поэтому пытаетесь лепить сюда Meltdown, который эксплотабелен только для чтения памяти повышенной привелегии.

Кстати интел выпустила бумагу о том как они расставляют костыли все это фиксят.
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf

На сколько я понял, Spectre они фиксят барьером памяти, который будет зваться на каждом контекст свиче и тем самым откатывать натренерованный префетч, чтобы один процесс не мог влиять на префетч другого процесса. Только не понятно, прикапывается ли предикшен стейт для каждой таски, что бы по возвращении им можно было воспользоваться.. Если нет, то это также поафектит производительность.

Ранг: 136.6 (ветеран)
Статус: Участник

Создано: 18 января 2018 09:05 New!
Цитата · Личное сообщение · #23

https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf


Ранг: 655.4 (! !)
Статус: Участник
CyberMonk

Создано: 20 января 2018 19:23 New!
Цитата · Личное сообщение · #24

Корпорация Intel продолжает активно уведомлять клиентов о ходе борьбы с уязвимостями Spectre и Meltdown, которые обнаружены в центральных процессорах многих разработчиков, и продукция марки не стала исключением. Как выяснилось недавно, системы на базе процессоров Haswell и Broadwell после применения "заплаток" в некоторых случаях стали чаще перезагружаться, причём проблема коснулась и серверных систем соответствующих поколений. Дополнительные меры по устранению проблемы уже принимаются, Intel обещает держать клиентов в курсе дела.

Компания Microsoft, в свою очередь, выяснила, что процессоры Intel поколения Haswell и более старые сильнее страдают от применения "заплаток", и это выражается в заметном снижении быстродействия системы. Программные платформы Microsoft, предшествующие Windows 7, демонстрируют более заметное замедление, а вот Windows 10 страдает от проблемы в меньшей степени. Владельцам серверных систем Microsoft рекомендует тщательно взвешивать приоритеты: безопасность и быстродействие находятся в этом случае на разных чашах весов.

Intel призналась, что заплатки для более новых процессоров тоже учащают перезагрузку

Корпорация Intel со страниц корпоративного блога вчера призналась, что применение обновлений микрокода, устраняющих уязвимости типа Spectre и Meltdown, вызывает более частые произвольные перезагрузки не только на системах, использующих процессоры поколений Broadwell и Haswell, но и в случае использования процессоров более новых поколений. Проблема касается и некоторых конфигураций на базе процессоров Skylake, Kaby Lake, Sandy Bridge и Ivy Bridge. Работа над устранением проблемы ведётся, партнёры Intel начнут получать бета-версии исправленного микрокода на следующей неделе.

Кроме того были опубликованы результаты тестирования серверных систем на базе процессоров поколения Skylake-SP, с целью определения влияния на быстродействия применённых "заплаток" от указанных уязвимостей. Как видите, крайних случаев падения производительности на 18% или 25% не так уж и много, чаще всё ограничивается единицами процентов.

--> Link <--

List of Links: BIOS Updates for the Meltdown and Spectre Patches

--> Link <--


Ранг: 316.1 (мудрец)
Статус: Участник

Создано: 21 января 2018 12:33 New!
Цитата · Личное сообщение · #25

Oott

> рассмотреть подробнее данный сабж Вы скорее всгео не потрудились.

Память общая только в верхней области(ядерная, за исключением сессионной) для всех процессов на NT. Когда происходит смена адресного пространства - перезагружается CR3, то сбрасываются все кэши(TLB). Поэтому никак нельзя обратиться к памяти чужого процесса - её просто не существует. Ядро для такой операции использует аттачь к процессу - принудительную перезагрузку CR3(при этом поднимается IRQL, так что RC атака становится невозможной).

В линях вроде бы как это возможно, но я их архитектуру не знаю и не могу ничего сказать. Говорят что там память чужих процессов расшарена и может быть доступна из текущего, так что это актуально только там.

Добавлено спустя 6 минут
Code:
  1. ;++
  2. ;
  3. ; VOID
  4. ; KiSwapProcess (
  5. ; IN PKPROCESS NewProcess,
  6. ; IN PKPROCESS OldProcess
  7. ; )
  8. ;
  9. ; Routine Description:
  10. ;
  11. ; This function swaps the address space to another process by flushing
  12. ; the data cache, the instruction cache, the translation buffer, and
  13. ; establishes a new directory table base.
  14. ;
  15. ; It also swaps in the LDT and IOPM of the new process. This is necessary
  16. ; to avoid bogus mismatches in SwapContext.
  17. ;
  18. ; NOTE: keep in sync with process switch part of SwapContext
  19. ;


Code:
  1. ;
  2. ; Load the new CR3 and as a side effect flush non-global TB entries.
  3. ;
  4.  
  5.         mov     eax,[edx]+PrDirectoryTableBase
  6.         mov     cr3,eax

Ранг: 238.9 (наставник)
Статус: Участник

Создано: 22 января 2018 12:28 New!
Цитата · Личное сообщение · #26

При загрузке CR3 сбрасываетя кэш TLB, а эксплуатируется загрузка даныых в кэш данных - это разные кэши.
Но как при этом читать из АП чужого процесса я тоже так и не понял.

| Сообщение посчитали полезным: difexacaw



Ранг: 316.1 (мудрец)
Статус: Участник

Создано: 22 января 2018 18:06 · Поправил: difexacaw New!
Цитата · Личное сообщение · #27

cppasm

На васм можите посмотреть тесты. Эффект несомненно есть, но он не подчиняется тому, что описывает паблик матчасть. TLB никакого эффекта не оказывают, но тем не менее задержки значительны и статистически однозначно обнаружимы. Просто авторы этих уязвимостей имеют доступ к приват(интернал) инфе. А есчо уклон делается в сторону линей, на нт это всё трудно реализуемо в принципе. Как например шар межпроцессной памяти.


Ранг: 312.4 (мудрец)
Статус: Участник

Создано: 27 января 2018 11:12 New!
Цитата · Личное сообщение · #28

difexacaw пишет:
на нт это всё трудно реализуемо в принципе


То есть, если попотеть, поднапрячься, то всё-таки можно?


Ранг: 316.1 (мудрец)
Статус: Участник

Создано: 27 января 2018 12:46 · Поправил: difexacaw New!
Цитата · Личное сообщение · #29

DenCoder

Не могу сказать, я подробно профайл не снимал. Посмотрите сами --> Link <--

Статистически обнаружима разница в профайле в некоторых случаях, но они не зависят от TLB. Даже если каким то образом(сомневаюсь) это и сработает, то вы не сможите прочитать память чужих процессов. Такова архитектура. Для чтения чужой памяти нужен прямой аттачь к процессу(давно я пытался найти ошибки в аттачах, но их нет). В линях это возможно. И что забавно --> Link <-- Торвальдс начал поливать говном NT, не смотря на то, что у него кривая и дырявая архитектура, эта атака работает только там

Видимо с головой не всё в порядке.


Ранг: 44.3 (посетитель)
Статус: Участник

Создано: 14 марта 2018 00:03 New!
Цитата · Личное сообщение · #30

началось, бгг
amd rip (https://amdflaws.com/)


Ранг: 539.1 (!)
Статус: Участник
оптимист

Создано: 15 марта 2018 12:03 New!
Цитата · Личное сообщение · #31

specz пишет:
amd rip

))) на подходе современные процессор для IOS
<< . 1 . 2 . 3 . >>
 eXeL@B —› Оффтоп —› Meltdown и Spectre - названия двух атак на процессоры Intel/AMD/ARM64

У вас должно быть 20 пунктов ранга, чтобы оставлять сообщения в этом подфоруме, но у вас только 0


Оригинальный DVD-ROM: eXeL@B DVD !

Вы находитесь на форуме сайта EXELAB.RU
Проект ReactOS