forum.opennet.ru - "Обход полнодискового шифрования в Linux через непрерывное нажатие клавиши Enter" (298)

"Обход полнодискового шифрования в Linux через непрерывное нажатие клавиши Enter"

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

"Обход полнодискового шифрования в Linux через непрерывное нажатие клавиши Enter"	+/–
Сообщение от opennews (??), 02-Сен-23, 12:01
Майкл Финчем (Michael Fincham) из компании Pulse Security выявил уязвимость в реализации механизма разблокировки полнодискового шифрования, позволяющую при наличии физического доступа к компьютеру выполнить свои команды с правами root на раннем этапе загрузки, вручную снять блокировку с шифрованного диска и получить полный доступ к информации, хранимой на дисках. Уязвимость затрагивает Linux-системы в которых используется формат шифрования LUKS (Linux Unified Key Setup), механизмы защиты ключей на базе TPM (Trusted Platform Module) и компоненты Clevis, dracut и systemd для организации автоматической разблокировки во время загрузки... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59702
Ответить \| Правка \| Cообщить модератору

Оглавление

Скрыто модератором, Аноним (1), 12:01 , 02-Сен-23, (1) –4

Скрыто модератором, Аноним (8), 12:12 , 02-Сен-23, (8) +9

Скрыто модератором, пох. (?), 13:19 , 02-Сен-23, (33) +1

В чём смысл TPM, если с его помощью система просто загружается без ввода пароля , Аноним (3), 12:02 , 02-Сен-23, (3) +19

Не взломав систему, не получишь доступ к данным на диске Если просто вынуть дис, Аноним (8), 12:04 , 02-Сен-23, (4) +1

Сломалась материнка - прощай инфа на диске , Аноним (7), 12:11 , 02-Сен-23, (7) +7

На этот случай есть пароль для ручной разблокировки , Аноним (8), 12:13 , 02-Сен-23, (9)

171 На этот случай у меня есть проездной 187 , bergentroll (ok), 15:36 , 02-Сен-23, (78) +9
Тогда в чём смысл TPM , Аноним (87), 15:58 , 02-Сен-23, (87) +3

Ну как, без него атакующий в систему не попал бы Бэкдор успешно выполнил свою ф, Аноним (-), 17:42 , 02-Сен-23, (103) +2
В том, чтобы не быть ограниченным _только_ ручным вводом Да-да, в свете этой нов, Shevchuk (ok), 20:38 , 02-Сен-23, (136) –1

Почему Если я их в другой системе попробую примонтировать,появится диалог ввода , Аноним (17), 12:32 , 02-Сен-23, (17) +1

я слышал что была такая игра, там штангист поднимает штангу, и чем чаще нажимает, Dmitry22333 (ok), 20:11 , 02-Сен-23, (132) +1

А нельзя, вынув диск, подключить в материнку свой диск, загрузиться с рутом и пр, Страдивариус (?), 09:49 , 03-Сен-23, (217) +3
Ну т е если не брать всякую биометрию, то всё равно пароль нужно вводить, прост, погроммист (?), 16:41 , 04-Сен-23, (291)

В данном случае видимо наглядное демо что удобство и безопасность живут по разны, Аноним (-), 12:09 , 02-Сен-23, (6) +14

Смысл авторазблокировки не в том, чтобы создать невзамываемую систему, а в том, , Аноним (29), 13:15 , 02-Сен-23, (29) +5

Обычный слесарный молоток решает эту проблему , pic (?), 13:48 , 02-Сен-23, (43) –4
И этот бред в результате защищает - паазвольте ка, кого и от чего Если атаку, Аноним (-), 17:21 , 02-Сен-23, (98) +2
теперь нужно воровать диск с мат платой и входить без пароля так фбр удобней А, АнонимПротивЦензуры (?), 20:55 , 04-Сен-23, (295) +2

TMP полная чушь Гораздо надежнее использовать флешку для хранения ключей Вынул, Аноним (16), 12:31 , 02-Сен-23, (16) +5

Использую аппаратный TPM, его можно вынуть Гребенка под него есть практически н, Аноним (29), 13:10 , 02-Сен-23, (26)

Почитай что такое TPM Это лютая дичь с security through obscurity В первой вер, Аноним2 (?), 17:42 , 02-Сен-23, (105) +4

Почитай, что такое descrete TPM Можешь заодно погуглить картинки и почитать про, Аноним (207), 05:15 , 03-Сен-23, (207)

а встроенное шифрование в диск вставить фбр не разрешило, АнонимПротивЦензуры (?), 20:59 , 04-Сен-23, (296)

TPM - гoвнo Бай дезигн , Аноним (173), 23:36 , 02-Сен-23, (173) +2

Ну вот утром был сбой системы защиты электропитания в DC, она защитила электропи, пох. (?), 13:29 , 02-Сен-23, (39)

IPMI с удалённым экраном и флешкой и пароль - лучше ещё не придумано , Tron is Whistling (?), 15:00 , 02-Сен-23, (61) +3

Открой для себя Tang Жизнь с шифрованными томами в ЦОДе станет существенно легч, Тот самый (?), 17:49 , 02-Сен-23, (107) +1

Причём ключ никогда не покидает машину, на которой он используется для расшифров, Shevchuk (ok), 20:54 , 02-Сен-23, (137) +1

Пасибо, ребята, но настолько базовые ключи автоматически по сети ходить не должн, Tron is Whistling (?), 21:33 , 02-Сен-23, (144)

Ты так и не понял, что такое Tang , Тот самый (?), 02:39 , 03-Сен-23, (195) +2

Как этот Tang проверяет, что злодей не пересобрал initramfs, вставив туда дамп и, Аноним (199), 04:02 , 03-Сен-23, (199)

Да никак, плюс всё это автоматизировано - и фиг отследишь, когда утекло , Tron is Whistling (?), 09:48 , 03-Сен-23, (216)

ты вот пробовал это в рамках хотя бы первых сотен коробок Уверяю тебя, быстро р, пох. (?), 18:26 , 02-Сен-23, (116) –2

А у меня вообще других вариантов нет К счастью, эта штатная перезагрузка бывает , Tron is Whistling (?), 21:31 , 02-Сен-23, (143) +1
cryptsetup-initramfs dropbear ssh 3, Вася (??), 22:53 , 02-Сен-23, (160)
а что это за система у тебя такая, что требует FDE эндпоинтов так еще кластер на, penetrator (?), 23:28 , 02-Сен-23, (171)

от давай ты и будешь таким администратором А мы поржем с безопасного расстояния, пох. (?), 00:05 , 03-Сен-23, (178)

Я хочу опыт в ЦОД Сколько ЗП, какой город , count0 (ok), 18:16 , 19-Сен-23, (335)

TLVнорм там зарплата Но этот ЦОД принадлежит 1513 1489 а они понаехов не, пох. (?), 13:46 , 20-Сен-23, (336)

Скажу больше - если серверов 1000 такое происходит каждый день, но даже с физич, Аноним2 (?), 17:48 , 02-Сен-23, (106)

вряд ли ты можешь похвастаться 1000 шифрованных серверов и толку-то с него Ты , пох. (?), 18:20 , 02-Сен-23, (114) –1

Ну будем честными _шифрованных_ серверов обычно столько и не надо , Tron is Whistling (?), 21:35 , 02-Сен-23, (145)

ну хз что там у какого-нибудь протона Но мне бы хватило вот просто тыщи серверов, пох. (?), 22:43 , 02-Сен-23, (157)

А фирмварь на хардварных нодах вообще не обновляете Без IPMI этот процесс выгля, Tron is Whistling (?), 09:51 , 03-Сен-23, (218)

там где их тыщи Конечно не обновляют, это ж совсем е нуться можно П-данулась, пох. (?), 10:19 , 03-Сен-23, (222) –1

Да не, всё достаточно просто, образ с фирмварью и немножечко автоматизации Бут-п, Tron is Whistling (?), 10:29 , 03-Сен-23, (225)

у нас нет тысячи нод, но я так прикидываю - сотен 5 за день окучить вполне реал, Tron is Whistling (?), 10:30 , 03-Сен-23, (227)

Тыщи нод у нас так-то реально только у гугла и прочих мажоров, но там и землекоп, Tron is Whistling (?), 10:32 , 03-Сен-23, (228)

да ладно тебе, какой гугль мелкая конторка в которой я имел сомнительное щаст, пох. (?), 10:42 , 03-Сен-23, (232) +1

Ну, сейчас корытца стали пожирнее, и их реально поубавилось - ледники надо береч, Tron is Whistling (?), 10:45 , 03-Сен-23, (233)
Скажите, которые нужно ненавидеть и не покупать А то вдруг попросят подсказать , count0 (ok), 13:56 , 20-Сен-23, (338)
речь о сетапах, а не серверах Иногда на сервере стоит что-то такое что его нель, пох. (?), 14:44 , 20-Сен-23, (342)
Видимо поэтому и придумали CI CD, чтобы не обращать внимание на падения железа, , count0 (ok), 14:46 , 20-Сен-23, (343)
угу А потом такие - ой, транзакция потерялась или раздвоилась, что еще забавн, пох. (?), 14:52 , 20-Сен-23, (344)
Чтобы не потерялась - проверяет скрипт на стороне клиента не получил от сервера, count0 (ok), 23:02 , 21-Сен-23, (345)

за 7000 руб час вообще без проблем оплачиваемое время включает поездкудо места , ivan_erohin (?), 17:50 , 02-Сен-23, (109)

Какой дешовый раб дык был дизель Не очень помогает - когда выходит из строя с, пох. (?), 18:24 , 02-Сен-23, (115) –2

окей, назови свою цену особо сложной работы там не будет,вставил-вынул и бежать, ivan_erohin (?), 20:00 , 02-Сен-23, (129) +1

удовольствие от посещения гермозоны и пребывания в ней несколько часов к ряду - , пох. (?), 23:03 , 02-Сен-23, (163)

Что смотришь, HR у звони Поделите премию на двоих, нормуль А может, состояние, Аноним (200), 04:20 , 03-Сен-23, (200)

а он точно не подставит меня так со своими подходами, что МНЕ придется тоже звиз, пох. (?), 10:23 , 03-Сен-23, (223)

Можно деловое предложение в договор вписать если не справился то получает 0, и , Аноним (-), 12:04 , 03-Сен-23, (242)
Ну вообще, то каждая ветвь электропитания имеет свою собственную независимую схе, Anon3 (?), 12:18 , 03-Сен-23, (247)

Читал историю ТуТу ру и их общение с датацентрами В-общем надо резервироваться , count0 (ok), 14:05 , 20-Сен-23, (339) +1

Под ssh ключи tpm вполне годится Лучше, чем голый ключ на диске , погроммист (?), 16:43 , 04-Сен-23, (292)

Ты сам ответил на свой вопрос Нет видимого смысла, когда любой имеющий физическ, Аноним (87), 15:56 , 02-Сен-23, (86) +2
Основная мотивация в том, чтобы защищать данные поставщиков ПО и контента от пол, Аноним (156), 22:38 , 02-Сен-23, (156) +1

StarForce-3 , count0 (ok), 14:07 , 20-Сен-23, (340)

правильное использование TPM - контроль целостности системы чип TPM собирает инф, onanim (?), 12:23 , 03-Сен-23, (248) +2

т е контролировать софт через TPM - глупость примерно нихрена не сможет Сноуд, ivan_erohin (?), 10:07 , 13-Сен-23, (331)

что значит контролировать софт через TPM ну от снифферов PCI или SPI шин ничто, onanim (?), 12:31 , 13-Сен-23, (332)

Зато те, у кого могли быть такие платы за пределами МКАД отсутствуют, поэтому и , count0 (ok), 14:11 , 20-Сен-23, (341)

А вот не фиг ключи хранить где попало Т е на системе без TPM этот номер вооб, Аноним (-), 12:08 , 02-Сен-23, (5) +2

на системе без TPM невозможно вообще загрузиться автоматически - будешь как лox , пох. (?), 13:22 , 02-Сен-23, (35) +4

Если у вас в ЦОДе радиус со лдапой не завезли, то это печально, печально , InuYasha (??), 13:24 , 02-Сен-23, (37) –2

они как тебе помогут для загрузки сервера, который вот встал в позу и ждет твой , пох. (?), 13:30 , 02-Сен-23, (40) +4

Ну я выну им из широких штанин фак W флеху с из STM32 Оно и напечатает парол, Аноним (-), 14:05 , 02-Сен-23, (47) +4
Зачем пешком-то Удалённое управление каким-нибудь iDRAC , Tron is Whistling (?), 15:01 , 02-Сен-23, (62) –1

Dell тебя благобдарит , Аноним (173), 23:04 , 02-Сен-23, (164) +1
А как ты проверишь, что между iDRAC и разблокируемым сервером нет MiTM , Аноним (199), 04:00 , 03-Сен-23, (198)

TLS, Tron is Whistling (?), 09:35 , 03-Сен-23, (214)

а как ты проверишь, что iDRAC не пишет нажатия клавиш и не передаёт куда следуе, onanim (?), 12:10 , 03-Сен-23, (243)

Зачем , Tron is Whistling (?), 19:08 , 03-Сен-23, (262)
Поясняю Я не помешан на приватности Мне принципиально только то, чтобы уборщик, Tron is Whistling (?), 19:11 , 03-Сен-23, (263) +1

уборщик Вася и TLS перехватить не осилит, а если осилит перехватить TLS, то и iD, onanim (?), 22:45 , 03-Сен-23, (268) –1

Не читатель , Tron is Whistling (?), 22:47 , 03-Сен-23, (269) +1

а, точно, перечитал ветку и понял, что фигню написал , onanim (?), 22:48 , 03-Сен-23, (270)

А кто тебе сказал, что в реализации TLS нет закладок , Брат Анон (ok), 09:51 , 05-Сен-23, (299) +1

См выше , Tron is Whistling (?), 09:53 , 05-Сен-23, (300) –1

Это что ж за ЦОД такой Прям интересно стало, у них же пачка разых Tier-ов, ryoken (ok), 17:38 , 02-Сен-23, (101) +1

хер его знает какой там был тогда у AWS - но вышло эпичненько отказ системы рез, пох. (?), 18:31 , 02-Сен-23, (117) –1

Ай красота D, ryoken (ok), 20:21 , 02-Сен-23, (133)
а какого ответа ты, мало обеспеченный гражданин, ждал, если у AWS перед тобой от, Атон (?), 22:31 , 02-Сен-23, (155) –2

ответа ждал _AWS_ от Кумаров копчоных И для них это был вопрос жизни и смерти, , пох. (?), 22:47 , 02-Сен-23, (158) –1

у него по SLA ответственность перед AWS ограничена одним окладом , Атон (?), 09:12 , 06-Сен-23, (319)

А что, так то хороший повод послать поставщика таких систем в ж пу и научиться д, Аноним (-), 04:26 , 03-Сен-23, (201)
Ай, молодца Кумар Показал им всем, что значит ынтырпрайз Всегда смешно когда б, Страдивариус (?), 09:55 , 03-Сен-23, (220)

На виртуалке При штатном обновлении системы с перезагрузкой Раз в полгода год , Аноним (173), 23:43 , 02-Сен-23, (174)

Не дают они зуб У них отказ от ответственности на каждом шагу И возмещение уще, Аноним (179), 00:06 , 03-Сен-23, (179)

Используй USB флешку с первичным ключем, не как лох , bOOster (ok), 07:12 , 03-Сен-23, (209)

ну я ж говорю - для локалхоста зашибись, а представь что у тебя их десятки таких, пох. (?), 10:25 , 03-Сен-23, (224)

Да не, ну подключиться к IPMI, найти-получить нужный ключ и воткнуть - это задач, Tron is Whistling (?), 10:34 , 03-Сен-23, (229)

Т е даже в случае битлохера только ручной ввод Но в целом у нас битлохер только, Tron is Whistling (?), 10:35 , 03-Сен-23, (231)
э вот ты уверен что десяток одновременных эмуляций usb ибо что еще там у теб, пох. (?), 10:52 , 03-Сен-23, (234)

Ну, работает Единственная с этим проблема - доступ операторов к ключам, но это, Tron is Whistling (?), 11:03 , 03-Сен-23, (235)

Тут скорее вопрос, что благонадёжнее - TPM или оператор Мы решили, что оператор, Tron is Whistling (?), 11:06 , 03-Сен-23, (236)

а на хуавеях даже распаянные, onanim (?), 12:12 , 03-Сен-23, (244) +1

Кщастью, этого добра нет и не ожидается , Tron is Whistling (?), 19:12 , 03-Сен-23, (264)

смотря у кого , onanim (?), 22:43 , 03-Сен-23, (267)

хм, они ж вроде отказались вообще вести дело с РФ , пох. (?), 17:18 , 07-Сен-23, (321)

кто они Huawei или казахстанская армянская ООО Точно Не Одноразовая Проксико, onanim (?), 21:56 , 07-Сен-23, (323)

А потом китаец из оченьплохойдороги приедет в армоказахстан для настройки или ре, пох. (?), 22:10 , 07-Сен-23, (324)

ага, недавно на широко известном в узких кругах форуме писали, что новые прошивк, onanim (?), 15:39 , 08-Сен-23, (326)
Пипец мериканскому а так же китайскому шпиену- припрется по дипломатической ви, пох. (?), 15:42 , 08-Сен-23, (327)

Но таки да, желающие скорее всего нароют на любом вендоре , Tron is Whistling (?), 19:13 , 03-Сен-23, (265)

Вообще-то вполне себе распаяный В каждом PCI разъеме, внезапно, есть , Аноним (-), 05:05 , 19-Сен-23, (334)

google dropbear-initramfs, Mr. Cake (?), 13:57 , 03-Сен-23, (252)

ну шо, съэкономили пару мс на паралельном запуске , Ананимаз (?), 12:14 , 02-Сен-23, (10) +9
Что это за шифрование такое, если ключи можно просто попросить у этого TMP, и он, Q2W (?), 12:20 , 02-Сен-23, (11) +4

s TMP TPM , Q2W (?), 12:21 , 02-Сен-23, (12)
Сейчас есть решения без оставления иммобилайзера в машине, Аноним (17), 12:34 , 02-Сен-23, (18)

Если иммобилайзер или блок управления двигателем уже не раздраконили - ключ в лю, bOOster (ok), 07:15 , 03-Сен-23, (210)

например для VAG которые заводят двигатель в ограниченном режиме грется можно, д, анонимоус (?), 08:10 , 12-Сен-23, (330)

Ключ шифрования LUKS по умолчанию хранится на самом диске, добро пожаловать в ре, Аноним (29), 13:18 , 02-Сен-23, (32)

В битлохере оно не просто существует, его надо руками выковыривать , Tron is Whistling (?), 15:12 , 02-Сен-23, (68) –1

Проблемы индейцев шерифа не касаются , Аноним2 (?), 17:50 , 02-Сен-23, (108)

Эти регистры TPM - это как дополнительный слот для пароля в LUKS Именно поэтому, Аноним (82), 15:53 , 02-Сен-23, (82) +1

Почитай про TPM например на хакере Вкратце принадлежит микрософту, делают ерун, Аноним2 (?), 17:54 , 02-Сен-23, (111) +3
ну да или с флэшки, или еще с чего Но разница в том что TPM не должен ничего р, пох. (?), 18:35 , 02-Сен-23, (118) +1

Второй вариант почему-то секурным не выглядит ну вот вообще совсем никак Маркет, Аноним (-), 17:38 , 02-Сен-23, (102) –2

Кто о чем, а мамкины конспирологи о кознях врагофф а это вопрос не к tpm, а, вне, пох. (?), 18:37 , 02-Сен-23, (119) –2

Чушь Доступ к железу - это больше, чем рут Режим восстановления в systemd ту, Аноним (179), 23:46 , 02-Сен-23, (175)

дружище, ты правда не понимаешь, зачем люди используют шифрованные диски нет оп, пох. (?), 00:09 , 03-Сен-23, (180) –3

Я-то понимаю, зачем замки придуманы А вот ты нет Иначе бы ключами не разбрасыв, Аноним (179), 00:12 , 03-Сен-23, (181) +1
Опенсорсная она или дрянь корпоративная - роли не играет Нету у неё пароля от L, Аноним (179), 00:14 , 03-Сен-23, (183) +2

Алё Инициализация не завершена, разделы не примонтированы Какой кто-угодно Ка, Аноним (179), 23:56 , 02-Сен-23, (177)

обычным таким Он тебе и инициализацию завершит, он - может уязвимость именно в , пох. (?), 00:14 , 03-Сен-23, (182)

Вот мы и нашли виноватого Нет, вы , Аноним (179), 00:16 , 03-Сен-23, (184)

Да вот сабж прозрачно намекает Ну то-есть идея хранить ключ локально для того чт, Аноним (-), 04:32 , 03-Сен-23, (203)

Последний раз для совсем полных иди0тов - чип ВНЕЗАПНО не позволил бы им восполь, пох. (?), 10:29 , 03-Сен-23, (226)

В смысле Он его отдает системе для расшифровки диска И хаксору вломившемуся в , Аноним (245), 12:15 , 03-Сен-23, (245)

б-ть, НЕТ - он его выдает твоему т-пому рукoжопoму опенсорсному г-ну, причем так, пох. (?), 14:30 , 03-Сен-23, (254)

Ну как бы фэйл в том что он нахаляву атакующему подмахивает - и вообще не важно , Аноним (-), 12:47 , 05-Сен-23, (306)

и ничего не получится на сем дискуссию и можно считать законченой, возвращайся , пох. (?), 13:57 , 05-Сен-23, (310)

Как так получается, что хранимый ключ сам по себе не зашифрован паролем , Имя (?), 12:29 , 02-Сен-23, (14)

Пароль на пароль Супер, Аноним (17), 12:35 , 02-Сен-23, (20) +1

Про 2FA слышал , Аноним (204), 04:40 , 03-Сен-23, (204) +1

Все вообще не так Суть шифрования с TPM в том, что вместо пароля вы используете, Аноним (29), 13:22 , 02-Сен-23, (34)
Зашифрован Игла кащеева с яйцами Ключ от данных лежит на диске Ключ от ключа на, Tron is Whistling (?), 15:16 , 02-Сен-23, (69) +2

TPM - корпоративная фишка для офиса Для личного использования или в случае особ, Аноним (82), 15:55 , 02-Сен-23, (85)

TPM вообще-то аппаратный бэкдор типа intel me , Аноним (87), 16:07 , 02-Сен-23, (92) +5

Ну это же трастед, ты что, ему не веришь Оно же трастед , Аноним (173), 00:31 , 03-Сен-23, (189) +2

Systemd кидок, Аноним (21), 12:37 , 02-Сен-23, (21) +4
У меня такое чувство, что разработчики линуксов работают на раскалённых клавиат, InuYasha (??), 13:00 , 02-Сен-23, (23) +10

Они просто заблокировали доступ к клавиатуре для своих котов Коты не могут на , Аноним (77), 15:30 , 02-Сен-23, (77)
В вас просто нет конспирологической жилки Неочевидные действия с клавишами это , Аноним2 (?), 17:58 , 02-Сен-23, (113)
Да обычные руки из ж0пы И голова там же И сама эта ж0па - с ушами , пох. (?), 18:41 , 02-Сен-23, (122)

Приматы , Аноним (150), 22:14 , 02-Сен-23, (150)

Вообще-то это осьминоги Но мне портрет модного современного разработчика почему, пох. (?), 22:50 , 02-Сен-23, (159) +1
Нет, хранители , Аноним (259), 17:15 , 03-Сен-23, (259)

А Линукс тут причем Если подстава в модуле от Микрософт, который сводит дисково, Аноним (179), 23:31 , 02-Сен-23, (172) –1

Скрыто модератором, пох. (?), 00:16 , 03-Сен-23, (185)

Скрыто модератором, Аноним (179), 00:22 , 03-Сен-23, (186)
Скрыто модератором, Аноним (179), 00:25 , 03-Сен-23, (187)
Скрыто модератором, Аноним (173), 00:34 , 03-Сен-23, (190)

Это эмоции Спокойнее надо быть Медитация поможет , Аноним (173), 23:50 , 02-Сен-23, (176)

типичный системд, Аноним (24), 13:08 , 02-Сен-23, (24) +1

А что Кто надо всегда должен иметь доступ куда надо Иначе зачем они платят ден, Аноним (27), 13:14 , 02-Сен-23, (27) +1
, Аноним (51), 14:08 , 02-Сен-23, (51)

это была специальная фича, теперь её спалили, но ничего есть ещё , Аноним (28), 13:15 , 02-Сен-23, (28) +8

8212 Ты видишь дыру 8212 Нет 8212 А она есть , Аноним (27), 13:16 , 02-Сен-23, (30) +5

Машка, видал я эту дыру, в которую проваливается пароль в 32 символа да так, что, Аноним (127), 19:14 , 02-Сен-23, (127)

Аппаратные методы защиты оказались ненадёжными, никогда такого не было , Fracta1L (ok), 13:18 , 02-Сен-23, (31) +2

деточка, ты в упор не хоешь видить что ненадежным оказался опять системдрянь, а , пох. (?), 13:24 , 02-Сен-23, (36)

системд вот тебе рут делай , Аноним (21), 13:31 , 02-Сен-23, (41) +5
Не визжи, клован Без ТРМ этой дыры бы не было , Fracta1L (ok), 13:42 , 02-Сен-23, (42)

ага, а без компуктера и тебя бы небыло наверн , Аноним (73), 15:20 , 02-Сен-23, (73) +2

Видеть 8212 Википедияru wikipedia org 8250 ВидетьМеню 171 Видеть 187 82, Аноним (150), 22:15 , 02-Сен-23, (152)
тётенька, аппаратура - это что, богиня и почему в неё надо верить , Аноним (173), 23:27 , 02-Сен-23, (170)
Хранить ключ для расшифровки в аппаратуре и отдавать его каждому встречному на, Аноним (-), 06:59 , 03-Сен-23, (208)

И вот опять Надо просто верить Верить производителю, который прибыль получает К, Аноним (173), 23:23 , 02-Сен-23, (169)

При трукрипте такого не было Ц , InuYasha (??), 13:27 , 02-Сен-23, (38) +3

Самый цимес был в их мануалеЖРаздел- Правдоподобное отрицание наличия скрытого р, Аноннонинмумумус (?), 20:12 , 07-Сен-23, (322)

Скрыто модератором, Аноним (44), 13:58 , 02-Сен-23, (44) –3

Скрыто модератором, Аноним (50), 14:08 , 02-Сен-23, (50)

Скрыто модератором, Аноним (44), 14:09 , 02-Сен-23, (52) –1

Скрыто модератором, Аноним (50), 14:16 , 02-Сен-23, (55)

Скрыто модератором, Аноним (44), 14:27 , 02-Сен-23, (56)

Скрыто модератором, RusFox (?), 14:42 , 02-Сен-23, (57)

Простите, а кто пароль рута то ввёл ctrl-D или введите пароль рута Если знаешь, Аноним (46), 14:04 , 02-Сен-23, (46)

Systemd, получив управление после неудачных попыток ручной разблокировки, не смо, Аноним (49), 14:07 , 02-Сен-23, (49) +5

Да здравствует Systemd , Аноним (50), 14:13 , 02-Сен-23, (54) +6
А каким образом диски разблокируются в этом случае , Вася (??), 14:58 , 02-Сен-23, (60)

TPM далее прочитать не проблема - у загрузочного образа есть к нему доступ и клю, Tron is Whistling (?), 15:04 , 02-Сен-23, (64) +1
Далее, так как информация для расшифровки ключей хранится в TPM, атакующий, сохр, Аноним (65), 15:05 , 02-Сен-23, (65)

я правильно понимаю, что ключ от диска лежит в ТРМ, а ключ доступа к этому ключу, фф (?), 11:40 , 05-Сен-23, (303)

нет, б-ть Еще один феноменально т-пой не смог прочитать статью но ценное мнение, пох. (?), 22:22 , 07-Сен-23, (325)

мда жесть как она есть , Аноним (53), 14:10 , 02-Сен-23, (53) +2

в этом месте все сравнительно правильно сделано - предполагалось, что это случай, пох. (?), 14:54 , 02-Сен-23, (58)

Всё там неправильно Хочешь починить повреждённый насмерть диск - переключай бут-, Tron is Whistling (?), 15:03 , 02-Сен-23, (63)

это вот на современном сервере может у тебя не очень получиться , пох. (?), 15:20 , 02-Сен-23, (72) –1

Ты из адептов облаков штолле , Аноним (73), 15:24 , 02-Сен-23, (75) –1

каких нахрен облаков Чтоб загрузиться с чего-то левого такому серверу нужно пом, пох. (?), 18:47 , 02-Сен-23, (125)

Бггггггг Ну, за причины, предпосылки и последствия ничего говорить не буду - всё, Tron is Whistling (?), 14:57 , 02-Сен-23, (59)

Хороший пример чего , Аноним (73), 15:25 , 02-Сен-23, (76)

Того, что TPM - это дыра, которая не имеет по факту никакой валидации и может бы, Tron is Whistling (?), 21:37 , 02-Сен-23, (146)

Никакого _обхода шифрования_ нет в помине Есть получение root консоли и выкачива, birdie (ok), 15:06 , 02-Сен-23, (66) +3

Что значит непонятно У нас _подписанный_ загрузочный образ, который может TPM чи, Tron is Whistling (?), 15:17 , 02-Сен-23, (70)

а к этому моменту он прошёл и проверку подписи, и measured boot - и вся эта шля, Tron is Whistling (?), 15:20 , 02-Сен-23, (71) +2
там даже догадываться незачем - автор оставил детальную инструкцию что за чем на, пох. (?), 15:23 , 02-Сен-23, (74)
Это если ключ шифрования хранится в TPM Атака _не_ на шифрование, а на _кривой , birdie (ok), 15:54 , 02-Сен-23, (83) +3

Ну я только за TPM и вещаю Уже достаточно К счастью да - нас это даже потенциал, Tron is Whistling (?), 21:39 , 02-Сен-23, (147)

Вот тебе и SystemD, Аноним (67), 15:11 , 02-Сен-23, (67)

Поправил, не благодари, Shevchuk (ok), 21:22 , 02-Сен-23, (141)

Очередная сферическая уязвимость в вакууме А TPM в принципе не нужен и является, Аноним (87), 15:52 , 02-Сен-23, (81) +5

Не, TPM полезен вообще-то, но в ограниченном количестве случаев и не должен пред, Аноним (82), 16:15 , 02-Сен-23, (94)
TPM не может быть бекдором, так как не умеет активно влиять на вычислительные пр, Аноним (199), 03:29 , 03-Сен-23, (196) –1

кому попало И по случайному совпадению - упал на мой кулак 5 раз подряд, тьф, Аноним (-), 07:19 , 03-Сен-23, (212) +3

Как политика настроена, тому и выдаётся Можно и кому попало, а можно только в с, Аноним (199), 23:39 , 03-Сен-23, (272)

Во этом всем я вижу как минимуму 1 небольшой нюанс вроде бы ниоткуда не следует, Аноним (-), 13:21 , 05-Сен-23, (307)

Представь себе железку, которая висит на линии reset и умеет один раз за загрузк, Аноним (199), 01:11 , 04-Сен-23, (276)

А зачем на линии Reset то Ну вот тут уже сложнее Особенно если что-то типа дифф, Аноним (-), 13:37 , 05-Сен-23, (308)

не гони на secure boot, он-то как раз - дар богов а остальное - да, бэкдоры , onanim (?), 12:16 , 03-Сен-23, (246)

Secure boot абсолютно бесполезен Того же уровня безопасности можно достичь, про, Аноним (199), 00:47 , 04-Сен-23, (274)

Попробуйте выключить Secure Boot на моём enterprise ноуте Раньше теплового конц, Аноним (301), 11:03 , 05-Сен-23, (301)

Потом вылезет какой-нибудь vendor cmd который делает невозможное за 10 секунд , Аноним (-), 13:39 , 05-Сен-23, (309)

если заблокирован ключ к зашифрованному, то зашифрованное не зашифровано, а забл, Аноним (77), 16:13 , 02-Сен-23, (93) +5

Корень в том что никто не любит тех кто шифруется и на них всегда методы найдутс, Аноним (27), 16:44 , 02-Сен-23, (96) –2

Это как-то называется другими выражениями , Аноним (150), 22:24 , 02-Сен-23, (153)
никто это кто ты щас пишешь на сайте через https, но не люблю я тебя только за , Вася (??), 23:07 , 02-Сен-23, (165)

Абсолютно да И железка по превращению одного в другое называется TPM Я это некот, Tron is Whistling (?), 21:40 , 02-Сен-23, (148)

Либо ты держишь пароль в голове, либо не морочишь себе голову и не страдаешь фиг, YetAnotherOnanym (ok), 17:01 , 02-Сен-23, (97) +4

Пароль можно забыть, вот у меня было парочку архивов начала 2000-х, год назад я , BeLord (ok), 13:27 , 04-Сен-23, (288)

При этом помимо автоматизированной разблокировки в подобных системах остаётся и , Аноним (100), 17:35 , 02-Сен-23, (100)

По какой методике ты собираешься это проверять что если и после Или гуманитарий, Аноним (27), 17:55 , 02-Сен-23, (112)

пф bin shif decrypt_automatic --please then decrypt_manual --hulefi, фф (?), 11:47 , 05-Сен-23, (304)

Патамушта у нас же ж системдрянь заботится об очень-очень-быстрой загрузке и все, пох. (?), 18:50 , 02-Сен-23, (126)

Зачем же так сразу - в петлю , Аноним (241), 11:47 , 03-Сен-23, (241)

Это какой-то позор , Ананоним (?), 17:42 , 02-Сен-23, (104) +4

Не прокатило, вычёркиваем Да вы правы , Аноним (27), 17:52 , 02-Сен-23, (110) +1

Не баг а фича - Леннарт Пёттеринг , Аноним (123), 18:43 , 02-Сен-23, (123) +2
Скрыто модератором, Аноним (-), 18:44 , 02-Сен-23, (124)
Любопытно смотреть на любителей шифрования когда у них начинается сыпаться диск , Аноним (128), 19:50 , 02-Сен-23, (128) +1

Если удалось примонтировать, то какая разница , Вы забыли заполнить поле Name (?), 20:01 , 02-Сен-23, (130)
Еще интереснее смотреть на ваши студенческие сборки дистрибутивов -- 20 лет ИТ в, Аноним (131), 20:06 , 02-Сен-23, (131) –1

128522 Прекратите Они серьёзно думают, что занимаются серьёзным делом типа в, Аноним (150), 22:28 , 02-Сен-23, (154)

Бекапы же есть, Q2W (?), 20:25 , 02-Сен-23, (134) +2
Есть два типа людей те, кто не делает бэкапы, и те, кто уже делает , Shevchuk (ok), 21:28 , 02-Сен-23, (142)

Вообще-то три Люди делятся на три категории те кто ещё не делает резервные ко, Аноним (149), 22:08 , 02-Сен-23, (149)

Это подкатегория вторых, Shevchuk (ok), 04:52 , 03-Сен-23, (205)

А, современные SSD всё равно сыпаться умеют так, что с них хоть с шифрованием, х, Tron is Whistling (?), 22:15 , 02-Сен-23, (151) +2
raid 1 или бекапы, что же выбрать да какая разница, оба варианта отлично помо, Вася (??), 22:55 , 02-Сен-23, (161)

Эпический С , _ (??), 06:52 , 05-Сен-23, (298)

Любопытно смотреть на мненечегоскрывателей, когда у них крадут ноут со всей их л, Аноним (241), 11:45 , 03-Сен-23, (240)
Любопытно смотреть на администраторов локалхоста, которые в жизни не работали в , Perlovka (ok), 23:18 , 03-Сен-23, (271)

Это вообще законно , Аноним (173), 23:11 , 02-Сен-23, (167)

Это деяние, хотя и предусмотренное Уголовным кодексом, все же имеет невинный ви, YetAnotherOnanym (ok), 07:16 , 03-Сен-23, (211)

Да как так-то Вот надо таки было использовать FreeBSD или OpenBSD Там такой фи, Аноним (173), 23:18 , 02-Сен-23, (168) –2

в смысле нет я так рутовский пароль и на фри и на опен восстанавливал , фф (?), 11:51 , 05-Сен-23, (305)

Корень всех проблем, torvn77 (ok), 02:12 , 03-Сен-23, (192)

bin sh лучше , Аноним (241), 11:39 , 03-Сен-23, (238)

Зачем sh если есть sysVinit , torvn77 (ok), 13:15 , 04-Сен-23, (286)

https www opennet ru openforum vsluhforumID3 131398 html 237, Аноним (241), 11:39 , 03-Сен-23, (239)

Тем не менее решение о предоставлении локального доступа без предоставления паро, torvn77 (ok), 13:19 , 04-Сен-23, (287)

Дать рута не спрашивая пароля рута SystemDегиниально , Аноним (202), 04:28 , 03-Сен-23, (202) +1

Ты вообще понимаешь о чём говоришь, гений Как устроен процесс загрузки ядра Чт, Аноним (241), 11:37 , 03-Сен-23, (237)

А теперь внимательнее почитай эту функцию Там выше запускается init из initram, Аноним (199), 01:05 , 04-Сен-23, (275)

Это не функция, а ленивое выражение Если часть выражения, которая вызывает функ, Аноним (179), 11:38 , 04-Сен-23, (280)

Да Это ленивое выражение находится внутри функции kernel_init, которая вызыва, Аноним (199), 19:26 , 04-Сен-23, (294)

Которая тоже строка, содержащая путь init , если не установлен другой , по ко, Аноним (312), 14:16 , 05-Сен-23, (312)
А ты вообще не замечаешь, как ловко у M всё выходит В рекламных буклетах M тип, Аноним (312), 15:01 , 05-Сен-23, (313) –1
И в догонку Почему логика про кривой Линукс и сам настроил, сам виноват не р, Аноним (312), 15:12 , 05-Сен-23, (314)

А при испорченном контролируемо диске мы тоже получим режим восстановления с р, Аноним (206), 05:10 , 03-Сен-23, (206)

_якобы_ наши средства шифрования не позволяют диск испортить контролируемо если, пох. (?), 10:34 , 03-Сен-23, (230)

Я имел в виду немного другое т к у нас подключается USB-брелок, то физический , Аноним (206), 17:34 , 03-Сен-23, (261)

дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть ди, пох. (?), 23:03 , 05-Сен-23, (315)

Вариант с мелкой флешкой конечно удобней, безусловно, просто описание уязвимос, Аноним (206), 05:39 , 06-Сен-23, (318)

дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть ди, пох. (?), 23:03 , 05-Сен-23, (316)

Шифрование с тпм это шифрование просто от детей, не более , Аноним (213), 08:54 , 03-Сен-23, (213) –1

Для детей и пароля на биос с загрузчиком хватит Или просто кабель питания унест, Аноним (199), 01:13 , 04-Сен-23, (277)

Это у тебя ещё маленькие дети , 1 (??), 15:54 , 04-Сен-23, (290) +2

не достают с пола до клавиатуры на столе,угу, пох. (?), 23:04 , 05-Сен-23, (317)

Пишите правду в заголовке что systemd виновато , Аноним (250), 13:06 , 03-Сен-23, (250) +2

systemd linux тогда уж у нас есть и другой линукс, в нем нет этой уязвимости, н, пох. (?), 14:34 , 03-Сен-23, (255)

к счастью, полно линуксов и без systemd помимо этого вашего ведра , Аноним (302), 11:18 , 05-Сен-23, (302)

с тем же успехом ты мог бы вспомнить netbsd, или вовсе там ресдох Но есть один н, пох. (?), 14:02 , 05-Сен-23, (311)

Держите компы в сейфе, а питание осуществляйте методом электромагнитной индукции, Аноним (256), 14:45 , 03-Сен-23, (256)

Через вал мотор-генератора будет практичнее , torvn77 (ok), 13:13 , 04-Сен-23, (285)

Насколько помню, у контроллера клавы задерка 25 мс , pavlinux (ok), 15:24 , 03-Сен-23, (257) –2

У USB HID такой задержки нет Стандартная частота поллинга EP - 125 Гц, что даст, Аноним (199), 01:23 , 04-Сен-23, (278) +1

Я так понимаю, что если настроен ввод PIN дополнительно, то эту атаку нельзя про, Аноним (281), 11:53 , 04-Сен-23, (281)
хех, сделали race condition, молодцы , Golangdev (?), 11:58 , 04-Сен-23, (282)
Раньше считалось что если зажать энтер то система быстрее грузится, Аноним (289), 14:01 , 04-Сен-23, (289)
А почему, интересно, загрузка с левой железякой считается за measured boot , Алексей (??), 20:37 , 09-Сен-23, (328)

потому что эта железяка кого надо железяка, onanim (?), 10:28 , 10-Сен-23, (329)

ДВА параллельных процесса разблокировки Ты действовал наверняка, да , Пряник (?), 09:37 , 18-Сен-23, (333) +1

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

1. Скрыто модератором –4 +/–

Сообщение от Аноним (1), 02-Сен-23, 12:01

В bitlocker такого позорища никогда не было

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

8. Скрыто модератором +9 +/–

Сообщение от Аноним (8), 02-Сен-23, 12:12

> В bitlocker такого позорища никогда не было
Шутишь? Там всё гораздо запущеннее:
https://support.microsoft.com/en-us/topic/kb5025175-updating...
https://msrc.microsoft.com/en-US/security-guidance/advisory/...
https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
https://blog.f-secure.com/cold-boot-attacks/
https://secret.club/2021/01/15/bitlocker-bypass.html

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

33. Скрыто модератором +1 +/–

Сообщение от пох. (?), 02-Сен-23, 13:19

>> В bitlocker такого позорища никогда не было
> Шутишь? Там всё гораздо запущеннее:
только в воображении л@п4тоужаленных
> https://support.microsoft.com/en-us/topic/kb5025175-updating...-
уязвимость в winRE. Надо быть админом и знать пароль. И еще и иметь RE, конечно же на нешифрованном разделе.
> https://msrc.microsoft.com/en-US/security-guidance/advisory/...
Уязвимость в конкретных чипах infineon
> https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
та же самая уязвимость в winRE
> https://blog.f-secure.com/cold-boot-attacks/
FUD от известных врунишек
> https://secret.club/2021/01/15/bitlocker-bypass.html
единственная серьезная проблема, впрочем автор _крайне_ мутен в том месте где доходит до выполнения собственно экзешника - предлагается его скачать бесплатнобезсмс.
Используется целый набор странных фич, включая средства для альтернативно-одаренных (ох как же я люблю эту заботку об инвалидиках пихаемую без разбора всюду и везде) и восстановления продолбанных паролей (да, безусловно было бы прекрасно их не иметь вовсе - ну вот как у вас, л@п4тых - продолбал пароль - прощайся с диском). При этом MS как-то вот не уверена что и это реализуемо не в лабораторных условиях.
Ну и рекомендация оверрадить настройки logon screen таки была нелишней.
Разумеется, это то же самое, что просто быстро-быстро понажимать space и ой, я рут.

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

3. "Обход полнодискового шифрования в Linux через непрерывное на..." +19 +/–

Сообщение от Аноним (3), 02-Сен-23, 12:02

В чём смысл TPM, если с его помощью система просто загружается без ввода пароля?

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

4. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (8), 02-Сен-23, 12:04

Не взломав систему, не получишь доступ к данным на диске. Если просто вынуть диски, данные не извлечь.

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

7. "Обход полнодискового шифрования в Linux через непрерывное на..." +7 +/–

Сообщение от Аноним (7), 02-Сен-23, 12:11

Сломалась материнка - прощай инфа на диске?

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

9. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (8), 02-Сен-23, 12:13

> Сломалась материнка - прощай инфа на диске?
На этот случай есть пароль для ручной разблокировки.

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

78. "Обход полнодискового шифрования в Linux через непрерывное на..." +9 +/–

Сообщение от bergentroll (ok), 02-Сен-23, 15:36

«На этот случай у меня есть проездной!»

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

87. "Обход полнодискового шифрования в Linux через непрерывное на..." +3 +/–

Сообщение от Аноним (87), 02-Сен-23, 15:58

Тогда в чём смысл TPM?

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

103. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (-), 02-Сен-23, 17:42

> Тогда в чём смысл TPM?
Ну как, без него атакующий в систему не попал бы. Бэкдор успешно выполнил свою функцию, предоставив ключ атакующему :)))

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

136. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от Shevchuk (ok), 02-Сен-23, 20:38

В том, чтобы не быть ограниченным _только_ ручным вводом.
Да-да, в свете этой новости: "ну как поплавали?" Речь об идее.

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

17. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (17), 02-Сен-23, 12:32

Почему?
Если я их в другой системе попробую примонтировать,
появится диалог ввода пароля. Если знаете пароль, вводите

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

132. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Dmitry22333 (ok), 02-Сен-23, 20:11

я слышал что была такая игра, там штангист поднимает штангу, и чем чаще нажимается Enter тем больший груз он поднимает :)
а если с USB брелком как описан в посте - можно будет тонны поднимать одной рукой :)

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

217. "Обход полнодискового шифрования в Linux через непрерывное на..." +3 +/–

Сообщение от Страдивариус (?), 03-Сен-23, 09:49

> Если просто вынуть диски, данные не извлечь.
А нельзя, вынув диск, подключить в материнку свой диск, загрузиться с рутом и просто извлечь из TPM ключи и потом расшифровать вынутый диск?
Я не понимаю модель нарушителя, для которого эта затея сделана.

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

291. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от погроммист (?), 04-Сен-23, 16:41

> Не взломав систему
Ну т.е. если не брать всякую биометрию, то всё равно пароль нужно вводить, просто позже -- на этапе login manager-а.

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

6. "Обход полнодискового шифрования в Linux через непрерывное на..." +14 +/–

Сообщение от Аноним (-), 02-Сен-23, 12:09

> В чём смысл TPM, если с его помощью система просто загружается без ввода пароля?
В данном случае видимо наглядное демо что удобство и безопасность живут по разные стороны улицы. Вы хотели автторазблокирование? Ну вот атакующий его оказывается тоже сможет. Удобно же!

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

29. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (29), 02-Сен-23, 13:15

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

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

43. "Обход полнодискового шифрования в Linux через непрерывное на..." –4 +/–

Сообщение от pic (?), 02-Сен-23, 13:48

Обычный слесарный молоток решает эту проблему.

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

98. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (-), 02-Сен-23, 17:21

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

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

295. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от АнонимПротивЦензуры (?), 04-Сен-23, 20:55

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

А брелок с ключом от диска требует ещё и пароля.

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

16. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (16), 02-Сен-23, 12:31

TMP полная чушь. Гораздо надежнее использовать флешку для хранения ключей. Вынул флешку - нет ключа. Вставил - есть ключ. А TMP вынуть нельзя если заходел отдать комп в сервис. Так что TMP полная чушь.

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

26. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (29), 02-Сен-23, 13:10

Использую аппаратный TPM, его можно вынуть. Гребенка под него есть практически на любой современной, и не очень, плате.

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

105. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от Аноним2 (?), 02-Сен-23, 17:42

Почитай что такое TPM. Это лютая дичь с security through obscurity. В первой версии вообще детские нелепости были(бэкдоры?), во второй таких критичных пока не обнаружено, но пользоваться такой технологией это как доверить деньги жулику.

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

207. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (207), 03-Сен-23, 05:15

Почитай, что такое descrete TPM. Можешь заодно погуглить картинки и почитать про материнки с TPM header-ом.
Впрочем, у dTPM есть свои проблемы: к нему, в отличии от fTPM (firmware TPM) можно подцепить на контакты осциллограф и считать, что он за данные у него там на шине летают.

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

296. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от АнонимПротивЦензуры (?), 04-Сен-23, 20:59

а встроенное шифрование в диск вставить фбр не разрешило

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

173. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (173), 02-Сен-23, 23:36

TPM - гoвнo. Бай дезигн.

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

39. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 13:29

Ну вот утром был сбой системы защиты электропитания в DC, она защитила электропитание, отрубив его сама. Езжай, милок, в свой выходной, за 20 километров - флэшки вставлять будешь.
И побыстрее, бузинесс уже недовольство выразил.

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

61. "Обход полнодискового шифрования в Linux через непрерывное на..." +3 +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 15:00

IPMI с удалённым экраном и флешкой и пароль - лучше ещё не придумано.

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

107. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Тот самый (?), 02-Сен-23, 17:49

>лучше ещё не придумано.
Открой для себя Tang. Жизнь с шифрованными томами в ЦОДе станет существенно легче.
Кстати, Clevis умеет брать ключи в т.ч. из Tang и в этом случае описанная уязвимость не сработает.

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

137. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Shevchuk (ok), 02-Сен-23, 20:54

Причём ключ никогда не покидает машину, на которой он используется для расшифровки. Но при этом без помощи внешнего сервера Tang и сама эта машина ключ не может использовать, принципиально. Довольно остроумная система.
- https://youtu.be/Dk6ZuydQt9I
- https://youtu.be/v7caQEcB6VU

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

144. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 21:33

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

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

195. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Тот самый (?), 03-Сен-23, 02:39

>базовые ключи автоматически по сети ходить не должны
Ты так и не понял, что такое Tang.

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

199. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (199), 03-Сен-23, 04:02

Как этот Tang проверяет, что злодей не пересобрал initramfs, вставив туда дамп и отправку ключа шифрования после того, как диск расшифровался?

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

216. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 09:48

Да никак, плюс всё это автоматизировано - и фиг отследишь, когда утекло.

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

116. "Обход полнодискового шифрования в Linux через непрерывное на..." –2 +/–

Сообщение от пох. (?), 02-Сен-23, 18:26

> IPMI с удалённым экраном и флешкой и пароль - лучше ещё не
> придумано.
ты вот пробовал это в рамках хотя бы первых сотен коробок? Уверяю тебя, быстро расхочется использовать для любой сколько нибудь массовой деятельности.
Штатная перезагрузка ТОЛЬКО с ipmi - Б-же сохрани от такого.

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

143. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 21:31

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

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

160. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Вася (??), 02-Сен-23, 22:53

cryptsetup-initramfs + dropbear ssh = <3

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

171. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от penetrator (?), 02-Сен-23, 23:28

а что это за система у тебя такая, что требует FDE эндпоинтов так еще кластер на несколько сотен машин, где нет администратора готового ОТВЕЧАТЬ ЗА ОБНОВЛЕНИЕ И ПЕРЕЗАГРУЗКУ НОД? да еще и доступ только удаленный?

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

178. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 03-Сен-23, 00:05

от давай ты и будешь таким администратором. А мы поржем с безопасного расстояния.

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

335. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от count0 (ok), 19-Сен-23, 18:16

Я хочу опыт в ЦОД. Сколько ЗП, какой город?

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

336. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 20-Сен-23, 13:46

> Я хочу опыт в ЦОД. Сколько ЗП, какой город?
TLV
норм там зарплата. Но этот ЦОД принадлежит ש.ב. а они понаехов не берут. Пол-года не могли вакансию закрыть (страна понаехавших потому что)

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

106. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним2 (?), 02-Сен-23, 17:48

Скажу больше - если серверов 1000+ такое происходит каждый день, но даже с физическим размещением никто никуда не едет, благо на всех интерпрайзных серверах есть ipmi. Поводов съездить в цод три: поставить новый сервер, заменить старый, на главную сетевую железку упал метеорит. Первые два делаются в будни и за раз.

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

114. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от пох. (?), 02-Сен-23, 18:20

> Скажу больше - если серверов 1000+ такое происходит каждый день
вряд ли ты можешь похвастаться 1000+ шифрованных серверов.
> благо на всех интерпрайзных серверах есть ipmi
и толку-то с него? Ты в самом деле работал в конторе с первой тысячей серверов? Пусть даже нешифрованных.
(вопрос риторический, очевидно что нет)

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

145. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 21:35

Ну будем честными: _шифрованных_ серверов обычно столько и не надо.

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

157. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 22:43

ну хз что там у какого-нибудь протона.
Но мне бы хватило вот просто тыщи серверов с ipmi. Не в том смысле что без него лучше, а в том что ipmi - это на совсем уж крайний случай, непосредственно перед поездкой на предмет выковыривания сдохшего уже напрочь сервера из стойки. Когда стандартный "reboot/reinstall" уже не помог.
А не на каждой перезагрузке, упаси Г-дь.

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

218. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 09:51

А фирмварь на хардварных нодах вообще не обновляете? Без IPMI этот процесс выглядит совсем тоскливо.

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

222. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от пох. (?), 03-Сен-23, 10:19

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

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

225. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 10:29

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

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

227. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 10:30

(у нас нет тысячи нод, но я так прикидываю - сотен 5 за день окучить вполне реально, это даже если надо все разом)

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

228. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 10:32

Тыщи нод у нас так-то реально только у гугла и прочих мажоров, но там и землекопов не 2-3.

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

232. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от пох. (?), 03-Сен-23, 10:42

да ладно тебе, какой гугль... мелкая конторка в которой я имел сомнительное щастье работать в еще 2010м, и та имела больше полутыщи корытцев. (правда, гугль нас таки пытался купить, но ему не продали)
Землекопов было не 2-3, а полтора десятка, но у них своих дел хватало, и идея потрахаться вручную с ipmi с конкретным тазом никогда и ни у кого там восторга не вызывала, а уж тем более прокатиться к месту событий самому. К счастью, в большинстве случаев наши системы либо все же после некоторых уговоров перезагружались автоматикой, и в крайнем случае их так же автоматом можно было переустановить, либо их перезагружал самоходный агрегат, прикованный там, между стоек, правда, по дороге обязательно выдернув пару кабелей и в итоге перезагрузив не то.
А те уникальные с которыми так было нельзя - мы все дружно ненавидели.

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

233. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 10:45

Ну, сейчас корытца стали пожирнее, и их реально поубавилось - ледники надо беречь...

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

338. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от count0 (ok), 20-Сен-23, 13:56

> А те уникальные с которыми так было нельзя - мы все дружно
> ненавидели.
Скажите, которые нужно ненавидеть и не покупать. А то вдруг попросят подсказать что выбрать, и будут и меня потом, заодно ))
ВК слышал у Минпромторга или Минцифры просил достать им 10к серверов в прошлом году. Мол никто не продаёт. Значит у них 10-ки тысяч их стоит.

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

342. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 20-Сен-23, 14:44

>> А те уникальные с которыми так было нельзя - мы все дружно
>> ненавидели.
> Скажите, которые нужно ненавидеть и не покупать. А то вдруг попросят подсказать
речь о сетапах, а не серверах. Иногда на сервере стоит что-то такое что его нельзя перезагружать ресетом и запускать без контроля. И даже если их таких один из сотни - каждая вынужденная перезагрузка превращается в адов гемор.
> ВК слышал у Минпромторга или Минцифры просил достать им 10к серверов в
> прошлом году. Мол никто не продаёт. Значит у них 10-ки тысяч
> их стоит.
может они просто решили что они же и продадут.
Но в общем-то Вк - это "облако мэйлру" в том числе. А там - "фсе одинаковые" и перезагрузка ресетом норм - подумаешь, твоя виртуалка (за 2k/мес между прочим) тоже ресетнулась при этом - куда ты с подводной-то лодки денешься? Одноглазнеки облачковых услуг пока не продают-с.

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

343. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от count0 (ok), 20-Сен-23, 14:46

> Но в общем-то Вк - это "облако мэйлру" в том числе. А
> там - "фсе одинаковые" и перезагрузка ресетом норм - подумаешь, твоя
> виртуалка (за 2k/мес между прочим) тоже ресетнулась при этом - куда
> ты с подводной-то лодки денешься? Одноглазнеки облачковых услуг пока не продают-с.
Видимо поэтому и придумали CI/CD, чтобы не обращать внимание на падения железа, размазанного по датацентрам.

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

344. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 20-Сен-23, 14:52

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

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

345. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от count0 (ok), 21-Сен-23, 23:02

> угу. А потом такие - ой, транзакция потерялась. (или раздвоилась, что еще
> забавнее).
> А на деле все эти придумки для тех кто кроме "Приложениев" и
> "финтеха" (торговли фантиками а не того что некоторые могли подумать) ничего
> не производит. Ну и еще рекламных баннеров. Подумаешь, пара кликов пропала.
> Зато конь-тиниоус дезинтеграция. Кому и нах-я она нужна - никто не знает
> но все уверены.
Чтобы не потерялась - проверяет скрипт на стороне клиента (не получил от сервера - форма пришла / билет продан / бабки переведены - пишем "Ой, что-то пошло не так, обновите страницу").
Чтобы не раздвоилась - есть номера транзакций. И задержки на повторную отправку. Например человек за 0.5 секунды 2 раза отправить не нажмёт. А если нажмёт - отбросить или вывести предупреждение, чтобы пыл умерил ))
Всё решаемо, это ж погромисты )) Получат по шапке пару раз - пофиксят ))

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

109. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от ivan_erohin (?), 02-Сен-23, 17:50

> Езжай, милок, в свой выходной, за 20 километров - флэшки вставлять будешь.
за 7000 руб/час вообще без проблем (оплачиваемое время включает поездку
до места и работу до результата "все завелось", поездка обратно за свой счет).
если кто не доверяет, то пусть ставит дизель в свой "датацентр класса А"
(или как там класифицируются помойные датацентры).

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

115. "Обход полнодискового шифрования в Linux через непрерывное на..." –2 +/–

Сообщение от пох. (?), 02-Сен-23, 18:24

>> Езжай, милок, в свой выходной, за 20 километров - флэшки вставлять будешь.
> за 7000 руб/час вообще без проблем (оплачиваемое время включает поездку
Какой дешовый раб...
> если кто не доверяет, то пусть ставит дизель в свой "датацентр класса
> А"
дык был дизель. Не очень помогает - когда выходит из строя система которая должна управлять в том числе и теми дизелями. Вон поищи историю эпик фейла AWS.
Даже двухлучевое подключение иногда не спасает от таких подарочков. (при том что не у всякой железки вообще в принципе есть второй блок питания в штатном комплекте)

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

129. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от ivan_erohin (?), 02-Сен-23, 20:00

>> 7000 руб/час
> Какой дешовый раб...
окей, назови свою цену. особо сложной работы там не будет,
вставил-вынул и бежать.
>> если кто не доверяет, то пусть ставит дизель в свой "датацентр класса
>> А"
> дык был дизель. Не очень помогает - когда выходит из строя система
> которая должна управлять в том числе и теми дизелями.
и дизель и систему надо иногда проверять (от "раз в квартал" до "раз в месяц" в зависимости от обстановки). чтобы контакты не закисали и топливо не расслаивалось.

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

163. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 23:03

>>> 7000 руб/час
>> Какой дешовый раб...
> окей, назови свою цену. особо сложной работы там не будет,
удовольствие от посещения гермозоны и пребывания в ней несколько часов к ряду - просто бесценно. Как и от поездки туда где они обычно имеют свойство находиться, впрочем на фоне ЧАСОВ внутри - а когда происходит массовый электрофакап это всегда часы - цветочки.

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

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

200. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (200), 03-Сен-23, 04:20

>> за 7000 руб/час вообще без проблем (оплачиваемое время включает поездку
> Какой дешовый раб...
Что смотришь, HR'у звони! Поделите премию на двоих, нормуль :)
> дык был дизель. Не очень помогает - когда выходит из строя система
> которая должна управлять в том числе и теми дизелями. Вон поищи
> историю эпик фейла AWS.
А может, состояние систем мониторить надо и резервировать стоит еще и системы управления? Ах, пиитоняшам "х..к, х..к и в продакшн" про это не рассказывали?
> Даже двухлучевое подключение иногда не спасает от таких подарочков. (при том что
> не у всякой железки вообще в принципе есть второй блок питания
> в штатном комплекте)
Ну вот _иногда_ человечек может смотаться в ДЦ и - все пофиксить. Вопрос в том насколько часто это случается. Раз в полвека - можно даже и телескоп на орбите обслужить, как показала практика.

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

223. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 03-Сен-23, 10:23

>>> за 7000 руб/час вообще без проблем (оплачиваемое время включает поездку
>> Какой дешовый раб...
> Что смотришь, HR'у звони! Поделите премию на двоих, нормуль :)
а он точно не подставит меня так со своими подходами, что МНЕ придется тоже звиздовать?
Я две премии отдам чтоб этого не делать!
> А может, состояние систем мониторить надо и резервировать стоит еще и системы
> управления? Ах, пиитоняшам "х..к, х..к и в продакшн" про это не
э... это вот как ты себе представляешь в случае - системы управления питанием dc  ?
> Ну вот _иногда_ человечек может смотаться в ДЦ и - все пофиксить.
идите нафиг с вашим иногда.
> Вопрос в том насколько часто это случается. Раз в полвека -
> можно даже и телескоп на орбите обслужить, как показала практика.
можно, но рабов лучше где-нибудь в индии для этого наловить.

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

242. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (-), 03-Сен-23, 12:04

> а он точно не подставит меня так со своими подходами, что МНЕ
> придется тоже звиздовать?
Можно деловое предложение в договор вписать: если не справился то получает 0, и джекпот переходит следующему кандидату. Отличный стимул работать без подстав между прочим :)
> Я две премии отдам чтоб этого не делать!
Фига ты щедрый, а зачем тогда на работу ходишь? Уволился или хотя-бы взял за свой счет весьма расширенный отпуск, свалил куда подальше, радостно машешь всем факом, они тебя в датацентр не вынут хоть там как, особенно если мобильник в речке утонет или связи в перди нет, за пару месяцев то можно хоть на северный полюс слиться.
> э... это вот как ты себе представляешь в случае - системы управления
> питанием dc  ?
Ну вот так, как и в системах управления космического корабля. Вплоть до выбора 2 из 3 при решении чего делать на самом деле. А какие проблемы?
>> Ну вот _иногда_ человечек может смотаться в ДЦ и - все пофиксить.
> идите нафиг с вашим иногда.
Да ладно, раз за срок службы телескопа нормально, даже на орбите. Главное чтоб не сильно чаще. Ну, фак, мне пришлось вот в пердях резко карты в одноплатниках менять пару раз бросив все. С тех пор пришлось подтянуть скилл чтобы больше они от 1 бэда под системной либой не дохли. Зато преимущество над раджами появилось.
>> можно даже и телескоп на орбите обслужить, как показала практика.
> можно, но рабов лучше где-нибудь в индии для этого наловить.
Ээээ может им еще и на орбиту доставку бесплатную? Да тфу на тебя - Маск и даже NASA их еще на несколько миллионов за доставку разведет, ведь звание астронавта - звучит гордо. А у индии их не так уж много. Где твоя деловая хватка?! Слить даже насе - ну это уж вообще!

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

247. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Anon3 (?), 03-Сен-23, 12:18

> пох: дык был дизель. Не очень помогает - когда выходит из строя система которая должна управлять в том числе и теми дизелями. Вон поищи историю эпик фейла AWS.
> пох: Даже двухлучевое подключение иногда не спасает от таких подарочков. (при том что не у всякой железки вообще в принципе есть второй блок питания в штатном комплекте)
>>  ivan_erohin: А может, состояние систем мониторить надо и резервировать стоит еще и системы управления? Ах, пиитоняшам "х..к, х..к и в продакшн" про это не рассказывали?
> пох: э... это вот как ты себе представляешь в случае - системы управления питанием dc?
Ну вообще, то каждая ветвь электропитания имеет свою собственную независимую схему управления (для ДЦ - две от двух независимых сетей + при желании дизель (первая категория надежности электроснабхения)) и каждая из них мониторит соседние по принципу watchdog-a.
Просто на практике обычно приходят продаваны, к примеру от Siemens-а, весь бюджет тратят на оборудование этого самого Siemens-а, где основную часть стоимости составляют откаты лицам принимающим решения. В итоге все оказывается подключенным к одному единственному контроллеру Siemens-а, а главный энергетик это подписывает, потому что на работу нигде не берут, а до пенсии остался один год работы

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

339. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от count0 (ok), 20-Сен-23, 14:05

> Просто на практике обычно приходят продаваны, к примеру от Siemens-а, весь бюджет
> тратят на оборудование этого самого Siemens-а, где основную часть стоимости составляют
> откаты лицам принимающим решения. В итоге все оказывается подключенным к одному
> единственному контроллеру Siemens-а, а главный энергетик это подписывает, потому что на
> работу нигде не берут, а до пенсии остался один год работы
Читал историю ТуТу.ру и их общение с датацентрами. В-общем надо резервироваться в Разных датацентрах (от разных фирм) )) И ещё там про тёмную оптику было.
У них был случай, что п*зданулось питание где-то, и местный чел, который к стойкам прикован, или электрик, дёрнул в итоге и 2е питание ))) На несколько часов всё погасло ))
А ещё Датацентр может внезапно... Переехать! Потому что из-под него недвижку выдёргивают. И вам 3 дня на сборы, можете вот по этому новому адресу всё перевезти.

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

292. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от погроммист (?), 04-Сен-23, 16:43

Под ssh ключи tpm вполне годится. Лучше, чем голый ключ на диске.

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

86. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (87), 02-Сен-23, 15:56

> В чём смысл TPM, если с его помощью система просто загружается без ввода пароля?
Ты сам ответил на свой вопрос. Нет видимого смысла, когда любой имеющий физический доступ к машине может её спокойно запустить, а вот скрытых зондов там предостаточно.

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

156. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (156), 02-Сен-23, 22:38

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

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

340. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от count0 (ok), 20-Сен-23, 14:07

> Основная мотивация в том, чтобы защищать данные поставщиков ПО и контента от
> пользователя (владельца) компьютера, на который эти данные были загружены. Обычно подобное
> продается под видом заботы о безопасности самого пользователя.
StarForce-3? ))))

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

248. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от onanim (?), 03-Сен-23, 12:23

>  В чём смысл TPM, если с его помощью система просто загружается без ввода пароля?
правильное использование TPM - контроль целостности системы.
чип TPM собирает информацию о железе и прошивках, и выводит чексуммы собранной информации в своих регистрах "PCR". сравнивая эти чексуммы с эталонами, полученными после первоначальной настройки сервера, администратор сервера может определить (даже удалённо, будучи за 100500 км от сервера), изменилась ли прошивка (не залили ли протрояненный BIOS) или железо (не воткнули ли в сервер DMA дампер), и поступить соответствующим образом (продолжить загрузку системы, если он сам обновил биос или поменял железо).
а хранение ключей шифрования в TPM - долбодолбизм, так делают только долбобобы и всякие похи с тысячами шифрованных серверов.

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

331. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от ivan_erohin (?), 13-Сен-23, 10:07

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

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

332. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от onanim (?), 13-Сен-23, 12:31

> т.е. контролировать софт через TPM - глупость ?
что значит "контролировать софт через TPM"?
> примерно нихрена не сможет. Сноуден описывал черные кабинеты на почте и у
> операторов доставки,
> способные протроянить железо спецжелезками в процессе пересылки.
ну от снифферов PCI или SPI шин ничто не защитит, увы.
благо среднестатистический онаним с опеннета никому не интересен настолько, чтобы заражать его железо такими имплантами, а от втыкания обычных хакерских PCI или USB девайсов TPM защитит.

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

341. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от count0 (ok), 20-Сен-23, 14:11

> благо среднестатистический онаним с опеннета никому не интересен настолько, чтобы заражать
> его железо такими имплантами, а от втыкания обычных хакерских PCI или
> USB девайсов TPM защитит.
Зато те, у кого могли быть такие платы за пределами МКАД отсутствуют, поэтому и TPM не сильно распространён. А вот швабры, бутылки шампанского и паяльники у этих вот самых есть. Так что онаним сам введёт все пароли, расскажет "эксперту" как, и что, и подпишет признание под тяжестью улик )))

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

5. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (-), 02-Сен-23, 12:08

> Далее, так как ключи для разблокировки хранятся в TPM
А вот не...фиг ключи хранить где попало. Т.е. на системе без TPM этот номер вообще совсем не прокатит?

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

35. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от пох. (?), 02-Сен-23, 13:22

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

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

37. "Обход полнодискового шифрования в Linux через непрерывное на..." –2 +/–

Сообщение от InuYasha (??), 02-Сен-23, 13:24

Если у вас в ЦОДе радиус со лдапой не завезли, то это печально, печально.

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

40. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от пох. (?), 02-Сен-23, 13:30

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

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

47. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от Аноним (-), 02-Сен-23, 14:05

> на системе без TPM невозможно вообще загрузиться автоматически - будешь как лox
> каждый раз вводить свой пароль вручную. Подглядывающие за тобой в камеры будут
> очень рады, особенно если этот пароль и еще к чему-нибудь подойдет.
Ну я выну им из широких штанин фак^W "флеху" с из STM32. Оно и "напечатает пароль". Где там у него кнопки на которые смотреть - хрен его знает. Но фак, наверное, увидят :)

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

62. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 15:01

Зачем пешком-то? Удалённое управление каким-нибудь iDRAC.

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

164. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (173), 02-Сен-23, 23:04

Dell тебя благобдарит.

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

198. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (199), 03-Сен-23, 04:00

А как ты проверишь, что между iDRAC и разблокируемым сервером нет MiTM?

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

214. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 09:35

TLS

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

243. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от onanim (?), 03-Сен-23, 12:10

а как ты проверишь, что iDRAC не пишет нажатия клавиш и не передаёт "куда следует"?

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

262. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 19:08

Зачем?

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

263. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 19:11

Поясняю. Я не помешан на приватности. Мне принципиально только то, чтобы уборщик Уася, скоммуниз**в сервер или хранилку, не мог ничего прочитать.

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

268. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от onanim (?), 03-Сен-23, 22:45

> Поясняю. Я не помешан на приватности. Мне принципиально только то, чтобы уборщик
> Уася, скоммуниз**в сервер или хранилку, не мог ничего прочитать.
уборщик Вася и TLS перехватить не осилит, а если осилит перехватить TLS, то и iDRAC заразить сможет.

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

269. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 22:47

Не читатель?

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

270. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от onanim (?), 03-Сен-23, 22:48

> Не читатель?
а, точно, перечитал ветку и понял, что фигню написал.

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

299. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Брат Анон (ok), 05-Сен-23, 09:51

А кто тебе сказал, что в реализации TLS нет закладок?

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

300. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от Tron is Whistling (?), 05-Сен-23, 09:53

См. выше.

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

101. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от ryoken (ok), 02-Сен-23, 17:38

>>Ну а если в ЦОД моргнуло питание
Это что ж за "ЦОД" такой..??? Прям интересно стало, у них же пачка разых Tier-ов и всякого прочего.

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

117. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от пох. (?), 02-Сен-23, 18:31

> Это что ж за "ЦОД" такой..??? Прям интересно стало, у них же
> пачка разых Tier-ов и всякого прочего.
хер его знает какой там был тогда у AWS - но вышло эпичненько.
(отказ системы резервного питания стартовать из-за...нестабильности параметров входной сети. Видимо не было способа ее отрубить вообще нахрен кроме динамита. Теперь-то наверное есть динамит. Они там чуть не на коленях ползали перед поставщиком этого г-на, умоляя дать секретный код запуска под свою ответственность и любые отказы от любых гарантий - не, "нипаложана!" ответил дежурный Кумар. Ну упсы сели, а дизели не включились.)

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

133. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от ryoken (ok), 02-Сен-23, 20:21

> (отказ системы резервного питания стартовать из-за...нестабильности параметров входной
> сети. Видимо не было способа ее отрубить вообще нахрен кроме динамита.
> Теперь-то наверное есть динамит. Они там чуть не на коленях ползали
> перед поставщиком этого г-на, умоляя дать секретный код запуска под свою
> ответственность и любые отказы от любых гарантий - не, "нипаложана!" ответил
> дежурный Кумар. Ну упсы сели, а дизели не включились.)
Ай красота.... :D

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

155. "Обход полнодискового шифрования в Linux через непрерывное на..." –2 +/–

Сообщение от Атон (?), 02-Сен-23, 22:31

> дежурный Кумар.
а какого ответа ты, мало обеспеченный гражданин, ждал, если у AWS перед тобой ответственность по SLA меньше $1000 за год простоя?

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

158. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от пох. (?), 02-Сен-23, 22:47

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

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

319. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Атон (?), 06-Сен-23, 09:12

> ответа ждал _AWS_ от Кумаров копчоных.
> Но не дождались ничего хорошего - потому что кумару плевать было насколько
> это важный клиент, у него
у него по SLA ответственность перед AWS ограничена одним окладом.

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

201. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (-), 03-Сен-23, 04:26

> (отказ системы резервного питания стартовать из-за...нестабильности параметров входной
> сети. Видимо не было способа ее отрубить вообще нахрен кроме динамита.
> Теперь-то наверное есть динамит. Они там чуть не на коленях ползали
> перед поставщиком этого г-на, умоляя дать секретный код запуска под свою
> ответственность и любые отказы от любых гарантий - не, "нипаложана!" ответил
> дежурный Кумар. Ну упсы сели, а дизели не включились.)
А что, так то хороший повод послать поставщика таких систем в ж@пу и научиться делать системы управления самим. Под свои требования и приоритеты. Чтоб все коды были под рукой, и динамит сразу встроенный, если надо.

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

220. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Страдивариус (?), 03-Сен-23, 09:55

Ай, молодца Кумар! Показал им всем, что значит ынтырпрайз! Всегда смешно когда большой ынтырпрайз ломает зубы об маленький, потому что обычно всегда всё наоборот.

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

174. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (173), 02-Сен-23, 23:43

>будешь как лox каждый раз вводить свой пароль вручную.
На виртуалке. При штатном обновлении системы с перезагрузкой. Раз в полгода/год.
Страшно тяжелая работа, да.
Лучше доверить ключи какой-то технологии какой-то фирмы, которой не нужны ваши данные и она вообще занимается защитой "ВАШИХ ДАННЫХ". Бесплатно.
Верить - вот главное условие надежности. Зуб дают. Даже два.

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

179. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (179), 03-Сен-23, 00:06

Не дают они зуб. У них отказ от ответственности на каждом шагу. И возмещение ущерба размером в один (бело)русский рубль. Кто поверил, то не мамонт!

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

209. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от bOOster (ok), 03-Сен-23, 07:12

Используй USB флешку с первичным ключем, не как лох :)

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

224. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 03-Сен-23, 10:25

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

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

229. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 10:34

Да не, ну подключиться к IPMI, найти-получить нужный ключ и воткнуть - это задача максимум на 2 минуты.
Причём один землекоп может почти одновременно десяток этих нод бутнуть.
Что касается битлохера, проблема со всей этой авторазлочкой достаточно простая - если сп***т ноду, то шанс получения доступа ко всему максимален. На платах имеются нераспаянные JTAG'и и прочее.

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

231. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 10:35

Т.е. даже в случае битлохера только ручной ввод.
Но в целом у нас битлохер только в виртуалках, поэтому решений по аппаратуре как-то не требовалось.

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

234. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 03-Сен-23, 10:52

э... вот ты уверен что десяток одновременных эмуляций usb (ибо что еще там у тебя за ключ) через ipmi - это хорошая идея и тем более что оно вообще-то заработает так?
Ну и насчет двух минут - у меня лезвия грузятся по 15. Большую часть этого времени - с чорным-чорным экраном.
> Что касается битлохера, проблема со всей этой авторазлочкой достаточно простая - если сп***т
> ноду, то шанс получения доступа ко всему максимален. На платах имеются нераспаянные JTAG'и и
> прочее.
они не должны давать доступа к содержимому tpm - он неплохо изолирован. Т.е. может у кого-то и получится перехватить управление, но точно не у обычного васяна.
Опять же более вероятно все же что сп-ят или ты сам прое...шь не ноду, это все же немного палево, а диск. Бо меняются пачками и на бегу.
И в этом сюжете -вполне себе поможет TPM, не создав лишних неудобств.

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

235. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 11:03

> э... вот ты уверен что десяток одновременных эмуляций usb (ибо что еще
> там у тебя за ключ) через ipmi - это хорошая идея и тем более что оно вообще-то заработает так?
Ну, работает...
Единственная с этим проблема - доступ операторов к ключам, но это меньшее зло, чем хранить ключи прямо под ковриком.
> Ну и насчет двух минут - у меня лезвия грузятся по 15.
Ну, с iSCSI могут и дольше - смотря сколько загружать. Или имеется в виду инит фирмвари? Инит фирмвари минуты 2 на EPYC'ах занимает.
> они не должны давать доступа к содержимому tpm - он неплохо изолирован.
Ну, как видим... Не обязательно к tpm, достаточно перехватить управление после measured boot.

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

236. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 11:06

Тут скорее вопрос, что благонадёжнее - TPM или оператор. Мы решили, что оператор, потому что одновременно с*** ноду и заинсайдить оператора - это слишком палевно, доступ к ключам логгируется.

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

244. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от onanim (?), 03-Сен-23, 12:12

а на хуавеях даже распаянные

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

264. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 19:12

> а на хуавеях даже распаянные
Кщастью, этого добра нет и не ожидается.

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

267. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от onanim (?), 03-Сен-23, 22:43

>> а на хуавеях даже распаянные
> Кщастью, этого добра нет и не ожидается.
смотря у кого...
> > «Сбербанк» объявил ещё как минимум два тендера. Один из них касается закупки серверов китайской Huawei на общую сумму $80 млн

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

321. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 07-Сен-23, 17:18

хм, они ж вроде отказались вообще вести дело с РФ?

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

323. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от onanim (?), 07-Сен-23, 21:56

> хм, они ж вроде отказались вообще вести дело с РФ?
кто "они"? Huawei или казахстанская/армянская ООО "Точно Не Одноразовая Проксикомпания", которая выиграет этот тендер?

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

324. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 07-Сен-23, 22:10

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

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

326. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от onanim (?), 08-Сен-23, 15:39

> А потом китаец из оченьплохойдороги приедет в армоказахстан для настройки или ремонта
> - и ооочень удивится.
> Хотя, сервер наверное штука более простая, его можно купить и просто пользоваться,
> а запчасти закупать по графику.
> Вот с базовыми станциями плохой дороги все гораздо интереснее.
ага, недавно на широко известном в узких кругах форуме писали, что новые прошивки модемов Quectel отказываются работать с MNC = 250 (Russian Federation)

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

327. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 08-Сен-23, 15:42

Пипец мериканскому (а так же китайскому) шпиену- припрется по дипломатической визе, творить свое шпионство, а фигак - мабила ниалле! Иди, занимай очередь за аврораосной. Но сперва заведи себе акаунт на госуслугах, без него ничего не получится.

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

265. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 03-Сен-23, 19:13

Но таки да, желающие скорее всего нароют на любом вендоре.

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

334. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (-), 19-Сен-23, 05:05

> Что касается битлохера, проблема со всей этой авторазлочкой достаточно простая - если
> сп***т ноду, то шанс получения доступа ко всему максимален. На платах
> имеются нераспаянные JTAG'и и прочее.
Вообще-то вполне себе распаяный. В каждом PCI разъеме, внезапно, есть.

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

252. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Mr. Cake (?), 03-Сен-23, 13:57

google://dropbear-initramfs

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

10. "Обход полнодискового шифрования в Linux через непрерывное на..." +9 +/–

Сообщение от Ананимаз (?), 02-Сен-23, 12:14

ну шо, съэкономили пару мс на паралельном запуске?

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

11. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от Q2W (?), 02-Сен-23, 12:20

Что это за шифрование такое, если ключи можно просто попросить у этого TMP, и он их имеет и даст?
Капец какой-то. Это как в автомобилях: для установки автозапуска вмуровывали в приборную панель оригинальный ключ.

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

12. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Q2W (?), 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ообщить модератору

14. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Имя (?), 02-Сен-23, 12:29

Как так получается, что хранимый ключ сам по себе не зашифрован паролем?

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

20. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (17), 02-Сен-23, 12:35

Пароль на пароль?
Супер

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

204. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (204), 03-Сен-23, 04:40

Про 2FA слышал?

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

34. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (29), 02-Сен-23, 13:22

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

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

69. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 15:16

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

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

85. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (82), 02-Сен-23, 15:55

TPM - корпоративная фишка для офиса. Для личного использования или в случае особо ценных данных она не нужна и даже вредна.

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

92. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (87), 02-Сен-23, 16:07

TPM вообще-то аппаратный бэкдор типа intel me.

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

189. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (173), 03-Сен-23, 00:31

Ну это же трастед, ты что, ему не веришь? Оно же трастед!!!

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

21. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от Аноним (21), 02-Сен-23, 12:37

Systemd кидок

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

23. "Обход полнодискового шифрования в Linux через непрерывное на..." +10 +/–

Сообщение от InuYasha (??), 02-Сен-23, 13:00

У меня такое чувство, что разработчики линуксов* работают на раскалённых клавиатурах. Потому что - тут ВВОД подержать и получишь рута, там PRINTSCREEN подержать - получишь смерть DBus, в иксах CTRL+SHIFT вообще запрещено держать... Если вы видите совпадение, я вижу систему.
Есть такая штука как проекционная клавиатура (лазер рисует на глом столе клавиши, а камера смотрит на пальцы). Так вот: разработчикам, наверное, проецируют клавиши на раскалённую сковородку.
(UJL)

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

77. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (77), 02-Сен-23, 15:30

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

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

113. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним2 (?), 02-Сен-23, 17:58

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

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

122. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 18:41

> Если
> вы видите совпадение, я вижу систему.
Да обычные руки из ж0пы. И голова там же. И сама эта ж0па - с ушами.

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

150. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (150), 02-Сен-23, 22:14

Приматы?

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

159. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от пох. (?), 02-Сен-23, 22:50

Вообще-то это осьминоги. Но мне портрет модного современного разработчика почему-то видится именно таким.

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

259. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (259), 03-Сен-23, 17:15

Нет, хранители! :)

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

172. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от Аноним (179), 02-Сен-23, 23:31

А Линукс тут причем? Если подстава в модуле от Микрософт, который сводит дисковое шифрование на нет, храня ключи по-корпоративному "безопасно" (читай - открыто) на железке.
А все эти подержи Enter, получишь рута - это, как раз, ни о чем. С доступом к железу нет никакого рута, есть только диск с данными. Грузись с лайвсиди, монтируй и читай. Собственно, для того дисковое шифрование и придумали, чтобы данные без секретного слова прочитать нельзя было. Но Микрософт решил, что от него у вас секретов нет.

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

185. Скрыто модератором +/–

Сообщение от пох. (?), 03-Сен-23, 00:16

> С доступом к железу нет никакого рута, есть только диск с данными.
ВНЕЗАПНО, он шифрованный. Поменять ты можешь только загрузчик - но после этого диск не расшифруется.
Почему л@п4тые борцуны с MS такие феноменально т-пые?

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

186. Скрыто модератором +/–

Сообщение от Аноним (179), 03-Сен-23, 00:22

> Почему л@п4тые борцуны с MS такие феноменально т-пые?
Феноменально тупы фанаты МС, которая систематически придумывает фигню с загрузкой, чтобы сломать (обязательный раздел /EFI) или подкопнуть (хранение паролей на "безопасных" вендорлоках) дисковое шифрование по заказу кого-надо.

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

187. Скрыто модератором +/–

Сообщение от Аноним (179), 03-Сен-23, 00:25

> Поменять ты можешь только загрузчик - но после этого диск не расшифруется.
Мы уже выяснили, что у кого надо - расшифруется. Ты новость-то хоть читал? Или ничто не пошатнет твою слепую веру в корпоративные убертехнологии?

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

190. Скрыто модератором +/–

Сообщение от Аноним (173), 03-Сен-23, 00:34

Внезапно, как можно расшифровать диск? Если ключ зашифрован.
Кто тyпой?

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

176. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (173), 02-Сен-23, 23:50

>У меня такое чувство,
Это эмоции.
Спокойнее надо быть :)
Медитация поможет.

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

24. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (24), 02-Сен-23, 13:08

типичный системд

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

27. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (27), 02-Сен-23, 13:14

А что? Кто надо всегда должен иметь доступ куда надо. Иначе зачем они платят деньги шапке за системд?

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

51. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (51), 02-Сен-23, 14:08

> и systemd
...

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

28. "Обход полнодискового шифрования в Linux через непрерывное на..." +8 +/–

Сообщение от Аноним (28), 02-Сен-23, 13:15

это была специальная фича, теперь её спалили, но ничего есть ещё

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

30. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (27), 02-Сен-23, 13:16

— Ты видишь дыру?
— Нет
— А она есть.

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

127. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (127), 02-Сен-23, 19:14

Машка, видал я эту дыру, в которую проваливается пароль в 32 символа да так, что остаётся ещё с десяток бит до переполнения стека.

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

31. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Fracta1L (ok), 02-Сен-23, 13:18

Аппаратные методы защиты оказались ненадёжными, никогда такого не было...

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

36. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 13:24

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

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

41. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (21), 02-Сен-23, 13:31

системд: вот тебе рут! делай!

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

42. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Fracta1L (ok), 02-Сен-23, 13:42

Не визжи, клован. Без ТРМ этой дыры бы не было.

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

73. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (73), 02-Сен-23, 15:20

ага, а без компуктера и тебя бы небыло наверн.

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

152. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (150), 02-Сен-23, 22:15

Видеть — Википедия
ru.wikipedia.org›Видеть
Меню
«Видеть» — американский научно-фантастический драматический телесериал, созданный Стивеном Найтом для Apple TV+. Среди известных актёров Джейсон Момоа и Элфри Вудард.
Извинити )

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

170. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (173), 02-Сен-23, 23:27

тётенька, аппаратура - это что, богиня?
и почему в неё надо верить?

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

208. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (-), 03-Сен-23, 06:59

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

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

169. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (173), 02-Сен-23, 23:23

И вот опять. Надо просто верить.
Верить производителю, который прибыль получает.
Капитализация подтверждает, да. !!!

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

38. "Обход полнодискового шифрования в Linux через непрерывное на..." +3 +/–

Сообщение от InuYasha (??), 02-Сен-23, 13:27

При трукрипте такого не было! (Ц)

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

322. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноннонинмумумус (?), 07-Сен-23, 20:12

Самый цимес был в их мануалеЖ
Раздел
- Правдоподобное отрицание наличия скрытого раздела
В захлеб просто читалось (посмотрите прям в стандартном исталяторе пдфка лежала Хд

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

44. Скрыто модератором –3 +/–

Сообщение от Аноним (44), 02-Сен-23, 13:58

Опять уебунта наделала себе в штаны. На нормальных системах с FDE нет никакого emergency shell.

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

50. Скрыто модератором +/–

Сообщение от Аноним (50), 02-Сен-23, 14:08

В Федоре он тоже есть.

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

52. Скрыто модератором –1 +/–

Сообщение от Аноним (44), 02-Сен-23, 14:09

А при чём тут федора?

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

55. Скрыто модератором +/–

Сообщение от Аноним (50), 02-Сен-23, 14:16

Вы ж нормальными считаете RHEL и его поизводные.

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

56. Скрыто модератором +/–

Сообщение от Аноним (44), 02-Сен-23, 14:27

Кто вы-то?

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

57. Скрыто модератором +/–

Сообщение от RusFox (?), 02-Сен-23, 14:42

adding systemd.debug_shell to the kernel parameters, or by enabling debug-shell.service - убунтята сделали верно :)

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

46. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (46), 02-Сен-23, 14:04

Простите, а кто пароль рута то ввёл? ctrl-D или введите пароль рута. Если знаешь пароль рута, то зачем эмулировать Enter. А если не знаешь пароль рута - перед тобой чёрный ящик.

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

49. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (49), 02-Сен-23, 14:07

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

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

54. "Обход полнодискового шифрования в Linux через непрерывное на..." +6 +/–

Сообщение от Аноним (50), 02-Сен-23, 14:13

Да здравствует Systemd!

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

60. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Вася (??), 02-Сен-23, 14:58

А каким образом диски разблокируются в этом случае?

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

64. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 15:04

TPM далее прочитать не проблема - у загрузочного образа есть к нему доступ и ключ.

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

65. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (65), 02-Сен-23, 15:05

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

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

303. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от фф (?), 05-Сен-23, 11:40

я правильно понимаю, что ключ от диска лежит в ТРМ, а ключ доступа к этому ключу в clevis? который доступен любому идиоту который сможет загрузить initramfs?
может правда проще в файлик записывать?

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

325. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 07-Сен-23, 22:22

> я правильно понимаю, что ключ от диска лежит в ТРМ, а ключ
> доступа к этому ключу в clevis? который доступен любому идиоту который
нет, б-ть. Еще один феноменально т-пой не смог прочитать статью но ценное мнение  имеет. Да откуда ж вы все лезете?
> сможет загрузить initramfs?
Нет. Он должен загрузить _подписанный_ образ. В котором должен лежать загрузчик, который либо молча загружает что надо без возможности вмешаться в процесс, либо сбросить статус "measured boot" - и тогда без пароля ничего уже не расшифруется. как и в случае попыток подсунуть какой-то другой загрузчик.
Но поскольку этот загрузчик - системдрянь, оказалось что понажимав ему быстро-быстро пробел - можно получить третье состояние, которое не предусмотрено его рукож0пым изготовителем. Когда ручное управление есть, состояние signed/measured не сброшено, и ты можешь вручную выполнить команды которые не должны выполняться.

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

53. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (53), 02-Сен-23, 14:10

>>> и предоставит доступ к командной оболочке с правами root <<<
мда... жесть как она есть:(

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

58. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 14:54

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

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

63. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 15:03

Всё там неправильно.
Хочешь починить повреждённый насмерть диск - переключай бут-режимы и бутись с другого носителя.

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

72. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от пох. (?), 02-Сен-23, 15:20

это вот на современном сервере может у тебя не очень получиться.

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

75. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от Аноним (73), 02-Сен-23, 15:24

Ты из адептов облаков штолле ?

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

125. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 18:47

> Ты из адептов облаков штолле ?
каких нахрен облаков. Чтоб загрузиться с чего-то левого такому серверу нужно поменять настройки uefi boot. Вот как загрузишься, так и поменяешь. Он бы тебе даже и позволил автоматически загрузиться с чего-то еще, если бы загрузочный диск совсем не читался, но в нашем случае побита файловая система, а начальная загрузка вполне успешна.
Бери дежурный пропуск, ижжай в Караганду.
Не на каждой ентер-прайсной железке, конечно, такая пакость, но - слуцяетца. Причем чем более секьюрно-навороченная тем более там такое вероятно.
(ну рецпет мы все знаем - не выпендривайся, ставь vmware, linoops свой супрешифрованный - в виртуалочке запустишь)

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

59. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 14:57

Бггггггг.
Ну, за причины, предпосылки и последствия ничего говорить не буду - всё и так ясно.
Но завтра я ребятам расскажу, почему я им лет 5 назад как уже, запретил в TPM хранить ЛЮБЫЕ ключи. И они матерились. Вот, хороший пример.

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

76. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (73), 02-Сен-23, 15:25

Хороший пример чего ?

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

146. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 21:37

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

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

66. "Обход полнодискового шифрования в Linux через непрерывное на..." +3 +/–

Сообщение от birdie (ok), 02-Сен-23, 15:06

Никакого _обхода шифрования_ нет в помине.
Есть получение root консоли и выкачивание пароля шифрования из TPM из-за кривого/дырявого initrd.
Если ключ шифрования _не_ хранится в TPM, то нет никакой атаки - с таким же успехом (а речь идёт о физическом доступе) можно просто вытащить винт и начать перебирать LUKS пароли.

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

70. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 15:17

Что значит непонятно?
У нас _подписанный_ загрузочный образ, который может TPM читать, выпал в рут.
Дальше, думаю, сами догадаетесь.

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

71. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 15:20

(а к этому моменту он прошёл и проверку подписи, и measured boot - и вся эта шляпа оказалась припаркой к кадавру в итоге)

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

74. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 15:23

> Что значит непонятно?
> У нас _подписанный_ загрузочный образ, который может TPM читать, выпал в рут.
> Дальше, думаю, сами догадаетесь.
там даже догадываться незачем - автор оставил детальную инструкцию что за чем нажимать чтоб смонтировать диски. Но местные зингонавты ж нечитатели.

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

83. "Обход полнодискового шифрования в Linux через непрерывное на..." +3 +/–

Сообщение от birdie (ok), 02-Сен-23, 15:54

Это если ключ шифрования хранится в TPM. Атака _не_ на шифрование, а на _кривой initrd_.
Могу вам вручить все свои машины с LUKS - вперёд, используйте эту атаку. TPM у меня не используется ровно нигде.

Даже по ссылке: https://pulsesecurity.co.nz/advisories/tpm-luks-bypass
TPM (!) LUKS BYPASS
Максим в заголовке новости упустил критическую деталь. Послал ему исправление.

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

147. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 21:39

Ну я только за TPM и вещаю. Уже достаточно.
К счастью да - нас это даже потенциально тоже затронуть не может, подстраховка сработала.

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

67. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (67), 02-Сен-23, 15:11

Вот тебе и SystemD

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

141. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Shevchuk (ok), 02-Сен-23, 21:22

> Вот тебе, бабушка, и systemd
Поправил, не благодари

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

81. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (87), 02-Сен-23, 15:52

Очередная сферическая уязвимость в вакууме. А TPM в принципе не нужен и является аппаратным бэкдором на равне с secure boot, intel sgx, me и прочей тряхомудией.

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

94. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (82), 02-Сен-23, 16:15

> А TPM в принципе не нужен и является аппаратным бэкдором на равне с secure boot, intel sgx, me и прочей тряхомудией.
Не, TPM полезен вообще-то, но в ограниченном количестве случаев и не должен предполагать особую важность данных. В основном для корпоративного применения или как здесь для удаленной загрузки сервера, чтобы не бегать вручную пароль вводить.

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

196. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от Аноним (199), 03-Сен-23, 03:29

TPM не может быть бекдором, так как не умеет активно влиять на вычислительные процессы. Это просто ящик с секретами, которые выдаются и/или используются им при соблюдении некоторых условий (политик).
Secure boot нужен, чтобы сделать систему защищённой от буткитов. Чтобы злоумышленник, временно получивший возможность писать в загрузочные области диска не смог закрепиться в системе. Спецификация явным образом требует дать возможность конечному пользователю на компьютерах общего назначения менять ключи, против которых проверяется подпись.
Intel SGX нужен для двух вещей - производить конфиденциальные вычисления на чужом оборудовании (не нужно доверять оператору облака, а только лишь вендору CPU) и давать хоть какую-то безопасность на сплошь затрояненном десктопе пользователя. Тоже на бэкдор не похоже - там взаимодействие с системой отгорожено заранее декларированным IDL, что ни на диск, ни в сеть из SGX сходить не получится без содействия снаружи.
Intel ME нужен примерно для того же, для чего и обновляемый микрокод - чтобы перетащить часть функций аппаратуры в софт - это делает процессоры дешевле, ведь очередную ошибку теперь можно исправить, не выбрасывая все уже изготовленные экземпляры процессора с ошибкой. Можно только с натяжкой назвать бэкдором, если вспомнить про Intel AMT/vPro в корпоративной серии чипсетов, который ещё через MEBx надо включить. Не вижу причины не доверять ME, если уже доверяешь процессору от Intel, вставляя его в свою плату.
А уязвимость тут в неправильном использовании TPM - перед тем, как давать отладочный шелл, надо портить содержимое TPM PCR, делая невозможным применение политики, отдающей ключ шифрования.

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

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ообщить модератору

246. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от onanim (?), 03-Сен-23, 12:16

не гони на secure boot, он-то как раз - дар богов.
а остальное - да, бэкдоры.

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

274. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (199), 04-Сен-23, 00:47

Secure boot абсолютно бесполезен. Того же уровня безопасности можно достичь, просто поставив пароль на изменение настроек BIOS и пломбу на корпус, что было возможно ещё во времена IBM PC AT.
Если злоумышленник может писать тебе в загрузчик, то он и secure boot выключит - это один байт в Setup в nvstore. А если не может, то ни с чего, кроме локального диска (при правильной настройке загрузчика и BIOS) он не сможет без нарушения целостности корпуса.

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

301. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (301), 05-Сен-23, 11:03

> это один байт в Setup в nvstore
Попробуйте выключить Secure Boot на моём enterprise ноуте. Раньше теплового конца вселенной не получится.

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

309. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (-), 05-Сен-23, 13:39

> Попробуйте выключить Secure Boot на моём enterprise ноуте. Раньше теплового конца вселенной
> не получится.
Потом вылезет какой-нибудь vendor cmd который делает невозможное за 10 секунд... :)))

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

93. "Обход полнодискового шифрования в Linux через непрерывное на..." +5 +/–

Сообщение от Аноним (77), 02-Сен-23, 16:13

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

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

96. "Обход полнодискового шифрования в Linux через непрерывное на..." –2 +/–

Сообщение от Аноним (27), 02-Сен-23, 16:44

Корень в том что никто не любит тех кто шифруется и на них всегда методы найдутся.

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

153. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (150), 02-Сен-23, 22:24

Это как-то называется другими выражениями )

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

165. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Вася (??), 02-Сен-23, 23:07

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

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

148. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 21:40

Абсолютно да.
И железка по превращению одного в другое называется TPM.
Я это некоторым донести так и не смог, пришлось просто по рукам бить.

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

97. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от YetAnotherOnanym (ok), 02-Сен-23, 17:01

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

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

288. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от BeLord (ok), 04-Сен-23, 13:27

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

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

100. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (100), 02-Сен-23, 17:35

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

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

112. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (27), 02-Сен-23, 17:55

По какой методике ты собираешься это проверять что если и после? Или гуманитарий?

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

304. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от фф (?), 05-Сен-23, 11:47

пф
#!/bin/sh
if ! decrypt_automatic --please; then
   decrypt_manual --hule
fi

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

126. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от пох. (?), 02-Сен-23, 18:50

> Так почему ручной ввод работал параллельно, а не запускался ЕСЛИ и ПОСЛЕ
Патамушта у нас же ж системдрянь заботится об очень-очень-быстрой загрузке и все операции делает параллельно, включая даже аварийный запуск.
Других разработчиков "системных менеджеров" у меня для вас нет. Попробуйте, что-ли, винду?

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

241. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (241), 03-Сен-23, 11:47

> Попробуйте, что-ли, винду?
Зачем же так сразу - в петлю?

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

104. "Обход полнодискового шифрования в Linux через непрерывное на..." +4 +/–

Сообщение от Ананоним (?), 02-Сен-23, 17:42

Это какой-то... позор.

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

110. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (27), 02-Сен-23, 17:52

Не прокатило, вычёркиваем. Да вы правы.

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

123. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Аноним (123), 02-Сен-23, 18:43

Не баг а фича - Леннарт Пёттеринг...

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

124. Скрыто модератором +/–

Сообщение от Аноним (-), 02-Сен-23, 18:44

>и systemd для организации автоматической разблокировки во время загрузки.
Так-так, у кого там установлен systemD?

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

128. "Обход полнодискового шифрования в Linux через непрерывное на..." +1 +/–

Сообщение от Аноним (128), 02-Сен-23, 19:50

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

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

130. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Вы забыли заполнить поле Name (?), 02-Сен-23, 20:01

Если удалось примонтировать, то какая разница?

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

131. "Обход полнодискового шифрования в Linux через непрерывное на..." –1 +/–

Сообщение от Аноним (131), 02-Сен-23, 20:06

Еще интереснее смотреть на ваши студенческие сборки дистрибутивов -- 20 лет ИТ в РФ -- замещение и не одной нормальной комерческой ОС - с закрытым кодом.

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

154. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (150), 02-Сен-23, 22:28

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

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

134. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Q2W (?), 02-Сен-23, 20:25

Бекапы же есть

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

142. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Shevchuk (ok), 02-Сен-23, 21:28

Есть два типа людей: те, кто не делает бэкапы, и те, кто уже делает.

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

149. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (149), 02-Сен-23, 22:08

Вообще-то три. Люди делятся на три категории: те кто ещё не делает резервные копии, те, кто уже делает, и те, кто проверяет сделанные.

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

205. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Shevchuk (ok), 03-Сен-23, 04:52

Это подкатегория вторых

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

151. "Обход полнодискового шифрования в Linux через непрерывное на..." +2 +/–

Сообщение от Tron is Whistling (?), 02-Сен-23, 22:15

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

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

161. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Вася (??), 02-Сен-23, 22:55

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

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

298. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от _ (??), 05-Сен-23, 06:52

Эпический!(С)

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

240. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Аноним (241), 03-Сен-23, 11:45

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

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

271. "Обход полнодискового шифрования в Linux через непрерывное на..." +/–

Сообщение от Perlovka (ok), 03-Сен-23, 23:18

Любопытно смотреть на администраторов локалхоста, которые в жизни не работали в системах, где секретность информации стоит выше ее сохранности.

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

167. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (173), 02-Сен-23, 23:11

>Атака сводится к тому, что злоумышленник может подключить устройство для симуляции непрерывного нажатия Enter, откатить процесс загрузки на ручной ввод пароля разблокировки и успеть исчерпать максимальный лимит на число попыток ввода пароля в небольшой промежуток времени до окончания выполнения обработчика автоматической разблокировки (автоматическая разблокировка требует времени и симулируя очень быстрые нажатия Enter можно успеть завершить выполнение процесса ручной разблокировки раньше, чем отработает параллельно запущенный процесс автоматической разблокировки).
Это вообще законно???

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

211. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от YetAnotherOnanym (ok), 03-Сен-23, 07:16

"Это деяние, хотя и предусмотренное Уголовным кодексом, все же имеет невинный вид детской игры в крысу"

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

168. "Обход использующего TPM шифрования диска в Linux через непре..." –2 +/–

Сообщение от Аноним (173), 02-Сен-23, 23:18

>В качестве возможной меры для защиты от атаки рекомендуется выставить при загрузке параметры ядра rd.shell=0 и rd.emergency=reboot, при которых в случае сбоя на раннем этапе загрузки будет выполнена автоматическая перезагрузка, а не переход в интерактивный сеанс.
Да как так-то?
Вот надо таки было использовать FreeBSD или OpenBSD. Там такой фигни нет. По умолчанию.

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

305. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от фф (?), 05-Сен-23, 11:51

в смысле нет? я так рутовский пароль и на фри и на опен восстанавливал.

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

192. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от torvn77 (ok), 03-Сен-23, 02:12

>Systemd, получив управление
Корень всех проблем

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

238. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (241), 03-Сен-23, 11:39

/bin/sh лучше?

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

286. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от torvn77 (ok), 04-Сен-23, 13:15

Зачем sh если есть sysVinit?

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

239. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (241), 03-Сен-23, 11:39

https://www.opennet.dev/openforum/vsluhforumID3/131398.html#237

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

287. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от torvn77 (ok), 04-Сен-23, 13:19

Тем не менее решение о предоставлении локального доступа без предоставления пароля принимает именно systemd.
а вот sulogin по умолчанию без пароля не пустит.

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

202. "Обход использующего TPM шифрования диска в Linux через непре..." +1 +/–

Сообщение от Аноним (202), 03-Сен-23, 04:28

Дать рута не спрашивая пароля рута? SystemDегиниально!

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

237. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (241), 03-Сен-23, 11:37

Ты вообще понимаешь о чём говоришь, гений? Как устроен процесс загрузки ядра? Что такое процесс инициализации?
// https://github.com/torvalds/linux/blob/master/init/main.c :
static int __ref kernel_init(void *unused)
{
//...
    if (!try_to_run_init_process("/sbin/init") ||
    !try_to_run_init_process("/etc/init") ||
    !try_to_run_init_process("/bin/init") ||
    !try_to_run_init_process("/bin/sh")) // sic!
    return 0;
//...
}
$ stat -c%N /sbin/init
'/sbin/init' -> '../lib/systemd/systemd'
Дальше нужно объяснять? Или ты сам видишь, что без системды у тебя рут-шелл вместо инита?
Повторяю для самых одарённых похов, нахов, няшей и прочих анонимных опеннет-экспертов: доступ к железке (хотя бы удаленный доступ к вводу на этапе загрузки) - это уже больше, чем "рут". Спасёт только дисковое шифрование данных и хранение пароля (а ещё лучше - заголовков LUKS и всего загрузчика, монтируемого на чтение, удаленно, только на момент загрузки) в надежном месте. TPM - надежным местом для паролей не является by design. Глупо полагаться, что в процессе загрузки ядра ничего не случится. Когда железки сообщают кривые ACPI/APM из кривых "биосов", а ещё до монтирования разделов (до cryptsetup) загружаются ранние модули ядра (привет, Невидии!). Слишком много переменных.

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

275. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (199), 04-Сен-23, 01:05

> !try_to_run_init_process("/bin/sh")
А теперь внимательнее почитай эту функцию. Там выше запускается /init из initramfs, который расшифровывает диск. Вот он должен быть максимально тупым, и никаких шеллов не запускать без предварительной блокировки (и проверки её успешности) ключа.
Если хочешь делать систему безопасной, снижай число переменных (уменьшай trusted computing base), а те, что остались, измеряй в PCR. Прежде, чем использовать TPM, стоит почитать рекомендации TCG.
Trusted computing base можно сделать даже меньше ядра Linux, если использовать TXT и late launch.
> доступ к железке (хотя бы удаленный доступ к вводу на этапе загрузки) - это уже больше, чем "рут"
Нет, если правильно настроены механизмы integrity. В Linux для этого есть kernel_lockdown(7) и IMA.
> TPM - надежным местом для паролей не является by design
By design TPM позволяет изолировать ключи и пароли от небезопасного состояния Host OS. То есть это альтернатива не сохранению ключа на флешку, пароля в мозг или носимый с собой криптотокен, а альтернатива записи его в конфиг на диске, находящимся под постоянным контролем Host OS.
> Глупо полагаться, что в процессе загрузки ядра ничего не случится.
Поэтому есть DRTM, SINIT ACM и TXT, позволяющие отменить всё то потенциально нехорошее, что случилось в процессе загрузки прошивки/загрузчика/ядра. Пристукнет даже ту малварь, которая в SMI handler смогла влезть.

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

280. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (179), 04-Сен-23, 11:38

>> !try_to_run_init_process("/bin/sh")
> А теперь внимательнее почитай эту функцию. Там выше запускается /init из initramfs,
> который расшифровывает диск. Вот он должен быть максимально тупым, и никаких
> шеллов не запускать без предварительной блокировки (и проверки её успешности) ключа.
Это не функция, а ленивое выражение. Если часть выражения, которая вызывает функцию запускающую инит с указанным строкой путем проваливается, то вычисляется следующая часть выражения и так постепенно, пока не будет вызвана последняя. Мне дальше тебя языку Си учить, линукс-хакер, эксперт-безопасник, или ты продолжишь учить меня внимательности?
А теперь, внимание, что же там запускается из initramfs:
# lsinitrd /boot/EFI/linux.efi |grep -e bin/init$
$ usr/bin/init -> ../lib/systemd/systemd
Вопрос, разумеется, не в том, кто-какую систему инициализации соберёт себе в инит. Можно вообще - никакую. (А без шелла уже вряд ли обойтись). Вопрос в ядерном дизайне процесса. Он таков, что не предусматривает надежности (и не должен). Жаль, M$ об этом "никто не рассказал", когда она проектировала свой бэкдор.
> TPM
Ключ от замка под ковриком рядом с дверью. By design. Это лишь вопрос времени, когда кто-то догадается под него заглянуть.
> DRTM, SINIT ACM и TXT
Даже если на коврик положить гирьку.

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

294. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (199), 04-Сен-23, 19:26

> ты продолжишь учить меня внимательности?
Да. Это "ленивое выражение" находится внутри функции kernel_init, которая вызывает run_init_process(ramdisk_execute_command) до возможного запуска /bin/sh.
> А без шелла уже вряд ли обойтись
В initramfs - запросто. У меня там лежит статический бинарь на Go, который находит, готовит и монтирует корень.
> Вопрос в ядерном дизайне процесса.
В ядре в этом плане всё хорошо. Измерять себя и критические бинари перед запуском оно умеет.
> Ключ от замка под ковриком рядом с дверью.
Нет, это ключ от замка в специальном ящике, для которого нужен свой ключ. И в отличии от твоего кармана, этот ящик специально проектировали для того, чтобы безопасно держать в нём свои ключи.
Повторю свой вопрос: Что именно в спеке TCG TPM 2.0 вызывает проблемы? Где там бэкдор от M$?

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

312. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (312), 05-Сен-23, 14:16

> вызывает run_init_process(ramdisk_execute_command)
Которая тоже строка, содержащая путь ("/init", если не установлен другой), по которому окажется симлинк, ссылающийся куда-угодно.
> запросто. У меня там лежит статический бинарь на Go
Фигасе, запросто. Программу нужно написать и отладить. Хорошо, если смонтировать корень без нормальной обработки ошибок будет достаточно, а если нужен запуск служб, аутентификация пользователей? Переизобретать полноценный инит?
> В ядре в этом плане всё хорошо.
Строковые пути с симлинками - это требует большого внимания, а не слепого доверия. Особенно, со стороны "безопасных" модулей с ключами от квартир, где деньги лежат.
> И в отличии от твоего кармана, этот ящик специально проектировали для того, чтобы безопасно держать в нём свои ключи.
На моем кармане тоже титановая молния. Но, кроме того, мой карман всегда при мне, а не рядом с дверью. И ключ из него достается только в моем присутствии.
> Повторю свой вопрос: Что именно в спеке TCG TPM 2.0 вызывает проблемы? Где там бэкдор от M$?
Повторю свой ответ: хранить ключи, постоянно, рядом с замком. Хотя, если бы я сомневался в злом умысле M$, назвал бы это не бэкдором, а идиотизмом. Но поводов сомневаться нет.

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

313. "Обход использующего TPM шифрования диска в Linux через непре..." –1 +/–

Сообщение от Аноним (312), 05-Сен-23, 15:01

А ты вообще не замечаешь, как ловко у M$ всё выходит?
В рекламных буклетах M$ типа стоит на страже ваших данных. А на деле они просто переложили отвественность на других.
Ключи свистнули? Так это не мы! Это Linux/cryptsetup/dracut/systemd кривой! Вы же сами их подписали! Все дружно ругаем в Интернетах кривой Линукс. Прям бесплатная антипиар-кампания, раньше им за такое платить приходилось.. Но, подождите, инит-генераторов и инит-систем в природе миллион. И ещё столько же умолчальных настроек в разных дистрибутивах. И не только Линуксов! А админы, всё это настраивающие, что удивительно, люди, а не илоны-маски. Зато с M$ взятки гладки. Сам настроил, сам виноват! Ага, а когда ключи в контейнере расшифруют, так это тоже не МС будет виновата, а алгоритм и математики, которые его неправильно придумали. А за что тогда вообще M$-то отвечает? Какую-такую она нам безопасность обещает? А ни за что. Но ключи шифрования вы её, всё равно, доверьте, жалко что ли? Вам будто спокойнее, а бизнесменам - грант.

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

314. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (312), 05-Сен-23, 15:12

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

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

206. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (206), 03-Сен-23, 05:10

>> Systemd, получив управление после неудачных попыток ручной разблокировки, не сможет получить доступ к файловым системам на зашифрованных дисках, предложит перейти в режим восстановления после сбоя и предоставит доступ к командной оболочке с правами root в окружении загрузочного ram-диска.
А при испорченном (контролируемо) диске мы тоже получим режим восстановления с рутом? Уже неплохо, плюс восстановим (с флешки) повреждённое и инициируем штатный процесс автоматической разблокировки зашифрованных дисков, вот и данные.

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

230. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от пох. (?), 03-Сен-23, 10:34

> А при испорченном (контролируемо) диске мы тоже получим режим восстановления с рутом?
_якобы_ наши средства шифрования не позволяют диск испортить контролируемо (если ты уже не рут еще до перезагрузки). Реализация вполне может быть как обычно.
Я еще не забыл историю ранних дней линукса, когда у них des оказался xor'ом. Причем это было видно просто если посмотреть hexdump - но кто бы мог подумать и было ли чем, сказали же ж вам - des, чего на него смотреть-то.
> Уже неплохо, плюс восстановим (с флешки) повреждённое и инициируем штатный процесс
С флэшки не получится, если это не кого надо флэшка.
С штатного загрузчика подписанного своим ключом - не должно получаться без запроса пароля, но сам видишь, получается, даже без необходимости что-то там портить.

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

261. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (206), 03-Сен-23, 17:34

Я имел в виду немного другое: т.к. у нас подключается USB-брелок, то физический доступ к устройству у нас есть. Вытаскиваем зашифрованный диск, вставляем в другой комп, вычитываем мегабайт-другой с начала и конца диска на флешку и зануляем эти области на диске. Ставим диск назад. Запускаемся. После автоматической расшифровки на занулённых блоках выдаётся мусор. Т.е. мусор получается на областях MBR/GPT и на начальной области первой партиции (а можно и не трогать MBR/GPT, а попортить только начальные/важные области всех партиций). Далее непонятно, как отреагирует systemd на подобное, но, судя по приведённой цитате, похоже даст рута для восстановления. Если это так, то подключаем флешку (доступ к USB-порту у нас есть), с неё перенесём исходное содержимое занулённых блоков обратно на диск и инициируем штатный процесс автоматической разблокировки зашифрованных дисков. Как-то так.

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

315. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от пох. (?), 05-Сен-23, 23:03

> Я имел в виду немного другое: т.к. у нас подключается USB-брелок, то
> физический доступ к устройству у нас есть. Вытаскиваем зашифрованный диск
дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть диск из сервера в стойке?
И сам сервер вырубить на пару часиков пока ты этой фигней занимаешься (прямо под камерами).
> Далее непонятно, как отреагирует systemd на подобное, но, судя по приведённой
понятно - там нет никакого race condition, поэтому он либо опознает luks заголовок, и спросит у тебя пароль, либо не опознает и просто выпадет в осадок - без шансов для тебя воспользоваться содержимым tpm.
> цитате, похоже даст рута для восстановления. Если это так, то подключаем
даст да не того рута.
> флешку (доступ к USB-порту у нас есть), с неё перенесём исходное
> содержимое занулённых блоков обратно на диск и инициируем штатный процесс автоматической
> разблокировки зашифрованных дисков. Как-то так.
штатный в этот момент уже не получится.
И в любом случае это уже совсем не то же самое что микроскопическая хрень сунутая в usb порт
(причем всунуть могут заранее, и хрен ты ее увидишь даже при непосредственном доступе к стойке, а сработать оно может и через год)

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

318. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (206), 06-Сен-23, 05:39

>> дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть диск из сервера в стойке? И сам сервер вырубить на пару часиков пока ты этой фигней занимаешься (прямо под камерами).
>> -----
>> И в любом случае это уже совсем не то же самое что микроскопическая хрень сунутая в usb порт (причем всунуть могут заранее, и хрен ты ее увидишь даже при непосредственном доступе к стойке, а сработать оно может и через год)
Вариант с мелкой "флешкой" конечно удобней, безусловно, просто описание уязвимости создало впечатление, что может пройти и более дубовый способ без всяких спец. устройств и гонок. Ну а возможность вытворять с железом всякое может быть вполне и легальной.
>> понятно - там нет никакого race condition, поэтому он либо опознает luks заголовок, и спросит у тебя пароль, либо не опознает и просто выпадет в осадок - без шансов для тебя воспользоваться содержимым tpm.
Заголовки luks можно не трогать (они описаны и идут до данных), а портить сами данные. Пусть расшифровываются. Получим битую файловую систему с которой далее не получится работать.
>> даст да не того рута.
>> -----
>> штатный в этот момент уже не получится
"Systemd, ..., не сможет получить доступ к файловым системам на зашифрованных дисках, предложит перейти в режим восстановления после сбоя и предоставит доступ к командной оболочке с правами root в окружении загрузочного ram-диска."
А чем текущее состояние отличается от описанного в уязвимости? Вроде, такое же, и там всё работало.

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

316. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от пох. (?), 05-Сен-23, 23:03

> Я имел в виду немного другое: т.к. у нас подключается USB-брелок, то
> физический доступ к устройству у нас есть. Вытаскиваем зашифрованный диск
дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть диск из сервера в стойке?
И сам сервер вырубить на пару часиков пока ты этой фигней занимаешься (прямо под камерами).
> Далее непонятно, как отреагирует systemd на подобное, но, судя по приведённой
понятно - там нет никакого race condition, поэтому он либо опознает luks заголовок, и спросит у тебя пароль, либо не опознает и просто выпадет в осадок - без шансов для тебя воспользоваться содержимым tpm.
> цитате, похоже даст рута для восстановления. Если это так, то подключаем
даст да не того рута.
> флешку (доступ к USB-порту у нас есть), с неё перенесём исходное
> содержимое занулённых блоков обратно на диск и инициируем штатный процесс автоматической
> разблокировки зашифрованных дисков. Как-то так.
штатный в этот момент уже не получится.
И в любом случае это уже совсем не то же самое что микроскопическая хрень сунутая в usb порт
(причем всунуть могут заранее, и хрен ты ее увидишь даже при непосредственном доступе к стойке, а сработать оно может и через год)

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

213. "Обход использующего TPM шифрования диска в Linux через непре..." –1 +/–

Сообщение от Аноним (213), 03-Сен-23, 08:54

Шифрование с тпм это шифрование просто от детей, не более.

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

277. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (199), 04-Сен-23, 01:13

Для детей и пароля на биос с загрузчиком хватит. Или просто кабель питания унести с собой на работу.

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

290. "Обход использующего TPM шифрования диска в Linux через непре..." +2 +/–

Сообщение от 1 (??), 04-Сен-23, 15:54

Это у тебя ещё маленькие дети.

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

317. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от пох. (?), 05-Сен-23, 23:04

> Это у тебя ещё маленькие дети.
не достают с пола до клавиатуры на столе,угу

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

250. "Обход использующего TPM шифрования диска в Linux через непре..." +2 +/–

Сообщение от Аноним (250), 03-Сен-23, 13:06

>В Linux
Пишите правду в заголовке что systemd виновато

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

255. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от пох. (?), 03-Сен-23, 14:34

systemd/linux тогда уж.
(у нас есть и другой линукс, в нем нет этой уязвимости, но он называется - андроид и тебе вряд ли понравится)

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

302. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (302), 05-Сен-23, 11:18

к счастью, полно линуксов и без systemd помимо этого вашего "ведра"

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

311. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от пох. (?), 05-Сен-23, 14:02

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

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

256. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (256), 03-Сен-23, 14:45

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

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

285. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от torvn77 (ok), 04-Сен-23, 13:13

Через вал мотор-генератора будет практичнее.

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

257. "Обход использующего TPM шифрования диска в Linux через непре..." –2 +/–

Сообщение от pavlinux (ok), 03-Сен-23, 15:24

> непрерывно симулирующий нажатие Enter c задержкой на уровне 15 миллисекунд,
Насколько помню, у контроллера клавы задерка 25 мс.

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

278. "Обход использующего TPM шифрования диска в Linux через непре..." +1 +/–

Сообщение от Аноним (199), 04-Сен-23, 01:23

У USB HID такой задержки нет. Стандартная частота поллинга EP - 125 Гц, что даст задержку в 8 мс.
У контроллера клавиатуры, что в SuperIO, по умолчанию частота шины 10-16 КГц (62-83 мкс) и честные прерывания.
Частота опроса типичной клавиатурной матрицы контроллером внутри дешёвой клавиатуры - 350 Гц. Можно смело делить на два, потому что обычно ещё антидребезг делают, что даёт суммарную задержку где-то около 6 мс.

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

281. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (281), 04-Сен-23, 11:53

Я так понимаю, что если настроен ввод PIN дополнительно, то эту атаку нельзя провести?

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

282. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Golangdev (?), 04-Сен-23, 11:58

> откатить процесс загрузки на ручной ввод пароля разблокировки и успеть исчерпать максимальный лимит на число попыток ввода пароля в небольшой промежуток времени до окончания выполнения обработчика автоматической разблокировки (автоматическая разблокировка требует времени и симулируя очень быстрые нажатия Enter можно успеть завершить выполнение процесса ручной разблокировки раньше, чем отработает параллельно запущенный процесс автоматической разблокировки)
хех, сделали race condition, молодцы!)

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

289. "Обход использующего TPM шифрования диска в Linux через непре..." +/–

Сообщение от Аноним (289), 04-Сен-23, 14:01

Раньше считалось что если зажать энтер то система быстрее грузится

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

328. "Обход шифрования диска в Linux через непрерывное нажатие кла..." +/–

Сообщение от Алексей (??), 09-Сен-23, 20:37

А почему, интересно, загрузка с левой железякой считается за measured boot?

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

329. "Обход шифрования диска в Linux через непрерывное нажатие кла..." +/–

Сообщение от onanim (?), 10-Сен-23, 10:28

> А почему, интересно, загрузка с левой железякой считается за measured boot?
потому что эта железяка кого надо железяка

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

333. "Обход шифрования диска в Linux через непрерывное нажатие кла..." +1 +/–

Сообщение от Пряник (?), 18-Сен-23, 09:37

> можно успеть завершить выполнение процесса ручной разблокировки раньше, чем отработает параллельно запущенный процесс автоматической разблокировки
ДВА параллельных процесса разблокировки! Ты действовал наверняка, да?

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Скрыто модератором	–4 +/–
Сообщение от Аноним (1), 02-Сен-23, 12:01
В bitlocker такого позорища никогда не было
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. Скрыто модератором	+9 +/–
	Сообщение от Аноним (8), 02-Сен-23, 12:12
	> В bitlocker такого позорища никогда не было Шутишь? Там всё гораздо запущеннее: https://support.microsoft.com/en-us/topic/kb5025175-updating... https://msrc.microsoft.com/en-US/security-guidance/advisory/... https://msrc.microsoft.com/update-guide/vulnerability/CVE-20... https://blog.f-secure.com/cold-boot-attacks/ https://secret.club/2021/01/15/bitlocker-bypass.html
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. Скрыто модератором	+1 +/–
	Сообщение от пох. (?), 02-Сен-23, 13:19
	>> В bitlocker такого позорища никогда не было > Шутишь? Там всё гораздо запущеннее: только в воображении л@п4тоужаленных > https://support.microsoft.com/en-us/topic/kb5025175-updating...- уязвимость в winRE. Надо быть админом и знать пароль. И еще и иметь RE, конечно же на нешифрованном разделе. > https://msrc.microsoft.com/en-US/security-guidance/advisory/... Уязвимость в конкретных чипах infineon > https://msrc.microsoft.com/update-guide/vulnerability/CVE-20... та же самая уязвимость в winRE > https://blog.f-secure.com/cold-boot-attacks/ FUD от известных врунишек > https://secret.club/2021/01/15/bitlocker-bypass.html единственная серьезная проблема, впрочем автор _крайне_ мутен в том месте где доходит до выполнения собственно экзешника - предлагается его скачать бесплатнобезсмс. Используется целый набор странных фич, включая средства для альтернативно-одаренных (ох как же я люблю эту заботку об инвалидиках пихаемую без разбора всюду и везде) и восстановления продолбанных паролей (да, безусловно было бы прекрасно их не иметь вовсе - ну вот как у вас, л@п4тых - продолбал пароль - прощайся с диском). При этом MS как-то вот не уверена что и это реализуемо не в лабораторных условиях. Ну и рекомендация оверрадить настройки logon screen таки была нелишней. Разумеется, это то же самое, что просто быстро-быстро понажимать space и ой, я рут.
	Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Обход полнодискового шифрования в Linux через непрерывное на..."	+19 +/–
Сообщение от Аноним (3), 02-Сен-23, 12:02
В чём смысл TPM, если с его помощью система просто загружается без ввода пароля?
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Обход полнодискового шифрования в Linux через непрерывное на..."	+1 +/–
	Сообщение от Аноним (8), 02-Сен-23, 12:04
	Не взломав систему, не получишь доступ к данным на диске. Если просто вынуть диски, данные не извлечь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	9. "Обход полнодискового шифрования в Linux через непрерывное на..."	+/–
	Сообщение от Аноним (8), 02-Сен-23, 12:13
	> Сломалась материнка - прощай инфа на диске? На этот случай есть пароль для ручной разблокировки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Обход полнодискового шифрования в Linux через непрерывное на..."	+9 +/–
	Сообщение от bergentroll (ok), 02-Сен-23, 15:36
	«На этот случай у меня есть проездной!»
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Обход полнодискового шифрования в Linux через непрерывное на..."	+3 +/–
	Сообщение от Аноним (87), 02-Сен-23, 15:58
	Тогда в чём смысл TPM?
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


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


	136. "Обход полнодискового шифрования в Linux через непрерывное на..."	–1 +/–
	Сообщение от Shevchuk (ok), 02-Сен-23, 20:38
	В том, чтобы не быть ограниченным _только_ ручным вводом. Да-да, в свете этой новости: "ну как поплавали?" Речь об идее.
	Ответить \| Правка \| К родителю #87 \| Наверх \| Cообщить модератору


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


	132. "Обход полнодискового шифрования в Linux через непрерывное на..."	+1 +/–
	Сообщение от Dmitry22333 (ok), 02-Сен-23, 20:11
	я слышал что была такая игра, там штангист поднимает штангу, и чем чаще нажимается Enter тем больший груз он поднимает :) а если с USB брелком как описан в посте - можно будет тонны поднимать одной рукой :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	217. "Обход полнодискового шифрования в Linux через непрерывное на..."	+3 +/–
	Сообщение от Страдивариус (?), 03-Сен-23, 09:49
	> Если просто вынуть диски, данные не извлечь. А нельзя, вынув диск, подключить в материнку свой диск, загрузиться с рутом и просто извлечь из TPM ключи и потом расшифровать вынутый диск? Я не понимаю модель нарушителя, для которого эта затея сделана.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	291. "Обход полнодискового шифрования в Linux через непрерывное на..."	+/–
	Сообщение от погроммист (?), 04-Сен-23, 16:41
	> Не взломав систему Ну т.е. если не брать всякую биометрию, то всё равно пароль нужно вводить, просто позже -- на этапе login manager-а.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	6. "Обход полнодискового шифрования в Linux через непрерывное на..."	+14 +/–
	Сообщение от Аноним (-), 02-Сен-23, 12:09
	> В чём смысл TPM, если с его помощью система просто загружается без ввода пароля? В данном случае видимо наглядное демо что удобство и безопасность живут по разные стороны улицы. Вы хотели автторазблокирование? Ну вот атакующий его оказывается тоже сможет. Удобно же!
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


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


	43. "Обход полнодискового шифрования в Linux через непрерывное на..."	–4 +/–
	Сообщение от pic (?), 02-Сен-23, 13:48
	Обычный слесарный молоток решает эту проблему.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Обход полнодискового шифрования в Linux через непрерывное на..."	+2 +/–
	Сообщение от Аноним (-), 02-Сен-23, 17:21
	> Смысл авторазблокировки не в том, чтобы создать невзамываемую систему, а в том, > чтобы диск был бесполезен без компьютера, в котором он был зашифрован. И этот бред в результате "защищает" - паазвольте ка, кого и от чего?! Если атакующий может сп...ть диск, то уж гирьку на энтер он поставить и подавно может. Ну, ладно, не гирьку так приблуду в юсб. На вид выглядит как буллшит какой-то вместо защиты. Т.е. ситуация в которой это еще и работает - полностью выдуманная и прокатит только от совсем рагулий вместо атакующих.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	295. "Обход полнодискового шифрования в Linux через непрерывное на..."	+2 +/–
	Сообщение от АнонимПротивЦензуры (?), 04-Сен-23, 20:55
	теперь нужно воровать диск с мат. платой и входить без пароля. так фбр удобней. А брелок с ключом от диска требует ещё и пароля.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	16. "Обход полнодискового шифрования в Linux через непрерывное на..."	+5 +/–
	Сообщение от Аноним (16), 02-Сен-23, 12:31
	TMP полная чушь. Гораздо надежнее использовать флешку для хранения ключей. Вынул флешку - нет ключа. Вставил - есть ключ. А TMP вынуть нельзя если заходел отдать комп в сервис. Так что TMP полная чушь.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	26. "Обход полнодискового шифрования в Linux через непрерывное на..."	+/–
	Сообщение от Аноним (29), 02-Сен-23, 13:10
	Использую аппаратный TPM, его можно вынуть. Гребенка под него есть практически на любой современной, и не очень, плате.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	207. "Обход полнодискового шифрования в Linux через непрерывное на..."	+/–
	Сообщение от Аноним (207), 03-Сен-23, 05:15
	Почитай, что такое descrete TPM. Можешь заодно погуглить картинки и почитать про материнки с TPM header-ом. Впрочем, у dTPM есть свои проблемы: к нему, в отличии от fTPM (firmware TPM) можно подцепить на контакты осциллограф и считать, что он за данные у него там на шине летают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	296. "Обход полнодискового шифрования в Linux через непрерывное на..."	+/–
	Сообщение от АнонимПротивЦензуры (?), 04-Сен-23, 20:59
	а встроенное шифрование в диск вставить фбр не разрешило
	Ответить \| Правка \| Наверх \| Cообщить модератору


	173. "Обход полнодискового шифрования в Linux через непрерывное на..."	+2 +/–
	Сообщение от Аноним (173), 02-Сен-23, 23:36
	TPM - гoвнo. Бай дезигн.
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


	39. "Обход полнодискового шифрования в Linux через непрерывное на..."	+/–
	Сообщение от пох. (?), 02-Сен-23, 13:29
	Ну вот утром был сбой системы защиты электропитания в DC, она защитила электропитание, отрубив его сама. Езжай, милок, в свой выходной, за 20 километров - флэшки вставлять будешь. И побыстрее, бузинесс уже недовольство выразил.
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


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


	107. "Обход полнодискового шифрования в Linux через непрерывное на..."	+1 +/–
	Сообщение от Тот самый (?), 02-Сен-23, 17:49
	>лучше ещё не придумано. Открой для себя Tang. Жизнь с шифрованными томами в ЦОДе станет существенно легче. Кстати, Clevis умеет брать ключи в т.ч. из Tang и в этом случае описанная уязвимость не сработает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	137. "Обход полнодискового шифрования в Linux через непрерывное на..."	+1 +/–
	Сообщение от Shevchuk (ok), 02-Сен-23, 20:54
	Причём ключ никогда не покидает машину, на которой он используется для расшифровки. Но при этом без помощи внешнего сервера Tang и сама эта машина ключ не может использовать, принципиально. Довольно остроумная система. - https://youtu.be/Dk6ZuydQt9I - https://youtu.be/v7caQEcB6VU
	Ответить \| Правка \| Наверх \| Cообщить модератору