The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обход полнодискового шифрования в Linux через непрерывное нажатие клавиши Enter, opennews (??), 02-Сен-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


212. "Обход полнодискового шифрования в Linux через непрерывное на..."  +3 +/
Сообщение от Аноним (-), 03-Сен-23, 07:19 
> TPM не может быть бекдором, так как не умеет активно влиять на
> вычислительные процессы. Это просто ящик с секретами, которые выдаются

...кому попало! И по случайному совпадению - упал на мой кулак 5 раз подряд, тьфу, то-есть расшифровал 5 дисков подряд, и это типа не уязвимость а так и задумано :). Может тогда пароль на бумажке под клавиатурой стоило хранить? Чтоб атакующему не париться вон той ерундой а сразу ввести его как белому человеку.

> Secure boot нужен, чтобы сделать систему защищённой от буткитов.
> Чтобы злоумышленник, временно получивший возможность писать в загрузочные области
> диска не смог закрепиться в системе.

Во первых оно многим и не надо. Во вторых - у майкрософта и OEM утекали ключи подписывания все и вся, они и сказали что отзывать их не будут. А то дескать загрузка винды на дофига систем сломается. И черт с ними с буткитами!

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

Но по дефолту оно видите ли доверяет каким-то майкрософтам, ОЕМ и проч, забыв пользователя спросить, да еще на честное слово предлагается поверить мутному проприетарному блобу, без особой возможности так по простому проверить что он реально сделал, какие еще ключи остались и все такое прочее. Очень безопасно смотрится. Примерно как модуль с секретами отдающий ключ от диска левому хаксору.

> Intel SGX нужен для двух вещей - производить конфиденциальные вычисления на чужом
> оборудовании (не нужно доверять оператору облака, а только лишь вендору CPU)

Тоже та еще жаба и гадюка. Доверять с ножом к горлу фирме напихавшей в железо ME, бутгадов, шифрованых апдейтов микрокода, кучу недокументированого нечто, и что там еще? И оставившей реальный мастерключ платфррмы (от ROM ME) себе? Звучит очень многообещающе. В плане заявок на залет.

> и давать хоть какую-то безопасность на сплошь затрояненном десктопе пользователя.

В смысле, заниматься имитацией бурной деятельности, втирать очки и создавать иллюзию безопасности в надежде что лох купится и залетит? :)

> Тоже на бэкдор не похоже - там взаимодействие с системой отгорожено заранее
> декларированным IDL,

И проверить это все можно - ну - например как? А, поверить джентльменам на слово?! И тут им карта как поперла, как поперла...

> Intel ME нужен примерно для того же, для чего и обновляемый микрокод

Ага, конечно. Контролиорвать платформу от и до - и оставить самый мощный мастерключ (вшитый в ME boot ROM) себе. Попутно впарив лохам иллюзию контроля, блалба про безопасность, не забыв завинтить DRM и ограничилова. А заодно сделав таймаут вгрузки фирмвари ME и шатдаун системы через полчаса если вдруг НЕлох попробует сумничать и таки выпилит враждебную мутную фимрварь из системы. Такое поведение прозрачно намекает что белый человек раздает индейцу клевые одеяла не просто так. Кстати уже и не бесплатно - еще и бабки требуют за тифозное одеяло. Ничего личного, это бизнес.

> уже изготовленные экземпляры процессора с ошибкой. Можно только с натяжкой назвать
> бэкдором, если вспомнить про Intel AMT/vPro в корпоративной серии чипсетов,

Это тот же ME и есть! Только у него фирмварь чуть пожирнее и фичастее. Но можно подумать вы прямо на каждой первой мамке, каждой субревизии, чекаете от и до что там прошивка ME умела, до последнего бита. Без сорцов то, аж два раза. Лучшее что есть это исследования позитивов, но они валидны для пары конкретных версий которые они ковыряли. Если завтра что-то пропатчат - вы об этом если и узнаете то далеко не сразу. А сперва основательно подзалетев, а потом уже может и заметите, конечно.

> который ещё через MEBx надо включить.

ME вообще самый первый в системе стартует со своим ROM. Включать он удумал мастерключи в системе, ога. Интел тебе лохи чтоли?

