The OpenNET Project / Index page

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



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

Оглавление

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

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


11. "Обход полнодискового шифрования в Linux через непрерывное на..."  +4 +/
Сообщение от Q2Wemail (?), 02-Сен-23, 12:20 
Что это за шифрование такое, если ключи можно просто попросить у этого TMP, и он их имеет и даст?

Капец какой-то. Это как в автомобилях: для установки автозапуска вмуровывали в приборную панель оригинальный ключ.

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

12. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Q2Wemail (?), 02-Сен-23, 12:21 
s/TMP/TPM/
Ответить | Правка | Наверх | Cообщить модератору

18. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (17), 02-Сен-23, 12:34 
Сейчас есть решения без оставления иммобилайзера в машине
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

210. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от bOOster (ok), 03-Сен-23, 07:15 
Если иммобилайзер или блок управления двигателем уже не раздраконили - ключ в любом случае придется "закапывать"..
Ответить | Правка | Наверх | Cообщить модератору

330. "Это не так. есть заводские компоненты удаленного запуска"  +/
Сообщение от анонимоус (?), 12-Сен-23, 08:10 
например для VAG.
которые заводят двигатель в ограниченном режиме.
грется можно, двигаться нельзя.
Ответить | Правка | Наверх | Cообщить модератору

32. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (29), 02-Сен-23, 13:18 
Ключ шифрования LUKS по умолчанию хранится на самом диске, добро пожаловать в реальность. Просто для разблокировки (расшифровки) этого ключа используется либо пароль, либо машина-специфичные регистры TPM.
Да, обычно никто не хранит ключ расшифровки в TPM, хотя такая возможность существует.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

68. "Обход полнодискового шифрования в Linux через непрерывное на..."  –1 +/
Сообщение от Tron is Whistling (?), 02-Сен-23, 15:12 
В битлохере оно не просто существует, его надо руками выковыривать.
Ответить | Правка | Наверх | Cообщить модератору

108. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним2 (?), 02-Сен-23, 17:50 
Проблемы индейцев шерифа не касаются.
Ответить | Правка | Наверх | Cообщить модератору

82. "Обход полнодискового шифрования в Linux через непрерывное на..."  +1 +/
Сообщение от Аноним (82), 02-Сен-23, 15:53 
> Ключ шифрования LUKS по умолчанию хранится на самом диске, добро пожаловать в реальность. Просто для разблокировки (расшифровки) этого ключа используется либо пароль, либо машина-специфичные регистры TPM.

Эти регистры TPM - это как дополнительный слот для пароля в LUKS? Именно поэтому можно расшифровать диск или вручную или с TPM?

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

111. "Обход полнодискового шифрования в Linux через непрерывное на..."  +3 +/
Сообщение от Аноним2 (?), 02-Сен-23, 17:54 
Почитай про TPM например на хакере. Вкратце: принадлежит микрософту, делают ерунду по принципу security through obscurity, в целом очень похоже на ерунду которую делал интел со своими (неудачными) анклавами, старые версии совсем с детскими бекдорами, новыми лучше просто не пользоваться.
Ответить | Правка | Наверх | Cообщить модератору

118. "Обход полнодискового шифрования в Linux через непрерывное на..."  +1 +/
Сообщение от пох. (?), 02-Сен-23, 18:35 
> Эти регистры TPM - это как дополнительный слот для пароля в LUKS?

ну да.

> Именно поэтому можно расшифровать диск или вручную или с TPM?

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

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

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

102. "Обход полнодискового шифрования в Linux через непрерывное на..."  –2 +/
Сообщение от Аноним (-), 02-Сен-23, 17:38 
> Просто для разблокировки (расшифровки) этого ключа используется либо пароль,
> либо машина-специфичные регистры TPM.

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

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

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

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

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

119. "Обход полнодискового шифрования в Linux через непрерывное на..."  –2 +/
Сообщение от пох. (?), 02-Сен-23, 18:37 
> Во первых предлагается доверять мутной блобфирмвари какой-то хрени предоставить ключ,

