Эти ваши атаки на процессоры

Ради интереса посмотрел что это за чудо тест браузеров такой. Короче смотирм js

Смотрю через мозилу - SharedArrayBuffer - несуществующий объект. Тест заканчивается не начавшись - всё ok. Гуглю что это за херь такая -SharedArrayBuffer

https://developer.mozilla.org/ru/docs/Web/J...aredArrayBuffer

Эта херь нигде не существовала. В мозиле уже выпилили её. Вывод - отставить панику!

Не всегда наличие физического доступа позволит получить доступ к данным.

речь идет про обновления браузера, ось тут непричем

Вот ещё
http://www.topnews.ru/news_id_112910.html

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

Вам все равно не спастись! © Бонд. Джеймс Бонд.

Бля да какие научные работы

Есле коротко то это связано с спекулятивным выполнением программы после выполнения инструкции к обращению к запрещённой области памяти. При этом обращение к области памяти сохраняется в кеше адресов - который нельзя почистить. Под нельтзя это тупо не сделали возможность, а не то что это типа НЕВОЗМОЖНО. В АМД процессорах например не выполняются инструкции после эксепшена адреса.

Короче немного изменить кристалл. Вся проблема в том что за немного изменить топологию кроется бля изменить ВСЁ! Шаблоны чипов, топологию чипов и тому подобное. Вобщем много много денег надо выкинуть на ветер - т.к. все те чипы которые уже сейчас в производстве - выкинуть в мусорное ведро.
Ну или сделать рожу кирпичом - и сказать мол это пиздец какая сложная ошибка - ждём пока профессор научную работу напишет. А вы пока выкупите весь остаток чипов с дырами. А мы потом обязательно сделаем без дыр, ну добавим пару новых

Это сообщение отредактировал develоper - 18.01.2018 - 14:14

Боюсь, автор вообще не понял сути проблемы. И разработчик он, судя по всему, на 1s

Надо просто добавить в MMU проверку. В спекулятивном режиме она не выполняется и данные попадают в кеш.
Точно такая же история была с TSX-NI. Починили в следующем поколении.

Да, серьёзно. Реальные значения ключей подставляются в функцию заранее, на неатакованном компьютере. В небезопасную среду выпускается только whitebox. Дампить можно 24 часа в сутки всю жизнь. Смысла это лишено.

Почитайте на досуге

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

Объясняю, опять на пальцах. Кеш процессора это просто очень быстрая память (SRAM) которая очень дорогая и её в процессоре очень мало. Обращение в кеш за данными очень быстрое, а обращение в обычную ОП - очень медленное. Процессор разбивает кеш на небольшие кеш-линии (ну тупо массивы идущих друг за другом байтов). При обращении к адресу памяти N, процессор грузит не только значение этого адреса, но и последующие байты размером с кеш-линию. (я намерено опускаю сложности типа выравнивания значения адреса (alignment). При попытке считать следующий байт из памяти - процессор берет его из кеша. Это очень упрощённая схема, но суть ясна: кеш это "зеркало" небольшого кусочка ОП. Если данные в ОП будут зашифрованными, в кеш прилетят эти самые зашифрованные данные.

А вы хотели увидеть тут доклад для конференции по безопасности среди разработчиков процессоров? На пальцах объяснял насколько можно упрощая чтобы в основном народ (не связанный с IT) понял суть. Мне почему-то казалось, что IT ребята с полуслова поймут зачем я так упрощал и что там под капотом на самом деле.

Я говорил выше, что "Реальные значения ключей подставляются в функцию заранее, на неатакованном компьютере". Одно из важных правил в документации к этому ПО - НИКОГДА не зашифровывайте и не расшифровывайте исходные данные (имеется ввиду ключи и пароли) на компьютере, который может быть потенциально атакован.

Ну, и не мог обойти:

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

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

Скорее всего, антивирь спалил попытку эксплуатации уязвимости.

У меня тоже все нормуль

Это сообщение отредактировал Iovis - 18.01.2018 - 15:10

А каким образом обфускация помогает писать безопасный код? Всё равно компилятор выкинет лишнее. Обфускация полезна, если исходники стали доступны, но раскрывать алгоритм не хочешь. К тому же обфускация, если не владеешь методом в достаточной мере - лишний повод «выстрелить в ногу».

У меня была Opera 48, писал, что уязвим, после обновления до 50, стало неуязвим.

coolerok

эээ, тут чел говорит что дело совсем не в кеше
https://habrahabr.ru/post/346164/

Проблема в блоке TLB, который используется в пейджинговой адресации оперативной памяти. Он является ассоциативным буфером хранящим пары значений виртуальный-физический адрес используемой приложением в оперативной памяти. Это не Кеш данных….

Блок TLB нужен для того чтобы сократить время обращения к ОП за счет исключения процедуры трансляции адресов памяти. Такая трансляция производится единственный раз для всей страницы (размером как раз 4К в случае современных ОС). Все остальные обращения программы к памяти в этой странице уже происходят форсированно, с использованием сохраненного значения в этом буфере. Эти блоки есть во всех современных процессорах, собственно из-за этого все они и подвержены уязвимостям называемым теперь Spectre и Meltdown.

И кстати, спекулятивное выполнение команд не единственная возможность эксплуатации этих уязвимостей, можно задействовать механизм форвардной загрузки данных из ОП.

Блок TLB не имеет программного (микропрограммного) управления, как обычный кеш. Из него невозможно удалить запись, либо принудительно внести/модифицировать какую-либо запись.

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

Соответственно произведенная спекулятивно операция тоже оставит в блоке TLB cлед в виде записи, нужно только эту запись обнаружить и идентифицировать. А это уже «дело техники», технология давно известна и применяется, она называется «Исследование состояния аппаратуры методом временного прозвона». Не ищите этого названия в Интернете, метод был известен в очень узких кругах совершенно не публичных специалистов.

Данные программы (ее переменные и константы) - атакующим не интересны, это затруднит работу с такой программой но не более.

Если ваш диск зашифрован f(k,N) где k это ключ, а N данные, то k рано или поздно в памяти, потому что f(S(k),N), где S(k) зашифрованные ключи, не позволит дешифровать данные.

Вспоминается прикол с dropbox пару лет назад. Они тоже клялись, что у них нет ключей от твоих данных, что данные шифруются/расшифровываются на узле пользователя. Оказалось, хренушки. Собственно, как и в венде - аккаунт используется для доступа к ключу, который лежит в расширенных атрибутах файла (их ещё называют «потоком»). Эта штука ещё в XP была реализована, когда владелец зашифрованного файла мог предоставить доступ к нему другим юзерам.

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

Что такое wasm или js.asm - не только читал но и юзаю. Не буду здесь разводить холивар по поводу этих сырых (работают не везде и по разному и вообще разные компании толкают своё) технологиях. Есть товарищ с которым мы как раз и ломаем копьи по поводу этого, но не здесь.
Так вот - браузер выполняет СКРИПТЫ. Хоть это js, хоть это не читаемая байт хрень типа wasm.
Что есть скрипты - команды не направляются напрямую к процессору, а проходят преобработку.
Так вот в браузере нельзя выполнять команды напрямую в процессоре - иначе эта огромная ДЫРА по умолчанию.
Например из js - нельзя работать напрямую с файловой системой. Иначе можно было бы просто тупо спиздеть любой файл до которого дотянешся (позволят права).
Что такое обфускация - как уже говорили и так все знают, хотя судя по всему далеко не все, и даже мало кто - потому как всем насрать. Собственно её тоже незачем обсуждать.
P.S. Даю наводку. Браузер понимает только js (не обсуждаем всякую хрень типа сервелата, flash и подобных трупов). Внимание вопрос - как на браузере выполнить wasm?

Это сообщение отредактировал develоper - 18.01.2018 - 15:03

эх мля только бы танки из ангара не угнали (((

Короче всё идет к тому, что надо иметь два компа. Один для работы с инетом на котором один хард без разбивки и в случае чего format C: - Enter, а второй без подключения к инету, да и вообще к сети, на котором вся важная информация. На одном проверил файлы и скачал на другой.

При переходе по ссылке антивирь сразу удалил какую то хрень вида 4cba553e7b7ea.....
На сайте ни чего не нажимал.

Как понимаю ТС предлагает "немного" изменить ПО, скорее всего имеется в виду ОС, когда данные которые не нужны в данный момет времени вытесняются из кэша в ОП.
А чтобы данные враг не украл будут шифроваться.
То есть CPU будет постоянно в ох*ении, шифруя и дешифруя все данные между ОЗУ и кэшем, не берем данные с жесткого диска.
Думаю даже с встроенными инструкциями шифрования типа AES-NI утилизация процессров улити в небеса, тем самым получим офигенные лаги.
Как это чудо будет работать на платформах виртуализации, а большинство сервисов и систем, тот же сайт ЯП сидят там, даже сложно представить.
Т.к. хосты виртуализации для оптимизации используют дедупликацию областей памяти гостевых систем.

Это сообщение отредактировал gr0und - 18.01.2018 - 15:04

Тогда вы не сможете дешифровать диск. Рано или поздно этот ключ должен быть расшифрован.

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

От нечего делать проверил Хром на рабочем компе.Неподвержен! Попробовал так же проверить IE- так он наглухо завис. Недаром последние 12 лет не юзаю две вещи:IE и стандартный проводник винды.