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

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

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



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

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

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

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

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

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 <--

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

*удалил

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

вобщем, проблема не решается только фиксом 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 числа - результаты на уровне погрешностей, т.е. одинаковые, что до патча ядра, что после. может на процессорах с другой архитектурой или профессиональных задачах будут видимые просадки, но лично у меня разницы нет.

-----
Array[Login..Logout] of Life

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

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

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

Archer

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

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

-----
vx

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

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

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

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

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

Alchemistry

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

-----
vx

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

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

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

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

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

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

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

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

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

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

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

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

cppasm пишет:
С учётом того что данные получаются по 1 биту - в итоге вместо данных там будет полная фигня.
Можно и по байту вычитывать, просто простукивать больше памяти, зависит от реализации.

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

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

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

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

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

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

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

cppasm пишет:
https://github.com/ionescu007/SpecuCheck
Этот балабол и рипнул их из официального повершел скрипта. Дальше были обильно насыпаны черепа и кости в консольке.

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

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 и других виртуалках коненчо же работать не будет.

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

Alchemistry

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

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

Oott

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

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

-----
vx

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

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



-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

difexacaw пишет:

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

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

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

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

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

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

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

Корпорация 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 <--

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

Oott

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

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

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

Добавлено спустя 6 минут




-----
vx

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

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

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

cppasm

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

-----
vx

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

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

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

-----
IZ.RU

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

DenCoder

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

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

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

-----
vx

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

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

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

specz пишет:
amd rip
))) на подходе современные процессор для IOS

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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