> Не вижу причины не доверять ME, если уже доверяешь процессору от Intel,
> вставляя его в свою плату.

Не вижу причин доверять куче мутной блоботы с известным нежелательным поведением, например, DRM и искусственными ограничениями.

> А уязвимость тут в неправильном использовании TPM - перед тем, как давать
> отладочный шелл, надо портить содержимое TPM PCR,

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

Ответить | Правка | Наверх | Cообщить модератору

272. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (199), 03-Сен-23, 23:39 
> ...кому попало!

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

Я вижу только один недостаток - мне приходится верить на слово производителю TPM-чипа, что там нет секретной инструкции "откройте, ФБР!". Но от этого спасает разделение секрета на части - одна в TPM, другая на бумажке, третья на удалённом сервере с вайтлистом по IP. И в таком виде с TPM становится лучше, чем без него.

> Может тогда пароль на бумажке под клавиатурой стоило хранить?

Подход с бумажкой не масштабируется и не защищён от подмены сервера.

> Во первых оно многим и не надо.

Кому не надо, те могут не использовать. Большинство пользователей Windows не умеют проверять подлинность своей системы, а обновлять её всё равно как-то надо. Кому надо не для Windows, те могут свои db и dbx загрузить, выкинув ключи от MS.

> Доверять с ножом к горлу фирме напихавшей в железо ME

Так всё равно сам чип от той же фирмы и закрытый. А даже если бы был открытый, то провалидировать отсутствие в нём бэкдора почти нереально. Разницы никакой.

> А, поверить джентльменам на слово?!

Аналогично предыдущему пункту. Если нет доверия Intel, то зачем вставлять его процессоры в сокет своей системы? Мастерключ тут - не подписи, а исходники самого чипа.

> Если завтра что-то пропатчат - вы об этом если и узнаете то далеко не сразу.

Чтобы пропатчить ME, надо патч во флеш-память записать. SPI замотивированный пользователь всё ещё может контролировать.

> А тот кто дизайнил эти булшит-спеки уж точно атакующим быть не умел.

Что именно в спеке TCG TPM 2.0 вызывает проблемы?

Кстати, спека TPM почти нигде не говорит, что TPM обязан быть закрытым. Если забить на валидацию EK против рекомендованного TCG списка сертификатов, то можно сделать открытую реализацию - свободные эмуляторы TPM вполне существуют, и их можно использовать, если запускать их на отдельной машине с SPI или LPC-интерфейсом до целевой.

Ответить | Правка | Наверх | Cообщить модератору

307. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (-), 05-Сен-23, 13:21 
> Как политика настроена, тому и выдаётся. Можно и кому попало, а можно
> только в случае совпадения измерений системы.

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

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

> Поменял критические компоненты - измерения тоже поменялись.

Как показал САБЖ может получиться что менять ничего и не надо... а откуда бы обратное в обязаловку следует?

> Я вижу только один недостаток - мне приходится верить на слово производителю
> TPM-чипа, что там нет секретной инструкции "откройте, ФБР!".

Ну да. Он в очень удобном месте - может прихранить все измерения, секреты и проч для "vendor cmd" например. Да и вот кому попало диск при случае разблокирует на раз.

> Но от этого спасает разделение секрета на части - одна в TPM, другая на
> бумажке, третья на удалённом сервере с вайтлистом по IP.

А TPM в этом случае вообще зачем? Чтобы деньги по приколу потратить, а потом еще вот так под дых получить?

> И в таком виде с TPM становится лучше, чем без него.

Как по мне - в секурити ложные ожидания до добра не доводят.

>> Может тогда пароль на бумажке под клавиатурой стоило хранить?
> Подход с бумажкой не масштабируется и не защищён от подмены сервера.

Зато это ssh какой поймает. А если они от и до перекатали образ, вплоть до ключа ssh - так, окей, а защищаем мы тогда что и от кого? Или как вон там - просто обошли и пошли дальше?

> Кому не надо, те могут не использовать. Большинство пользователей Windows не умеют
> проверять подлинность своей системы, а обновлять её всё равно как-то надо.

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