Кто о чем, а мамкины конспирологи о кознях врагофф.

> Во вторых, возникает резонный вопрос "а насколько атакующему сложно получить эти данные"
> и судя по новости ответ на него - это полное ололо.

а это вопрос не к tpm, а, внезапно, к опенсорсной поделке и л@п4тым гениям безопастносте.

> В третьих если атакующему достаточно просто получить вот это для расшифровки ключа,

Вот это - это рут в уже загруженной системе со всеми правильными подписями всего. Да, удивительно, правда?

> возникает вопрос зачем вам шифрование диска было? Чтобы при случае таки

действительно. Если у тебя кто угодно может стать рутом - можно ничего уже не шифровать.

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

175. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (179), 02-Сен-23, 23:46 
> это вопрос не к tpm, а, внезапно, к опенсорсной поделке и л@п4тым гениям безопастносте

Чушь. Доступ к железу - это больше, чем рут. Режим восстановления (в systemd) тут погоды не делает. И придуман, чтобы не искать лайвсиди и не монтировать разделы руками в простых случаях поломок. Совет про "вечную перезагрузку" вместо "режима восстановления" из новости - где-то на грани добра и зла.

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

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

180. "Обход полнодискового шифрования в Linux через непрерывное на..."  –3 +/
Сообщение от пох. (?), 03-Сен-23, 00:09 
> Чушь. Доступ к железу - это больше, чем рут.

дружище, ты правда не понимаешь, зачем люди используют шифрованные диски?

> А типа "зашифрованные" данные, как раз, раскрывает корпоративная поделка с гениальным дизайном

нет. опенсорсная поделка по имени системдрянь.

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

181. "Обход полнодискового шифрования в Linux через непрерывное на..."  +1 +/
Сообщение от Аноним (179), 03-Сен-23, 00:12 
> дружище, ты правда не понимаешь, зачем люди используют шифрованные диски?

Я-то понимаю, зачем замки придуманы. А вот ты нет. Иначе бы ключами не разбрасывался.

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

183. "Обход полнодискового шифрования в Linux через непрерывное на..."  +2 +/
Сообщение от Аноним (179), 03-Сен-23, 00:14 
> нет. опенсорсная поделка по имени системдрянь

Опенсорсная она или дрянь корпоративная - роли не играет. Нету у неё пароля от LUKSа, хоть ты тресни. А у TPM есть.


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

177. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (179), 02-Сен-23, 23:56 
>Если у тебя кто угодно может стать рутом - можно ничего уже не шифровать.

Алё. Инициализация не завершена, разделы не примонтированы. Какой кто-угодно? Каким рутом?

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


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

182. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от пох. (?), 03-Сен-23, 00:14 
> Алё. Инициализация не завершена, разделы не примонтированы. Какой кто-угодно? Каким рутом?

обычным таким. Он тебе и инициализацию завершит, он - может.

> Уязвимость не в "руте" на этапе загрузки

уязвимость именно в этом. Его там быть было не должно, в подписанной системе, которой только и доверяет TPM (т.е. никакой левый не помог бы - но этот не левый, этот штатный именно от той системы что должна загрузиться). И даже старались, чтоб он там не возник без спросу. Но получилось как всегда - потому что опенсорсники в очередной раз запутались в своем "параллельном ините".

Так что прекращай подменять понятия - обоcpaлись именно вы.

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

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

Вот мы и нашли виноватого.

> обоcpaлись именно вы

Нет, вы.


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

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

Да вот сабж прозрачно намекает.

> а это вопрос не к tpm, а, внезапно, к опенсорсной поделке и
> л@п4тым гениям безопастносте.

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

> Вот это - это рут в уже загруженной системе со всеми правильными
> подписями всего. Да, удивительно, правда?

Ну вы ж хотели удобств. Вот, атакующему стало просто ЗБС. А чем он хуже пользователя чтобы обделять его?!

>> возникает вопрос зачем вам шифрование диска было? Чтобы при случае таки
> действительно. Если у тебя кто угодно может стать рутом - можно ничего
> уже не шифровать.

Если кто угодно может диск разблочить на автомате - это г@вно а не безопасность. С самого начала.

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

226. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от пох. (?), 03-Сен-23, 10:29 
>> а это вопрос не к tpm, а, внезапно, к опенсорсной поделке и
>> л@п4тым гениям безопастносте.
> Ну то-есть идея хранить ключ локально для того чтобы атакующий мог им
> воспользоваться, да еще доверив его мутному чипу без сорцов прошивки -

Последний раз для совсем полных иди0тов - чип ВНЕЗАПНО не позволил бы им воспользоваться.
Если бы его не попросил тот самый немутный очень сорцовый софт, которому чип доверял - по твоей же команде. Который нельзя подменить, если все сделать правильно. И который не должен был этого делать, если что-то пошло не так - но оно, вот.

> Ну вы ж хотели удобств. Вот, атакующему стало просто ЗБС. А чем

Потому что руки у опенсорсников - из оттуда. Но виноват почему-то "мутный чип".

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

245. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (245), 03-Сен-23, 12:15 
> Последний раз для совсем полных иди0тов - чип ВНЕЗАПНО не позволил бы
> им воспользоваться.

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

> Если бы его не попросил тот самый немутный очень сорцовый софт, которому
> чип доверял - по твоей же команде.

А профит с чипа по сравнению с хранением пароля в файлике простите в чем был? Результат настолько же фэйловый.

> Который нельзя подменить, если все сделать правильно.

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

> И который не должен был этого делать, если что-то пошло не так - но оно, вот.

Я почему-то всегда был уверен что половина смысла существования "секурных" чипов это как раз перестать уповать на секурити основной здоровенной, а потому что не факт что особо секурной, дуры. А тут как раз вот это самое и провалилось с треском. А чипак вообще нафига? :)

>> Ну вы ж хотели удобств. Вот, атакующему стало просто ЗБС. А чем
> Потому что руки у опенсорсников - из оттуда. Но виноват почему-то "мутный чип".

А функциональность мутного чипа в результате какая? А, атакующему ключ выдать нахаляву? За сам факт красивых глаз и доступа в "несекурную" основную систему? Это наверное именно то за что бабки надо за чип заплатить.

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

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

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

А вот это самое г-но - ОБЯЗАНО было по спецификации проверять, можно тут спросить ключ у TPM или надо спрашивать пароль с клавиатуры - но - обоcpaлось, потому что оно - т-пое рукожoпoe опенсорсное  г-но.

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

306. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от Аноним (-), 05-Сен-23, 12:47 
>> А функциональность мутного чипа в результате какая? А, атакующему ключ выдать нахаляву?
> б-ть, НЕТ - он его выдает твоему т-пому рукoжопoму опенсорсному г-ну,

Ну как бы фэйл в том что он нахаляву атакующему подмахивает - и вообще не важно чему и почему. А init=/bin/bash можно так то и без всяких системд вкатить и ввалиться в этот ваш рамдиск без спроса всяких козлов так то.

В результате смысл в аппаратном чипе с ТАКОЙ реализацией вызывает определенные вопросы. С таким же успехом можно было ключ шифрования из файлика шифровать, результат будет примерно такой же.

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

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

> А вот это самое г-но - ОБЯЗАНО было по спецификации проверять, можно
> тут спросить ключ у TPM или надо спрашивать пароль с клавиатуры
> - но - обоcpaлось, потому что оно - т-пое рукожoпoe опенсорсное г-но.

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

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

310. "Обход полнодискового шифрования в Linux через непрерывное на..."  +/
Сообщение от пох. (?), 05-Сен-23, 13:57 
> Ну как бы фэйл в том что он нахаляву атакующему подмахивает - и вообще не важно чему и почему. А
> init=/bin/bash можно так то и без всяких системд вкатить

и ничего не получится.

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

Вот как разберешься, почему - сможешь обсуждать, такая там реализация или не такая.

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

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

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




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

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