Pull to refresh

Comments 14

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

Вот и получаем в день по две уязвимости — одну от Стима, второю от Интела.
А с учетом, что эти новости выходят новые процы АМД для серверов…
Как минимум для этой «уязвимости» есть решение:
Уязвимость SWAPGSAttack не опасна для компьютеров под управлением ОС на базе Linux.
Мне одному кажется, что в балансе безопасно vs быстро индустрия сворачивает куда-то не туда?

Давайте шагать дальше, господа! Скажем, есть вектора атаки на чтение памяти по энергопотреблению БП, да, для успешной атаки необходимо 10 000 часов и прямой доступ к железу, но мы же параноики, так что теперь в комплекте с каждой планкой памяти давайте делать неотключаемый встроенный утюг. Есть атака по тональности свиста дросселей? Не вопрос! Добавим в каждый чипсет постояннодействующую сирену на 130 децибел. Можно залезть на шкаф и, пригнувшись, через бинокль в женской бане напротив рассмотреть пароль на экране администратора? Правильно! Сжечь все мониторы, только звуковой ввод/вывод через имплантируемые гарнитуры в массы и на все устройства!

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

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

Hosting/Cloud/другие примеры разграниченивания прав на одном железном хосте? Причем с увеличениваем производительности на один процессор/сокет — это всё актуальней.


Песочничный cgi-bin — это зловредный код или нет?

Какая выгода от того, что отделят безопасность от прикладных задач, когда дыра в том, что прикладная фишка процессора по предсказанию ветвления имеет дыру через которую можно стащить всё?
Я бы посмотрел, как «прикладная фишка» стащила бы все из специализированного криптографического сопроцессора, расположенного отдельным чипом на, возможно, отдельной защищенной шине.
Ок! Есть отдельная микросхема с криптографией. Но Спектре использует уязвимость микрокода процессора. Когда данные уже расшифрованы или ещё не зашифрованы. И эти данные лежат «условно» в процессоре. Дело не в наличии специальной аппаратной штуковине связанной с криптографией. А с тем, что безопасность кода нельзя отделить от кода. Если программист использует обычный текстовый файл, в котором хранятся логины и пароли, то наличие или отсутствие некоей аппаратной криптографии не спасёт от просто копирования файла на уровне ОС.
И да: криптография <> безопасность.
> И эти данные лежат «условно» в процессоре.

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

Ну и дальше вы пытаетесь спорить с соображениями, полностью противоречащими моему исходному коментарию. Будем вместе спорить с воображаемым оппонентом?

Если вы прочитали моё:
> Правильным, но сложнореализуемым решением было бы разделить на аппаратном и софтверном уровне задачи криптографии+безопасности и общеприкладные.

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

Можно по-подробнее об этих методах? А то я, видимо, не так всё понял из ваших комментариев.
Два примера на поверхности:

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

2. Аторизация.
Банальная токен авторизация. Ключ не уходит за пределы анклава, токен, генерируемый на основе ключа, одноразовый.

И это то, что решается прямо вот на коленке, защищенным хранилищем ключей с отдельным от основного процессора специализированным АЛУ. В случае нахождения атаки на данный анклав достаточно пропатчить только его, пусть и с потерей в его производительности. А котики как крутились себе на основном процессоре, так и крутятся на полной производительности.
Безопасность — это комплексное понятие, но вот такие дыры низводят весь комплекс мер в ничто и требуют принципиально нового подхода к разработке софта — будем считать, что софт работает на изначально скомпроментированном компьютере, ваши действия?

Only those users with full accounts are able to leave comments. Log in, please.