> Кому надо не для Windows, те могут свои db и dbx загрузить, выкинув ключи от MS.

И как я в мутной блобвари без сорца должен проверить что оно и правда сделало вот именно это, что других ключей и прочих AWARD_SW там нет и проч? Или я должен развесить уши - и как раз когда расслаблюсь - получить ножик в спину? :)

> Так всё равно сам чип от той же фирмы и закрытый.

Ну вот лично я этой фирме вообще совсем и не доверяю. Да и амд с момента внедрения PSP - тоже. Во избежание формирования ложных ожиданий и залета на этом основании.

> А даже если бы был открытый, то провалидировать отсутствие в нём бэкдора
> почти нереально. Разницы никакой.

Ну как нереально. Есть немало чип-лаб изучающих что, где, как и проч. С спеками это заметно проще.

>> А, поверить джентльменам на слово?!
> Аналогично предыдущему пункту. Если нет доверия Intel,

За кого вы меня принимаете, доверять господам оставившим самый сильный ключ платформы себе?!

> то зачем вставлять его процессоры в сокет своей системы? Мастерключ тут - не подписи,
> а исходники самого чипа.

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

>> Если завтра что-то пропатчат - вы об этом если и узнаете то далеко не сразу.
> Чтобы пропатчить ME, надо патч во флеш-память записать. SPI замотивированный пользователь
> всё ещё может контролировать.

Это чтобы перманентно пропатчить. А что оно там по факту умеет и не догрузит ли по сигналу снаружи бонусы в RAM - большой вопрос! Это каждый ROM - и все что он грузит - надо аудитить от и до. Мадам Руткитская намекает что ей удалось вгрузить код в RAM ME, они назвали это "Ring -3". Когда x86 код в раме ME вообще не может даже и увидеть то, ME более привилегированная штука. И DMA могет. При том заметьте, это ПРОДЕМОНСТИРОВАНО было.

>> А тот кто дизайнил эти булшит-спеки уж точно атакующим быть не умел.
> Что именно в спеке TCG TPM 2.0 вызывает проблемы?

Ну вот например сабжевое поведение выглядит как кусок бреда. Да и в целом - "корпоративный оверинжениринг, бессмысленный и беспощадный". Когда все сложно, гиморно и - неэффективно.

> можно сделать открытую реализацию - свободные эмуляторы TPM вполне существуют, и
> их можно использовать, если запускать их на отдельной машине с SPI
> или LPC-интерфейсом до целевой.

Ну как бы "можно сделать" не отменяет того факта что по дефолту троянский булшит. И UEFI той же проблемой страдает. Бонусом идет в комплекте с господами которые охотно ломают только загрузку линуха. А если ключи сперли, не, мы виндочке обламывать загрузку не будем - что вы! Такая вот "безопасность" по факту получается. Малварщики разумеется возьмут вон тот ключ и выпишут себе что хотели. Или что-то несекурное подписаное, они ж на результат работают.

Ответить | Правка | Наверх | Cообщить модератору

276. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (199), 04-Сен-23, 01:11 
> А может, просто не надо хранить ключи шифрования в чипах с мутноблобистой фирмварой? Да и даже с открытой - и правильным процессом - стоит сто раз подумать что если ключ локально есть то и атакующий до него добраться в принципе все-таки может.

Представь себе железку, которая висит на линии reset и умеет один раз за загрузку по единственной команде отдавать ключ. Подключена эта железка по тупому протоколу, без всяких DMA - пусть будет RS-232. Как ты собираешься удалённо добираться до ключа?

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

Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

308. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (-), 05-Сен-23, 13:37 
> Представь себе железку, которая висит на линии reset

А зачем на линии Reset то?

> и умеет один раз за загрузку по единственной команде отдавать ключ. Подключена эта железка
> по тупому протоколу, без всяких DMA - пусть будет RS-232. Как ты
> собираешься удалённо добираться до ключа?

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

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

> Атакующий конечно сможет добраться до всего - абсолютно защищённых систем не существует.
> Даже если ключа не будет локально, он сможет его в момент ввода сохранить.

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


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру