forum.opennet.ru

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

Оглавление

Критическая уязвимость в загрузчике GRUB2, позволяющая обойти UEFI Secure Boot, opennews (?), 30-Июл-20, (0) [смотреть все]

1 https www gnu org software grub manual grub grub html Using-digital-signatur, Аноним (47), 07:44 , 30-Июл-20, (47) +18 //

100 хотят дрянь типа systemd в grub засунуть под предлогом исправления из пальц, Аноним (49), 08:09 , 30-Июл-20, (49) +3 //

А может дрянь не в сам grub совать будут, а в обновлённые сборки дистрибутивов , Аноним (81), 09:36 , 30-Июл-20, (81) +4
Уже есть systemd boot , Аноним (91), 10:22 , 30-Июл-20, (91) +2 //

До GNU Systemd осталось немного , Анноним (?), 10:34 , 30-Июл-20, (96) –1

Обсуждаю с коллегами варианты защиты, и ребята говорят, что надо внедрять system, anonymous (??), 10:39 , 30-Июл-20, (98) –2 //

лавров jpg, anonom (?), 14:56 , 30-Июл-20, (136) +2

А если откинуть эмоции, то технические аргументы какие forward-нуть , anonymous (??), 19:02 , 30-Июл-20, (174)

Форкнуть хотели сказать Описанная уязвимость boothole практично нереализуема У , Аноним (219), 11:17 , 31-Июл-20, (219)

А ключ для шифрования откуда берётся Вручную вводится Или из TPM А проблема ре, anonymous (??), 14:39 , 31-Июл-20, (238)

Да даже если разрешено шифрование с ключом в TPM -- та же проблема , anonymous (??), 14:39 , 31-Июл-20, (239)

Значит так ребята Давайте версии используемого вами grub пишите и дистрибутива , Аноним (241), 14:56 , 31-Июл-20, (241)

Не должно быть проблем ни с ручным вводом пароля ни с ключом Измененный grub cfg, Аноним (241), 14:53 , 31-Июл-20, (240)

Когда у тебя миллион серверов, это уже становится проблемным А про ключик из TPM, anonymous (??), 19:59 , 31-Июл-20, (253)

С каким конкретно TPM и какая конкретно версия GRYB не работает Если лям сервако, Аноним (255), 07:16 , 01-Авг-20, (255)

Или coreboot затрояненый проприетарные блобами обучить шифровать boot Портиров, Аноним (258), 08:09 , 01-Авг-20, (258)

Не могу распарсить написанное , anonymous (??), 10:12 , 01-Авг-20, (264)
Coreboot обучить шифровать boot портировав в него поддержку LUKS с GRUB2 или Li, Аноним (288), 14:16 , 03-Авг-20, (288)

Почему не работает Работает Просто тут выбор 1 Либо запретить менять конфиг g, anonymous (??), 10:09 , 01-Авг-20, (263)

Не понял вашей политики организации изменения конфигурации grub Для изменения ко, Аноним (288), 14:29 , 03-Авг-20, (289)

Нет такого в природе, подпись grub cfg проверяется и побитого GRUB не загрузит, Аноним (308), 14:54 , 18-Авг-20, (308)

Он курящий , Аноним (231), 13:24 , 31-Июл-20, (231)

s сертифицированный цепочку вериытцированну цепочку Вражеский спелчекер херит см, Аноним (49), 08:15 , 30-Июл-20, (50) //

Смысла нет, есть цель , Аноним (231), 13:05 , 30-Июл-20, (123)

А можно поподробнее, каким образом он подписывается И как после этого обновлять , Аноним (102), 11:36 , 30-Июл-20, (102) +1 //

https www gnu org software grub manual grub grub html Using-digital-signatures, Аноним (207), 08:47 , 31-Июл-20, (207)
https www linux org ru forum admin 15742224 cid 15744272, Аноним (230), 12:59 , 31-Июл-20, (230)

Какой дистр Что мешает на компе прописать зловредные ключи при наличии физ дост, олооло (?), 16:20 , 30-Июл-20, (157) //

Сам себе дистростроитель Свой дистр свои правила Сегодня нет популярных дистров, Аноним (219), 10:46 , 31-Июл-20, (216)

Документированная фичя https www gnu org software grub manual grub grub html G, Аноним (219), 11:08 , 31-Июл-20, (218) +1 //

Наверно все же лучшим решением будет перенос пароля с grub cfg в grub core img , Аноним (258), 08:03 , 01-Авг-20, (257)

Богато накопали, однако , Consta (?), 00:22 , 30-Июл-20, (1) +6 //

а вот если бы писали на расте - то было бы бедно , Аноним (21), 03:05 , 30-Июл-20, (21) –17 //

А раст что, телепатить умеет Там ошибка в том что все должно было вырубиться по, Аноним (30), 05:35 , 30-Июл-20, (30) +6 //

Не говоря уже о том, что низкоуровневые вещи один черт в unsafe будут, а мантра , asdasd (?), 07:41 , 30-Июл-20, (46)

Да просто на самом деле правда жизни такова что GRUB жирная и фичастая скотина, , Аноним (57), 08:47 , 30-Июл-20, (57) +3
Эти санитайзеры ругаются на функции glibc Приходится заменять на аналоги, на ко, Аноним (60), 08:55 , 30-Июл-20, (60) –1

Они много на что ругаются И довольно часто - имея на это некий пойнт , Аноним (-), 09:07 , 30-Июл-20, (67)

p s в grub нет вызовов glibc P, Аноним (70), 09:12 , 30-Июл-20, (70)

Там ошибка в том, что присутствует киллерфича переполнение буфера, которое може, Аноним (89), 10:16 , 30-Июл-20, (89)

Валезание за пределы буфера заканчивается panic, который приводит к остановке пр, Forth (ok), 14:57 , 01-Авг-20, (272)

так это фича , Аноним (2), 00:23 , 30-Июл-20, (2) +31 //

Согласен, однако, значит ли это, что на упоротые ноутбуки с нетключаемым секуреб, Аноним (127), 14:12 , 30-Июл-20, (127) +5

А всё почему Потому что GRUB надо переписать на Rust , marios (ok), 00:41 , 30-Июл-20, (4) –10 //

и вообще всю ефи тоже на раст переписать , Аноним (21), 03:06 , 30-Июл-20, (22) +3 //

Так перепишите, кули А то все вы такие умные с вашими серебряными пулями Покаж, Аноним (31), 05:40 , 30-Июл-20, (31) +5
EFI лучше выуинуть к чертям собачьим Производитьелям материнок никто не запреща, Аноним (94), 10:27 , 30-Июл-20, (94) +6 //

Таки да Оно породило больше проблем, чем решило , None (??), 15:37 , 30-Июл-20, (150)

https www myinstants com instant counter-strike-go-go-go , Анином (?), 09:03 , 30-Июл-20, (65)
Минусующие не понимают в сарказм , Аноним (94), 10:25 , 30-Июл-20, (93) –1
на JavaScript, Вы забыли заполнить поле Name (?), 12:42 , 30-Июл-20, (121)
На Дерипаско , Аноним (231), 11:49 , 01-Авг-20, (268)

Локальный злоумышленник с административными привилегиями или с физическим досту, Антон (??), 00:46 , 30-Июл-20, (5) //

если у атакующего есть физический доступ к системе - дырка в грубом это меньшее , Аноним (6), 01:14 , 30-Июл-20, (6) +25 //

если у атакующего есть физический доступ к системе То перед ним открываютс, sysrise (ok), 04:15 , 30-Июл-20, (25) //

Это может быть обезьяна с подготовленной флешкой, обученная нажать несколько кно, lleeree_ (ok), 10:24 , 30-Июл-20, (92) +3

Да можно и просто с молотком Потеря машины и данных гарантирована , rshadow (ok), 15:18 , 30-Июл-20, (146) +1

Шуруповёрт надежнее , lleeree_ (ok), 16:58 , 30-Июл-20, (165)

Ну и какие у него шансы с Epyc, где есть TSME и FDE Скажем так не очень большие , хотел спросить (?), 06:58 , 30-Июл-20, (45) +1 //

Пункт 2 https www opennet ru openforum vsluhforumID3 121426 html 47, Аноним (49), 08:01 , 30-Июл-20, (48)

если факт несанкцированной перезагрузки установлен, то всё - система скомпромети, хотел спросить (?), 09:07 , 31-Июл-20, (210)

Вы серьезно на каждый проскок питания или что там у вас это делаете А не проще , Аноним (-), 07:55 , 01-Авг-20, (256)

в датацентре с аптаймом 99 99 какой-такой проскок питания грузить по сети через, хотел спросить (?), 06:07 , 02-Авг-20, (275)

Оптимизм это конечно круто, да Еше скажи что ты полностью понимаешь как все это, Аноним (57), 08:56 , 30-Июл-20, (61)

Читаю не списки а профильные сайты И да я смотрел конференцию CCC где эпики раск, хотел спросить (?), 09:16 , 31-Июл-20, (211)

Однако ж CVE были и в PSP и в ME И что характерно, хаксорский код потом вообще , Аноним (247), 18:40 , 31-Июл-20, (247)

Вот, еще один Аноним задался правильным вопросом https www opennet ru openforu, Аноним (81), 09:10 , 30-Июл-20, (68) +1 //

Похерили http techrights org 2020 07 30 wontboot , Аноним (290), 14:41 , 03-Авг-20, (290)

Ну а что мешает ровно таким же образом вместо grub cfg подменить ядро инитрамфс , Аноним (7), 01:14 , 30-Июл-20, (7) +1 //

Для самых внимательных в статье прям картинка есть - подпись ядра проверяется пр, Аноним (8), 01:19 , 30-Июл-20, (8) //

Кем должно проверяется ядро если в процессе загрузки используется grub Вниматель, Аноним (81), 08:49 , 30-Июл-20, (58) //

Grub, разумеется , Аноним (206), 08:41 , 31-Июл-20, (206)

Ну как бы SecureBoot именно против такой подмены и существует Ты загоняешь в пр, AnonPlus (?), 01:36 , 30-Июл-20, (11) //

Вот та часть вместо может и не получиться Потому что они предустановлены и не, Аноним (31), 05:43 , 30-Июл-20, (32) –2 //

Это только если биос кривой, ну или еще если это ноут по акции с Microsoft купле, Аноним (35), 05:54 , 30-Июл-20, (35)

Ну, блин, биос по жизни так или иначе кривой Другим он просто не бывает Уж доп, Аноним (-), 09:00 , 30-Июл-20, (64) –1
Просто не покупай Surface и подобные железки, где ключи нельзя вытряхнуть Во все, AnonPlus (?), 02:12 , 31-Июл-20, (194)

На железке заранее не написано - можно там или нельзя Увы, это не особые паранои, Аноним (206), 08:36 , 31-Июл-20, (204)

Кто проверяет подписи 1 Самого UEFI перед его загрузкой и испоьнением 2 Ядро g, Аноним (81), 08:58 , 30-Июл-20, (62) –1 //

На интеле потенциально бутгад может Проблема в том что это подписывается ну воо, Аноним (-), 09:05 , 30-Июл-20, (66)

Зависит от производителя В идеале процессором аппаратно есть возможность шифров, Аноним (81), 09:29 , 30-Июл-20, (77) +1

С точки зрения покупателя - лотерея Без возможности оверрайда, если не угадал , Аноним (126), 14:10 , 30-Июл-20, (126)

Читать документацию перед покупкой системы На сколько я понял вхардкорен куда-то, Аноним (219), 10:37 , 31-Июл-20, (214)

Честно сказать юзеру что его держат за лоха Это не очень популярно Вхардкожен, Аноним (-), 19:36 , 31-Июл-20, (250)

Я подробностей реальной технической реализации не знаю Читал популярные, а не т, Аноним (258), 08:58 , 01-Авг-20, (262)

1 Никто, но есть такая прекрасная штука как TPM-модуль Задействуй его в процес, AnonPlus (?), 02:15 , 31-Июл-20, (195)

Уточнение, есть еще BootGuard, вот он может проверять подпись прошивки Но он ли, AnonPlus (?), 02:17 , 31-Июл-20, (196)

Вот, еще один Аноним задался правильным вопросом https www opennet ru openforu, Аноним (81), 09:11 , 30-Июл-20, (69) –1 //

Однако демьян апдейты grub все же выкатил А то что она не эксплуатируемая в бол, Аноним (70), 09:14 , 30-Июл-20, (71) +1

systemd-boot рулит, systemd-boot неуязвим , foo (?), 01:20 , 30-Июл-20, (9) –4
Дыра в самом SB, но виноват grub think , Андрей (??), 01:30 , 30-Июл-20, (10) //

Переполнение буфера в grub, читаем внимательно, да , AnonPlus (?), 01:37 , 30-Июл-20, (12) +1 //

Там соль не в этом, а в том что он продолжил как ни в чем ни бывало пахать после, Аноним (31), 05:45 , 30-Июл-20, (33) //

Фатальная ошибка в загрузчике кирпич , Аноним (102), 11:44 , 30-Июл-20, (103) +1

Вы только подумайте, секурбут в лучшем для вас случае ничего не делает В случае, Аноним (129), 14:22 , 30-Июл-20, (129)

Поэтому в Linux есть режим lockdown, в котором хакерские модули грузить нельзя , kmeaw (?), 15:43 , 30-Июл-20, (151)

А прикольно о нем рассказать тому кто его как раз у себя и включил , Аноним (-), 19:51 , 31-Июл-20, (252)

Концептуально, в чем безопасность URFI секур бута если ошибка в приложении вне U, Аноньимъ (?), 11:18 , 01-Авг-20, (267)

Был же старый добрый MBR, работал и есть не просил Нет, обязательно надо выпенд, qbr (?), 01:42 , 30-Июл-20, (13) +8 //

Как реализовать сценарий secure boot с MBR Где будет лежать подпись Напомню, ч, kmeaw (?), 02:05 , 30-Июл-20, (14) –2 //

Ваш комментарий подразумевает, что реализация сценария secure boot - это что-то , Аноним 80_уровня (ok), 02:33 , 30-Июл-20, (19) +16 //

Это что-то в некоторых случаях небесполезное, т к усложняет эксплуатацию физиче, DerRoteBaron (ok), 02:43 , 30-Июл-20, (20) +2

закрой свой комп в тумбочку, ключ раствори в кислоте профит Некоторые неради, Аноним (21), 03:12 , 30-Июл-20, (23) +2
Это защита от руткитов, которые подменяют ядро на свое собственное Это не защит, RADV (?), 11:53 , 30-Июл-20, (109)
А нельзя было просто в биосе прописать, что без ввода пароля от биоса запретить , Аноним (114), 12:08 , 30-Июл-20, (114)

Можно снять крышку, вытащить диск, переписать на нём загрузчик и поставить обрат, kmeaw (?), 12:21 , 30-Июл-20, (117)

Если каждый легко может стать vendor-ом, то смысл в vendor lock пропадает и этой, kkk (??), 12:37 , 30-Июл-20, (120) +1
Можно получить рута на компе, прописать хлам в загрузочный раздел сектор и д, Аноним (129), 14:27 , 30-Июл-20, (130) +1

А если диск зашифрован Злоумышленнику очень бы хотелось заменить загрузчик на т, kmeaw (?), 15:24 , 30-Июл-20, (148) +1

А что помешает злоумышленнику добавить свой ключ в список доверенных SB Если же, Аноним (-), 06:25 , 31-Июл-20, (198)

Сделать IPL и первую статию загрузчика наглухо readonly А вот дальше в них чека, Аноним (31), 05:50 , 30-Июл-20, (34) +1 //

А как обновлять этот IPL тогда И в 440 байт сложно уместить алгоритм проверки п, kmeaw (?), 12:15 , 30-Июл-20, (115)

1 А что если никак Зачем вам обновлять мелкий прелоадер Вы же не обновляете , Аноним (132), 14:40 , 30-Июл-20, (132)

Вы уверены, что сможете с первого раза написать идеальный прелоадер без ошибок , kmeaw (?), 15:20 , 30-Июл-20, (147)

Ну, во первых, с 1 раза и не надо - зачем вам устраивать локаут себе на тестово , Аноним (-), 11:02 , 31-Июл-20, (217)

А зачем вообще нужен secure boot, кроме как для vendor lock , kkk (??), 12:07 , 30-Июл-20, (113) //

Чтобы злодей, кратковременно получивший физический доступ к оборудованию или чер, kmeaw (?), 12:16 , 30-Июл-20, (116)

Нет, чтобы ты не дай бог, не поставил себе чего-то несертифицированного , kkk (??), 20:31 , 30-Июл-20, (178)

Злодей, имеющий физ доступ, может прописать свои ключи в биос Поэтому secureboo, Павел (??), 07:34 , 31-Июл-20, (202)

Я прямо в предвкушении был этого комментария, открывая текст новости Образцовый, Annoynymous (ok), 02:26 , 30-Июл-20, (18) –3 //

Он досих пор наверное под MSDOS сидит с дисками 100Мб, Аноним (35), 05:59 , 30-Июл-20, (37) //

В этом все линуксоиды, взять и извратить до абсурда мысль собеседника -Я не хочу, Адекват (ok), 06:43 , 30-Июл-20, (43) –3

У меня MBR работает до сих пор, главное, чтобы размер свободного места в начале , Аноним (81), 08:44 , 30-Июл-20, (55)
MBR не умеет в GPT, не умеет больше 4 физических разделов, не умеет разделы 2Т, Аноним (59), 08:52 , 30-Июл-20, (59) –1 //

не MBR не умеет, а отвратительные недостаточно модульные биосы, сделанные с расч, Аноним (60), 08:59 , 30-Июл-20, (63)
Ставь GPT и малюсенький раздел для BIOS GRUB, перед разделом boot и все у тебя , Аноним (81), 09:45 , 30-Июл-20, (83)
добавить поддержку никто не мешает - это всего лишь прочитать пару секторовво-пе, aa (?), 09:51 , 30-Июл-20, (84) –1
1 GPT - это раздутая и искуственно усложнённая система разделения диска 2 Боль, kkk (??), 11:35 , 30-Июл-20, (101) –1 //

GPT хорош наличием GUID у диска и раздела Это позволяет однозначно идентифициро, kmeaw (?), 12:35 , 30-Июл-20, (119) +1

Что ты понимаешь под однозначно идентифицировать разделы В MBR ты знаешь всё,, kkk (??), 13:25 , 30-Июл-20, (125) –1

После того, как система запустилась, ей может быть нужно найти раздел на диске , kmeaw (?), 15:36 , 30-Июл-20, (149) +1

Разве Linux до сих пор не умеет находить dev sda4 Как он вообще работал всё эт, kkk (??), 16:29 , 30-Июл-20, (159) –1

дедушка, вы таблетку от склероза забыли принять Если сожрали вместо нее эклер -, пох. (?), 17:30 , 30-Июл-20, (169) +1

Типичный напыщенный хам Это ты таблетку забыл принять Ты глуп и невежественен , kkk (??), 20:43 , 30-Июл-20, (179)

лол Дальше можешь не продолжать Дос ты видел только в ютубчике, а описание парт, пох. (?), 20:53 , 30-Июл-20, (180)

Эм, по-моему бутсектор логического диска не партишна искал нечто типа IO SYS и, Аноним (221), 11:38 , 31-Июл-20, (221)

Да, именно так А никак не на специальные секторах диска Именно поэтому IO SYS , kkk (??), 19:22 , 31-Июл-20, (249)
да ничего он не искал , в нем за вычетом bpb места еще меньше чем в mbr, и того, пох. (?), 10:25 , 01-Авг-20, (265)
Дурачок, когда же ты хотя бы просто посмотришь дамп бутсектора FAT Я уже не гов, kkk (??), 17:54 , 01-Авг-20, (273)
ты свой ник не в то поле вписал дамп бутсектора лолшта - FAT Отлично, просто, пох. (?), 16:28 , 02-Авг-20, (278)
Первый сектор файловой системы Посмотри что написано в первом секторе, дурачок , kkk (??), 09:27 , 03-Авг-20, (286)

Это ты DOS никогда не видел и даже не потрудился проверить то, что тебе говорят , kkk (??), 19:18 , 31-Июл-20, (248)

Специально для тебя https www youtube com watch v V5tMCTOcg8kБудь мужиком, при, kkk (??), 19:44 , 01-Авг-20, (274)

Замечательно умеет Только при очередной перезагрузке это может оказаться раздел, Sarcastic scutosaurus (?), 17:32 , 30-Июл-20, (172) +1

Ты вменяемый , AlexYeCu_not_logged (?), 20:56 , 30-Июл-20, (184)

Не знаю, давно не проверялся А что Или ты просто не в курсе, что инициализация , Sarcastic scutosaurus (?), 21:24 , 30-Июл-20, (187)

Т е про UUID ты не в курсе , AlexYeCu_not_logged (?), 22:08 , 30-Июл-20, (191)

UUID чего У раздела в случае msdos-разметки нет никакого UUID Они могут быть у, Sarcastic scutosaurus (?), 16:34 , 31-Июл-20, (242) +1
Ну почитал у гражданина какие-то невнятные проблемы с поиском раздела sdx он х, AlexYeCu_not_logged (?), 18:18 , 31-Июл-20, (244)
Проблема описана вполне внятно на разделе может быть нечто, не идентифицируемое, Sarcastic scutosaurus (?), 18:37 , 31-Июл-20, (246)
ну могу тебе показать машину, где именно при каждой, угадай где у нас сегодня ди, пох. (?), 10:39 , 01-Авг-20, (266) –1
И в чём у тебя проблема с лейблами Хоть руками mount -L делай, хоть в fstab их , Аноним (102), 12:12 , 01-Авг-20, (269)
то что ты даже не понял, о каких лейблах речь , пох. (?), 16:19 , 02-Авг-20, (277)
Заинтриговал , Аноним (102), 20:21 , 02-Авг-20, (279)
не, сам запутался - -L это именно оно, partition label в отличие от LABEL , кот, пох. (?), 03:11 , 04-Авг-20, (292)
Эээ 8230 А где этот partition label лежать-то должен В DOS disk label на кажд, Аноним (102), 22:45 , 04-Авг-20, (295)
в partition table, вестимо Если она, конечно, GPT Собственно, это одна из прич, пох. (?), 00:17 , 05-Авг-20, (297)
А, ты про GPT 8230 Просто выше-то MBR обсуждали Но и что в GPT можно имена ра, Аноним (102), 23:01 , 05-Авг-20, (301)
повторяю в той _единственной_ реальной ситуации, когда на самом деле могут возн, пох. (?), 18:49 , 06-Авг-20, (305)
Впрочем, можно их при желании в fstab зафигачить dev disk by-partlabel , Аноним (102), 23:04 , 05-Авг-20, (302)
о, научились Но, похоже, это фича ядер после 4 какой-то, мое так не умеет и тако, пох. (?), 13:38 , 06-Авг-20, (303)
На, дарю ENV ID_PART_ENTRY_SCHEME gpt , ENV ID_PART_ENTRY_NAME , SYMLIN, Аноним (102), 16:05 , 06-Авг-20, (304)
ты мне лучше найди куда вставить создание этих меток Причем - динамическое При, пох. (?), 18:55 , 06-Авг-20, (306) –1
Э не, вот это уже только за деньги , Аноним (102), 11:41 , 07-Авг-20, (307)
то что в fstab вместо них автоматически записывается неведомая вредная херня мен, пох. (?), 03:18 , 04-Авг-20, (293) –1
В случае с dd лейблы никак не помогут, с ними ровно такая же путаница будет , Аноним (102), 22:50 , 04-Авг-20, (296)
лэйблы помогут - тем что ты это увидишь и сможешь понять, где какой - если я сей, пох. (?), 00:23 , 05-Авг-20, (298) –1

При наличии одного SATA контроллера с несколькими портами Ты уверен Кроме того , kkk (??), 19:50 , 31-Июл-20, (251)

0_0 Эм, а вы вообще etc fstab видели когда-нибудь , AlexYeCu_not_logged (?), 20:55 , 30-Июл-20, (182)

всяких бакланов, подпихивая им небольшое персональное клеймо , Аноним (-), 14:51 , 30-Июл-20, (133) –3

не будь лохом, скопируй uuid у другого баклана правда, потом будет немного обид, пох. (?), 20:55 , 30-Июл-20, (183)

Ну, давай сюды свой Так зачем же CP копировать, толко гуид , Аноним (221), 11:39 , 31-Июл-20, (222)

держи e139ce78-9841-40fe-8823-96a304a09859дык cp найдет товарищмайор, и решит ч, пох. (?), 00:30 , 05-Авг-20, (299)

Решается на уровне ОС, а за её пределами 8212 зачем , AlexYeCu_not_logged (?), 20:53 , 30-Июл-20, (181) –1

Да блин, что за каша в головах у людей Если имеете в виду grub-pc, то так и пиш, Аноним (102), 11:50 , 30-Июл-20, (105) +3

Критическая необходимость , Аноним (15), 02:09 , 30-Июл-20, (15) +2
Когда трудности нет, то что тогда преодолевать , Alexey (??), 02:11 , 30-Июл-20, (16) //

Возьми шмот и айда в горы, узнаешь , Аноним (36), 05:56 , 30-Июл-20, (36) //

Куда ты его посылаеш Там сдохнуть вполне реально Прочти статистику по РФ в го, Аноним (81), 08:37 , 30-Июл-20, (54) –1 //

К преодолению трудностей К тому же по своему прикольному Вообще, так по жизни , Аноним (70), 09:19 , 30-Июл-20, (72)

Русский не родной , Sgt. Gram (?), 11:51 , 30-Июл-20, (106) +1 //

Даже если был бы не родной, то как показать где должно быть разделение и как чит, Alexey (??), 19:03 , 30-Июл-20, (175) //

Да какое препинание Союзы научись употреблять Либо s когда если , либо s то г, Sgt. Gram (?), 21:35 , 30-Июл-20, (188)

Про союзы на regteston mail ru аж интересно стало, научи будь добр в данном конк, Alexey (??), 10:14 , 31-Июл-20, (213)

Что тебе непонятно Если что-то, то нечто Когда что-то, нечто И никак иначе , Sgt. Gram (?), 16:43 , 31-Июл-20, (243)

А почему нельзя Или он не Великий и могучий пиши разъяснения на почту с приме, Alexey (??), 20:56 , 31-Июл-20, (254)

Купи учебник, найми препода нормального не репетитора для ЕГЭ Ишь какой, на х, Sgt. Gram (?), 15:10 , 02-Авг-20, (276) +1

Тебе трудно указать где это правило, когда оно было введено и на основании чего , Alexey (??), 00:14 , 04-Авг-20, (291)

Чем оно лучше lilo , Аноним (17), 02:20 , 30-Июл-20, (17) +1 //

Оно лучше, чем lilo, Аноним (21), 03:13 , 30-Июл-20, (24) +1
Своей громоздкостью, глючностью и вечными проблемами, Аноним (35), 06:00 , 30-Июл-20, (39) //

А еще негуманоидным синтаксисом, реально нужно иметь степени по клинописи, крипт, Адекват (ok), 06:47 , 30-Июл-20, (44) +5 //

но к сожалению, альтернативно-одаренным его было никак не понять Поэтому он объ, пох. (?), 09:36 , 30-Июл-20, (80) +7

Так он и теперь помещается Просто он запускает более жирный лоадер, тот догружа, Аноним (-), 14:55 , 30-Июл-20, (135)

или не запускает, и ты сосешь лапу и бежишь за rescue диском а потом разгадывае, пох. (?), 16:23 , 30-Июл-20, (158)

Я видел много странной фигни, но вот именно такого ни разу не встречал За десят, Аноним (-), 12:02 , 31-Июл-20, (223)

зато https bugzilla redhat com show_bug cgi id 1861977 встретили это у lilo о, пох. (?), 00:59 , 05-Авг-20, (300)

grub2 menuentry Arch Linux Fallback set root hd1,msdos1 linux boot , kmeaw (?), 15:45 , 30-Июл-20, (152) +1

если бы еще и работал - то цены бы ему не было Только он у тебя не сработает - , пох. (?), 16:45 , 30-Июл-20, (163) +2

Ровно так у меня и работает Только сверху есть ещё кусок if loadfont EFI boot , kmeaw (?), 17:25 , 30-Июл-20, (168)

ох, да, как это - да чтоб в загрузчик сцуко - в ЗАГРУЗЧИК, Карл да не подгруз, пох. (?), 21:04 , 30-Июл-20, (185)

Так не подгружай Он всё равно будет работать Разве это плохо, когда фича есть,, kmeaw (?), 21:56 , 30-Июл-20, (190)

расскажи это вот теперь счастливеньким де6иллиано-убунтоюзерам У которых ночью , пох. (?), 08:52 , 31-Июл-20, (208)

Кстати, там что, ссылка на файл шрифта а если вместо шрифта будет какой-то сво, Адекват (ok), 07:08 , 31-Июл-20, (201) +1
Собственно, а почему бы загрузчику и не уметь нормально рисовать в гуевый режим,, Аноним (-), 08:46 , 01-Авг-20, (260)

Это для интеграции с пакетниками, апдейтами ядер и всем таким Теперь пакетник п, Аноним (259), 08:42 , 01-Авг-20, (259)

вы забыли добавить - написанными вчерародившимися, ниасиляторами sed Вот вам суп, пох. (?), 13:15 , 01-Авг-20, (270)

Нет, то что я показал - это реальный пример тех веремен, когда grub 0 97 был, а , Адекват (ok), 06:39 , 31-Июл-20, (200)

ну в первых же строчках все интуитивно-понятно - мы написали прекрасный конфиг , пох. (?), 09:02 , 31-Июл-20, (209) +3

Абсолютно Если что-то надо - айда менять ШАБЛОН А этот список динамический, , Аноним (-), 08:48 , 01-Авг-20, (261)

да, щас, щас, еще один нескучный язычок вызубрю только к0к0к0й ужос Ведь sed-то, пох. (?), 13:24 , 01-Авг-20, (271) +1

Какой смысл вообще использовать Secure Boot с GRUB Изначально понятно, что так , Аноним (26), 04:35 , 30-Июл-20, (26) +3 //

Доступ к bios может быть ограничен на уровне uefi, Аноним (27), 05:00 , 30-Июл-20, (27) //

UEFI давно уже выяснено ломается и из системы получается доступ к изменению наст, Аноним (38), 05:59 , 30-Июл-20, (38) +5

Ога, только ни рамдиск не положишь, ни командлайн не поменяешь небось Поэтому ф, Аноним (-), 05:22 , 30-Июл-20, (29) +2 //

ну вот этим должен был заниматься как раз grub или какая-нибудь его замена В ид, пох. (?), 16:32 , 30-Июл-20, (160)
Если прописывать ядро в nvram, то без проблем и командлайн, и initrd туда же мо, kmeaw (?), 17:31 , 30-Июл-20, (170)

Согласен GRUB ненужен как и другие загрузчики У меня ядро напрямую грузится из, Аноним (35), 06:03 , 30-Июл-20, (40) –1 //

Ramdisk и подпись для secureboot через gummiboot, Аноним (35), 06:06 , 30-Июл-20, (41)
У вас, простите, 1 ядро необновляемое В том же Дебе сразу после установки систе, ryoken (ok), 08:20 , 30-Июл-20, (51) //

Во всяких рачах ядро называется просто как-нибудь вроде vmlinuz-linux и раскатыв, Аноним (90), 10:18 , 30-Июл-20, (90)

Чё, правда Прямо поверх, не симлинком Отчаянные ребята , Аноним (102), 11:54 , 30-Июл-20, (110) +1
А если вдруг система с новым ядром не запустилась - мы произносим удивленное ух, Аноним (-), 14:58 , 30-Июл-20, (138) +1

это рач, они даже не удивляются не может загрузиться даже со старым ведром - вед, пох. (?), 16:34 , 30-Июл-20, (161)

бть Сглазил , пох. (?), 08:40 , 31-Июл-20, (205)

Чего Кернел Или сабжа , Аноним (-), 12:08 , 31-Июл-20, (225)

сабжа - реально все по моему сценарию и слуцилась этой же ночью - - и у убунтоид, пох. (?), 14:18 , 31-Июл-20, (233) +1

режьте ОСТОРОЖНЕЙ ц PS http bugzilla redhat com 1861977 -- оно PPS это у , Michael Shigorin (ok), 08:22 , 03-Авг-20, (285)

угу, и нифига так и не понятно - ни что это было, ни где запатчено в очередной р, пох. (?), 14:50 , 04-Авг-20, (294)

Ну так тем более - мне казалось, лезть каждый раз за загрузочной флехой должно б, Аноним (-), 12:07 , 31-Июл-20, (224)

да куда лезть, она ж у них напостой в разъем воткнута, только диск выбрать ой, , пох. (?), 14:21 , 31-Июл-20, (236)

Вот так достаточно , Аноним (102), 14:56 , 30-Июл-20, (137) +1

Дык там один из довереных ключей ms утек, так что не похрен ли Кто этого хотел , Аноним (-), 05:20 , 30-Июл-20, (28) +2 //

Что мешает пользователю самостоятельно положить этот ключ в dbx , kmeaw (?), 15:47 , 30-Июл-20, (153)
А можно ссылочку на ключ или сам ключ , Аноним (173), 18:58 , 30-Июл-20, (173) //

Я такое не коллекционирую, но на форониксе новость была про малварь подписанную , Аноним (-), 12:12 , 31-Июл-20, (226) +1 //

Ну там и ещё вариант был , Michael Shigorin (ok), 08:18 , 03-Авг-20, (284)

Хахаха, как обычно Жду от мамкиных экспертов визгов про кривые руки программисто, Fracta1L (ok), 06:41 , 30-Июл-20, (42) –6 //

1 Тебе надо прочесть учебник о защите памяти в OS Можно на C написать OS котора, Аноним (49), 08:27 , 30-Июл-20, (52) +1 //

Вот и начались мантры , Fracta1L (ok), 08:45 , 30-Июл-20, (56) –2 //

Ну так покажи нам, ракам, как чай в варежках пить Не, не покажешь Потому что п, Аноним (75), 09:23 , 30-Июл-20, (75) +1

Ну так покажи хоть одну используемую программу на Сишке без дыр, Fracta1L (ok), 10:06 , 30-Июл-20, (88) –1

Ну дык djbdns например А так что совсем без дыр и нафиченые проги - блин, поиме, Аноним (-), 15:04 , 30-Июл-20, (143)

Ахахахахаhttps www webcitation org 68AXHUSJp url http securityandthe net 200, Fracta1L (ok), 16:44 , 30-Июл-20, (162)

Это не сишная дыра, а логическая Такое на любом языке могло бы быть Гугли даль, Аноним (102), 17:18 , 30-Июл-20, (167)

Найс манявры , Fracta1L (ok), 07:43 , 31-Июл-20, (203) –1

Ну ладно, а вон те L4 и проч которые типа математически-доказаны ты ломать умееш, Аноним (-), 12:14 , 31-Июл-20, (227)

Вы пытаетесь спорить с упоротым глупцом, который мнит себя троллем Смысл Он , Michael Shigorin (ok), 08:17 , 03-Авг-20, (283)

Двоечник, марш за учебниками И чтобы до 1 сентября вот здесь https www openn, Аноним (219), 09:50 , 31-Июл-20, (212)

Linux PAX тебе ничего не говорит , Аноним (219), 11:20 , 31-Июл-20, (220) +2

Она для начала вызвана игнором ошибки парсера, а это уже следствие обшего undefi, Аноним (75), 09:22 , 30-Июл-20, (73) –1
Товарищ папкин эксперт, покажи-ка свой код Интересно, писал ли ты вообще на чём, Аноним (102), 11:57 , 30-Июл-20, (111)

Ха-ха-ха мы закинем в ваш раздел efi свою уязвимость что бы искать другие уязвим, Аноним (53), 08:31 , 30-Июл-20, (53)
Ужас-ужас А по сути - ничего собственно не произошло Как был весь этот секуребут, Онаним (?), 09:23 , 30-Июл-20, (74) +4 //

надеяться, Онаним (?), 09:23 , 30-Июл-20, (76) +2

Хм, это за частую даже удобно, можно спокойно заливать любые системы на эту бесп, svsd_val (ok), 09:35 , 30-Июл-20, (78)
так это ж не уязвимость, а True-функционал дурачок Мэтью Гаррет в ногах у микрос, Hellraiser (??), 09:35 , 30-Июл-20, (79) –1 //

Мальчик, ты дурачок В том и дело что НЕ может И вот те серьезные дядечки - ХРЕ, пох. (?), 09:43 , 30-Июл-20, (82) +1 //

девочка, не надо обзываться, это невежливо лучше расскажи нам сказку, что тольк, Hellraiser (??), 09:58 , 30-Июл-20, (85) //

Из коробки -- только с ним, увы По факту Отключение -- действие, которое дал, Michael Shigorin (ok), 08:15 , 03-Авг-20, (282)

Менюшек может просто не быть - вообще ну да - зайдите в менюшку _своей_операцион, пох. (?), 13:59 , 03-Авг-20, (287)

Именно благодаря этой уязвимости у меня получилось установить линукс на hp pav, Укуренный (?), 10:01 , 30-Июл-20, (86) –1 //

вобщем-то ничто не мешает сделать так, чтобы после обновления остался уязвимый , Hellraiser (??), 10:05 , 30-Июл-20, (87) +1

А может мне кто-нибудь доходчиво объяснить, зачем в реальном мире нужен SecureBo, mikevmk (??), 10:35 , 30-Июл-20, (97) +3 //

Загрузочные вирусы же Другое дело - кто их видел вобще за последние лет 5 , tolstushka.ru (ok), 10:51 , 30-Июл-20, (99) +1 //

Ну это ж никакой критики не выдерживаетТ е получается, что вендор лок как мало-, mikevmk (??), 11:22 , 30-Июл-20, (100) +1
На самом деле этот SecureBoot - ТОЛЬКО НАЗВАНИЕ И НИЧЕГО БОЛЬЕЕ Он НЕ SECURE, о, InuYasha (??), 11:49 , 30-Июл-20, (104) //

СПАСИБО, БОЛЬШИЕ БУКОВЫ ЛУЧШЕ ВИДНО, RADV (?), 11:52 , 30-Июл-20, (107) +5

В реальном мире на фиг не нужен В идеальном же должна выполняться проверка подп, Аноним (102), 12:01 , 30-Июл-20, (112) +1 //

к этому и ведут облачные ОС, облачные программы, всех в сад инет, Аноним (21), 12:27 , 30-Июл-20, (118) //

Ты правда думаешь, что там девляпсы что-то проверяют , Аноним (102), 14:59 , 30-Июл-20, (141)

это не идеал, это антиутопия, vitalif (ok), 14:59 , 30-Июл-20, (140) //

Иедальный, от слова идея 8212 воображаемый, на практике недостижимый Идеал, Аноним (102), 15:02 , 30-Июл-20, (142)

ну, допустим есть сервер банка и нужно защитить его от руткитов режима ядра, Нанобот (ok), 12:52 , 30-Июл-20, (122) –4 //

Ты кейс целиком расскажи А то это получается как турникеты в школах против терр, mikevmk (??), 13:24 , 30-Июл-20, (124) +4 //

Ну как-то так 1 прихожу в банк2 захожу в серверную3 вставляю флэшку с руткито, Аноним (21), 14:17 , 30-Июл-20, (128) –1

А охрана банка, соответственно, спокойно на все это втыкает А не проще было тог, Аноним (-), 15:07 , 30-Июл-20, (145) +4

охрана втыкает нервно - потому что из стены в серверную хлещет дерьмо, и он вооб, пох. (?), 17:11 , 30-Июл-20, (166)

не надо судить о взломе банков по американским фильмам , Аноним (21), 20:10 , 30-Июл-20, (177)
Понятно Помогает только при съемке попсовых фильмов про хакеров, и то приходитс, Аноним (-), 12:20 , 31-Июл-20, (228) +1

да в чем проблема-то Было бы мне надо - вполне мог бы что-то в этом роде исполн, пох. (?), 12:38 , 31-Июл-20, (229)

допустим, я уже работаю в этом банке и имею полный доступ но в один прекрасным , Нанобот (ok), 17:32 , 30-Июл-20, (171)

Если есть полный доступ можно и программатор принести и переписать всю уефину на, Аноним (173), 19:05 , 30-Июл-20, (176) +1
это просто невозможно Код ядра безусловно подписан какой-то подписью, а вот вся , пох. (?), 21:14 , 30-Июл-20, (186) –1

да, 100 защиты системы оно не даёт, оно защищает только одну конкретную область, Нанобот (ok), 14:19 , 31-Июл-20, (234)

ну да, о том и речь - от другой совсем модели угроз, нежели полноправный админ с, пох. (?), 14:27 , 31-Июл-20, (237)

чьей именно цифровой подписью , Аноним (-), 06:29 , 31-Июл-20, (199)

цифровой подписью разработчика операционной системы, Нанобот (ok), 14:20 , 31-Июл-20, (235)

SecureBoot 8212 это гибкая альтернатива перемычке read-only на загрузочном но, kmeaw (?), 15:53 , 30-Июл-20, (155)

Не баг, а фича , Zenitur (ok), 11:53 , 30-Июл-20, (108) +4
Атакующий столкнет меня с моего места и взломает граб чтобы добраться до UEFI У, RedEyedMan (ok), 14:35 , 30-Июл-20, (131)
GRUB, GRUB2, LILO - это всё эпоха древнего Биоса Парни сейчас эпоха UEFI, давай, Аноним (-), 14:51 , 30-Июл-20, (134) –5 //

Не дёргайся, они и UEFI благополучно переживут , Sarcastic scutosaurus (?), 15:05 , 30-Июл-20, (144) +3
угу, systemd-boot наше всь стоп, но это не загрузчик Он ничего без дурацкого, пох. (?), 16:58 , 30-Июл-20, (164) +1

Надоели мне эти уязвимости Физический доступ к девайсу должен означать полное, vitalif (ok), 14:58 , 30-Июл-20, (139) +2 //

Тогда нельзя будет реализовать защиту от подмены компьютера или его частей, когд, kmeaw (?), 15:55 , 30-Июл-20, (156) +1 //

Забавно, что именно те, кто на самом деле работает с секретными данными, таки пр, AlexYeCu_not_logged (?), 00:15 , 31-Июл-20, (192) +2 //

Им проще обойтись физическими регламентами и по старинке поставить по парню с пу, kmeaw (?), 01:56 , 31-Июл-20, (193) –1

Облако в недоверенных руках будет тебе по пятницам 13-го выдавать 2 2 5 И не ср, Аноним (21), 04:14 , 31-Июл-20, (197)
Забавно , AlexYeCu_not_logged (?), 18:21 , 31-Июл-20, (245)
Дурацкая задача, на руку только проприерастам, vitalif (ok), 01:39 , 03-Авг-20, (280)

Буквально неделю назад думал себе на ноутбуке поменять GRUB 2 на Syslinux или LI, Аноним (154), 15:50 , 30-Июл-20, (154) +2
Это фича, srgazh (?), 21:35 , 30-Июл-20, (189)
Выстрел в пятку засчитан , pin (??), 13:54 , 31-Июл-20, (232)
Если у кого-то шляпа не загрузится после штатных обновлений -- это сюда http , Michael Shigorin (ok), 08:08 , 03-Авг-20, (281) –1

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

13. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +8 +/–

Сообщение от qbr (?), 30-Июл-20, 01:42

Был же старый добрый MBR, работал и есть не просил. Нет, обязательно надо выпендриться и придумать какую-то неведомую хрень, вместо развития уже работающей технологии. В большенстве случаев MBR продолжает работать и сейчас, но в некоторых недо-дистрибах его уже не поддерживают. Уроды!

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

14. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –2 +/–

Сообщение от kmeaw (?), 30-Июл-20, 02:05

Как реализовать сценарий secure boot с MBR? Где будет лежать подпись? Напомню, что размер IPL — всего 440 байт.

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

19. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +16 +/–

Сообщение от Аноним 80_уровня (ok), 30-Июл-20, 02:33

Ваш комментарий подразумевает, что реализация сценария secure boot - это что-то нужное, если не необходимое.

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

20. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +2 +/–

Сообщение от DerRoteBaron (ok), 30-Июл-20, 02:43

Это что-то в некоторых случаях небесполезное, т.к. усложняет эксплуатацию физического доступа к оборудованию

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

23. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +2 +/–

Сообщение от Аноним (21), 30-Июл-20, 03:12

> эксплуатацию физического доступа
закрой свой комп в тумбочку, ключ раствори в кислоте... профит! Некоторые нерадивые рабовладельцы так и делают.

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

109. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от RADV (?), 30-Июл-20, 11:53

Это защита от руткитов, которые подменяют ядро на свое собственное. Это не защита от физического доступа.

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

114. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (114), 30-Июл-20, 12:08

А нельзя было просто в биосе прописать, что без ввода пароля от биоса запретить загружаться со всяких флешек и СД ?

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

117. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kmeaw (?), 30-Июл-20, 12:21

Можно снять крышку, вытащить диск, переписать на нём загрузчик и поставить обратно.
Можно найти баг в загрузчике или ОС, получить рута и переписать загрузчик.
Secure Boot в таких случаях защитит пользователя, так как откажется грузиться в скомпрометированную систему.
Тут конечно остаётся вопрос, раз злоумышленник смог проникнуть в систему, то он и повторить это сможет. Но это должно решаться обновлениями безопасности.
Vendor-lock это хорошо, если каждый без особых усилий может стать vendor'ом — выпускать свои подписанные загрузчики и ядра. А спецификация Secure Boot требует наличия возможности загрузить пользовательские ключи, против которых проверяется загрузчик ОС.

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

120. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от kkk (??), 30-Июл-20, 12:37

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

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

130. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от Аноним (129), 30-Июл-20, 14:27

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

> Secure Boot в таких случаях защитит пользователя, так как откажется грузиться в
> скомпрометированную систему.
Но это в основном теоретически, практически мс зассал кашпировский буткит используемый хакерами зарубать потому что это и легитимным юзерам системы кирпичило заодно.
> Vendor-lock это хорошо, если каждый без особых усилий может стать vendor'ом — выпускать свои
> подписанные загрузчики и ядра. А спецификация Secure Boot требует наличия возможности
> загрузить пользовательские ключи, против которых проверяется загрузчик ОС.
А теперь коронный номер - попробуйте сменить гранд-мастер-ключ, которым блобы ME подписаны. А, не получается? Ну вот то-то - сразу и видно, кто настоящий вендор, а кто так, покурить вышел. И в этой схеме настоящий вендор вас конечно же этсамое, по иерархии.

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

148. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от kmeaw (?), 30-Июл-20, 15:24

> Можно получить рута на компе, прописать хлам в загрузочный раздел/сектор и ... даже диск вынимать не надо.
А если диск зашифрован? Злоумышленнику очень бы хотелось заменить загрузчик на тот, который запомнит ключи или попатчит ещё что-нибудь, когда легитимный пользователь загрузит свой компьютер.
Secure Boot не даст ему загрузиться после такого вмешательства.
> А теперь коронный номер - попробуйте сменить гранд-мастер-ключ, которым блобы ME подписаны.
А что вы хотите поменять в ME? Вы же не требуете от процессора быть реализованным на FPGA.
И Secure Boot никак не защищает ME.
Единственное отличие "настоящего вендора" от меня в том, что если я решу разработать свой болдженос, то он не загрузится на машине со включенным Secure Boot и настройками по-умолчанию — придётся либо выключить Secure Boot, либо сделать provisioning.

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

198. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (-), 31-Июл-20, 06:25

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

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

34. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от Аноним (31), 30-Июл-20, 05:50

> Как реализовать сценарий secure boot с MBR?
Сделать IPL и первую статию загрузчика наглухо readonly. А вот дальше в них чекать подписи уже. Злоумышленник не сможет их перезаписать - и, соответственно, перехватить управление. Ну и коли это честно проверит подписи - то собственно дело в шляпе.
И таки я примерно так и делаю на некоторых одноплатниках, где в качестве boot media - sd card или spi nor, там либо аппаратный WP# есть, либо однократно выставляемый навечно флаг "readonly media" (в управляющих структурах SD card). При этом от чипа вообще не требуется уметь в secure boot - некий аналог "донавешен позднее", что впрочем совершенно не мешает. Эту идею озвучивал еще гугл с своими хромобуками лет наверное 10 назад. Нормальная идея, достигает то же самое без дикой оверинженерии как в уефанстве.

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

115. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kmeaw (?), 30-Июл-20, 12:15

А как обновлять этот IPL тогда?
И в 440 байт сложно уместить алгоритм проверки подписи.
Смысл всех этих BIOS Guard, Secure Boot, Trusted Boot, TPM, Measured Boot в том, что система не жёстко фиксируется на readonly-носителе, а может обновляться, но не злоумышленником.

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

132. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (132), 30-Июл-20, 14:40

> А как обновлять этот IPL тогда?
1) А что если никак?! Зачем вам обновлять мелкий прелоадер? Вы же не обновляете бутром на кристалле... ну а это вот будет вашим аналогом того рома. С ровно той же фичой - атакующий не может это перефигачить под себя.
2) Если очень надо - в случае SPI NOR можно хардварный сигнал WP# юзать. Что с ним сделать?! Ну, самое очевидное - на железный джампер или кнопку загнать. Вот это как минимум ремотный атакующий совершенно точно оспорить не сможет. А локальный с физическим доступом один черт может очень много всего интересного. Вплоть до осмысленного пуляния сфокусированным рентгеном в нужную область проца в правильное время, если вопрос будет на миллион.
Более продвинутый вариант - микроконтроллеру этот пин отдать. С защищенной от чтения извне прошивкой, конечно, дабы пароль не стыбзили из МК. Ну и дальше - фирмвара мк может спросить "boot update password" например. Скажете правильно - фирмвара дернет лапку МК, снимет сигнал WP# с чипа, и пишите себе свою флеху апдейтом - доказав что вы owner. Не угадали? Ну вот вам отключение ввода пароля до следующего полного poweroff, WP# остается в залоченом состоянии, основной проц это никак оспорить не сможет - он не контролит WP# напрямую. С SD так не прокатит, там хардварного пина блокировки записи нет в отличие от spi nor чипов.
> И в 440 байт сложно уместить алгоритм проверки подписи.
Не обязательно. Рассматривайте его + более крупную стадию как одно целое и отправьте оба в ридонли область. Все что 440 байтов будут должны - подчитать более жирный бут из ридонли и запустить его. Поскольку атакующий не может его заменить - оно ж ридонли - то и проблемы в этом нет.
> Смысл всех этих BIOS Guard, Secure Boot, Trusted Boot, TPM, Measured Boot
> в том, что система не жёстко фиксируется на readonly-носителе, а может
> обновляться, но не злоумышленником.
Смысл всей этой гадости - убедить лоха в том что у него типа-есть-контроль. А реально - фирма интел всегда может подписать своим ключом early boot своего ME. ME всегда возьмет под козырек и выполнит то что интел попросил. И вы не можете отнять у фирмы Интел эту возможность полностью и окончательно. Более подробный анализ этих подарочков есть у positive techs например. Как и некие способы перехвата. Однако это все же не отменяет того факта что бутром ME всегда охотно выполнит код подписаный интелем - и только им, это будет иметь доступ в все закоулки - и нет никакого способа радикально и совсем вырубить фирме Интел такую возможность.

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

147. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kmeaw (?), 30-Июл-20, 15:20

> 1) А что если никак?! Зачем вам обновлять мелкий прелоадер?
Вы уверены, что сможете с первого раза написать идеальный прелоадер без ошибок? Я скорее всего не смогу, и хотелось бы расчитывать на какую-то внешнюю систему для проверки подписи, дающей возможность выпустить новую версию (и заодно отозвать старую).
> Вы же не обновляете бутром на кристалле... ну а это вот будет вашим аналогом того рома. С ровно той же фичой - атакующий не может это перефигачить под себя.
Когда в ROM обнаруживается ошибка, всё становится очень плохо. Но у производителя чипов больше ресурсов, чем у меня (и у большинства разработчиков ОС), поэтому это должно происходить не слишком часто.
> Ну, самое очевидное - на железный джампер или кнопку загнать.
Представьте, что вы работаете в компании, и в ваши обязанности входит обслуживание рабочих мест сотрудников, которых сотни.
Вот вышла новая версия ОС, в которой обновились критические компоненты (в частности ядро). Как массово накатить обновление? С boot update password конечно всё здорово придумано, но в PC такого пока что нет (что-то похожее есть на новых маках). Зато есть Secure Boot, который эту проблему решает. Вместо password используется подпись.
> Не обязательно. Рассматривайте его + более крупную стадию как одно целое и отправьте оба в ридонли область. Все что 440 байтов будут должны - подчитать более жирный бут из ридонли и запустить его. Поскольку атакующий не может его заменить - оно ж ридонли - то и проблемы в этом нет.
Не получится. Всё, что знает BIOS - это то, что с диска надо загрузить первый сектор и передать туда управление. Что будет грузиться дальше, какой layout у выдуманных мной структур, ему уже неизвестно. Значит единственное место, у которого он сможет проверить подпись (если бы такая функция была бы реализована) — это IPL. Чтобы построить цепочку доверия, внутри этого IPL должен располагаться код, который загрузит всё остальное, проверит подпись и передаст управление в случае успеха. А места для этого маловато. Так что остаётся только вариант с уводом в read-only, а обычный PC с обычными жёсткими дисками так (увести в r/o первые N килобайт) не умеет.
> Смысл всей этой гадости - убедить лоха в том что у него типа-есть-контроль.
Смысл всех этих мер не в абсолютной защите от всех-всех подряд. От производителя процессора вы всё равно защититься не сможете. Все эти меры, правильным образом задеплоенные, позволяют защититься всего от двух атак:
1) злоумышленник смог кратковременно получить контроль, и, переписывая критические компоненты системы, хочет закрепиться надолго;
2) компьютер является частью какой-то распределённой системмы; пользователь этого компьютера и есть злоумышленник — он выкинул рабочий компьютер и заменил его (по частям или целиком) своим, и пытается выдать его за оригинальный, чтобы украсть или исказить данные этой системы.
Intel, разумеется, может провернуть любую из этих атак, и является стороной, которой мы вынуждены доверять.
Заметьте, что Intel сделал ME, микрокод и много ещё что обновляемым, чтобы сохранить возможность исправлять свои собственные ошибки. Путь "сделать с первого раза всё правильно и увести в readonly" слишком сложный.
Если не быть активистом фонда СПО, то в ME нет ничего особенно плохого. vPro по-умолчанию выключен. На мой взгляд, единственное, что в ME работает лично против меня, это возможность по-разному инициализировать одинаковые кристаллы, создавая ценовую диверсификацию — блокировка множителя, ограничение частоты памяти. Если бы ME был СПО, то я бы мог всё это выключить. Но тогда бы было невозможно защититься от атаки #2 (см. выше), так как у ME не было бы возможности доказать свою собственную подлинность. Так что можно рассматривать процессор Intel и блоб Intel ME, как единый программно-аппаратный комплекс.
Некоторый вред есть от сторонних компонентов (option ROMs, модули UEFI, код SMM), которые написаны непонятно кем, часто сомнительного качества, и которым пользователь вынужден доверять. Но в большинстве случаев их можно выкинуть, а то и вовсе заменить весь биос на открытый coreboot.
Так можно договориться до того, что я не могу изменять топологию интегральных (микро)схем, и поэтому у меня недостаточно контроля. Контроля достаточно для того, чтобы собрать новый образ ОС, подписать его и разлить по всем маишнам. А также обновить все обновляемые блобы.

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

217. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (-), 31-Июл-20, 11:02

> Вы уверены, что сможете с первого раза написать идеальный прелоадер без ошибок?
Ну, во первых, с 1 раза и не надо - зачем вам устраивать локаут себе на тестово дебажных версиях? А вот после проверки что все ЗБС - гайки завинтить :)
Во вторых - если вы не можете написать без факапов даже, блин, 440-байтный код :D, тогда вам придется наверное признать что это - не ваше! :D Нене, рассаду выращивать я вам советовать не буду, там можно встать на грабли или порезаться огурцом.
В третьих, если ну очень хочется - я ж описал вариант где хардварно снимается WP и вперед, апдейтить. Сие потребует нажать кнопу или переставить джампер, подтвердив физическое присутствие. Гугол так на хромобуках делал, неплохо придумано. И сильная защита от ремотных физиономий, которые кнопку нажать все же не могут, и можно сделать полный оверрайд на вообще свой код с самого начала, зажав эту кнопку. Ну а дальше вы уже отвечаете за безопасность системы сами и гугл умывает руки, теперь это целиком ваше добро.
> Я скорее всего не смогу, и хотелось бы расчитывать на какую-то
> внешнюю систему для проверки подписи, дающей возможность выпустить новую версию (и
> заодно отозвать старую).
Ну вот вам и подогнали счастья. Только в результате как это и бывает оно в результате как-то делает больше всего фавора в общем то и не вам, а для вас только достаточно декоративная иллюзия контроля. А своим хозяевам эта пакость фавор норовит сделать и не спрашивая вас особо. При том это идет настолько далеко, что хозяева отказываются даже минимально щемить себе йайцы, поскольку их видите ли за это натягивают злые кастомеры. И они как-то вот решают что лучше нехай вам хакеры грузят черти-что через буткит касперского чем у их кастомеров компы закирпичатся. И безопасТность полчается в результате характерная - у юзера куча грабель, особенно если он удумал шаг в сторону, хакеры вообще не имеют проблем, а тут еще какие-то вендоры в режиме супербогов порой объясняют с п0нтом под з0нд0м что на свежекупленый ноут вы имеете право поставить либо вон ту восьмерку, либо вон тот рхел. И хватит с вас!
> Когда в ROM обнаруживается ошибка, всё становится очень плохо.
На этот случай я описал вариант с WP# где если сильно надо, он снимается. Но только локальным физически присутствующим телом с полным доступом к железке - такой мог и рентгеном пшикнуть вовремя, если сильно надо.
> Но у производителя чипов больше ресурсов, чем у меня (и у большинства разработчиков ОС),
> поэтому это должно происходить не слишком часто.
И что характерно - они предпочли эти ресурсы использовать не для защиты юзерей от проблем, а для навязывания что вы можете и не можете. Бабло побеждает зло. Эта мышиная возня была затеяна в основном потому, что MS лавры фирмы Эпл покоя не дают. Им кажется хочется загнать всех в стор и заставить покупать софт и контент только там.
> Представьте, что вы работаете в компании, и в ваши обязанности входит обслуживание
> рабочих мест сотрудников, которых сотни.
Представьте, что вы работаете в компании. А теперь представьте что малваре ... тихой сапой закрепится на десяточке из компов, в регионах памяти где никакой антивирь это в принципе вышибить не может. А, погодите, всякие equation примерно так и делают, ололо :)
> Вот вышла новая версия ОС, в которой обновились критические компоненты (в частности
> ядро). Как массово накатить обновление?
Упомянутая схема вообще никак не мешает апдейтить что либо - покуда вы можете подписать это (или оно подписано доверенным ключом). Это "навесной вариант secure boot", где железный root of trust создается нами, известно из чего и понятно почему ему можно доверять. А когда это чей-то ME ROM и огромное блобваре где черт ногу сломит - это довольно голимый root of trust. На гнилом фундаменте нельзя построить хороший дом.
> С boot update password конечно всё здорово придумано, но в PC такого пока что нет
> (что-то похожее есть на новых маках). Зато есть Secure Boot, который эту проблему
> решает. Вместо password используется подпись.
Вон тот password (или нажатие кнопки для снятия WP#) надо только для апдейта "root of trust" (начальной фазы загрузки, смыслового аналога boot ROM). В более поздних фазах когда все уже раскочегарено можно юзать и обычные подписи уже, после того как root of trust проверил что ему те ключи более поздних фаз катят, конечно. Всякие ME и бутгады тоже так делают - там вшит хэш убер-мастер-ключа, обычно куда-то в OTP ROM ("efuses"). И начальный ром проверяет что у первого ключа хэш вот такой. Тот кто владеет этим ключом и является настоящим owner'ом. И как вы уже поняли это ессно не вы.
В ARM чипы часто идут с фабы чистыми - fuses не прошиты, и можно вообще активировать секурбут самому и вшить хэш именно своего мастерключа. На x86 (и некоторых ARM) таки решили что морда у вас таких красивых от такого контроля и такой безопасности все же треснет - так что это отжимает себе вендор, а вам голимненькая иллюзия что вы там чем-то типа-управляете.
А изначально вопрос был можно ли и как что-то такое сделать с MBR или чем-то подобным. Ну вот я и показал что да, можно и с чем-то таким, если сильно хочется. Понадобится media которую можно сделать readonly. В случае ARM, даже без активированного секурбута в железе, такая схема может быть довольно эффективна т.к. глуповатый бутром чипа только пинает наш бут с карты или spi флехи, и если вот это будет readonly, никаких проблем рассмотреть вот этот бут как root of trust где допустим вшит тот хэш начального мастерключа которым подписана следующая стадия. Такой себе "rom extension" с "навесным секурбут". А если очень сильно хочется то вот для spi rom его можно даже разрещить обновлять - если вон тот микроконтроллер по пути не отдающий свое содержимое наружу вдруг согласится махнуть лапкой правильно и разлочить чип на запись.
> Не получится. Всё, что знает BIOS - это то, что с диска
> надо загрузить первый сектор и передать туда управление.
Прекрасно - BIOS прочитает _READONLY_ лоадер. Хакер не сможет пропатчить это и сломать его логику. Этот лоадер дочитает из _READONLY_ зоны второй, более жирный и умный модуль. Хакер не может пропатчить и это. А вот этот модуль уже сможет и развернуть публичное крипто, и в себе вхардкодить мастеркей, которым подписаны следующие фазы. И поскольку оно readonly - заменить на свое хакеру это не катит. И придется жить с хэшом мастеркея которого у хакера нет, он видите ли где-то в загашнике. Ну вот такой навесной root of trust. Сие предполагает некие допущения, но то что это хуже того месива которое в uefi развели - можно поспорить.
MBR, видите ли, достаточно прост и туп для того... чтобы не стоять на пути почти любой идеи которая пришла в голову. А вот о наглом и интрузивном секурбуте это уже не скажешь.
> Что будет грузиться дальше, какой layout у выдуманных мной структур, ему уже неизвестно.
Это не важно. Важно чтобы 440 байтов были ваши, делали что вам надо и их нельзя было заменить на хакерские. И если сие безусловно подчитает из readonly зоны еще 100500 байтов, допустим, сразу после того бутсектора, то чего? Хакер не может патчить и это - и дальнейшее целиком на усмотрение этого кода. Если тот код решит в себе вхардкодить хэш мастерключа или даже всю публичную часть и будет далее запускать только то что им подписано - собственно, а как это оспаривать?! Покуда это readonly media, с которой биос грузится - сорян, но эта штука haves control и вполне может стать самопальным root of trust. Который нельзя вот так просто и нахрапом заменить, как и тот убер-ключ в boot rom, собссно :)
> Значит единственное место, у которого он сможет проверить подпись (если бы такая
> функция была бы реализована) — это IPL.
BIOS (или глуповатому boot ROM ARM чипа, ... ) вообще не надо ничего в этом месте проверять.
В этом случае, в этот момент доверие строится на том факте что вон то - именно наглухо READONLY media. Где хакер не может сменить код на что-то более полезное и кооперативное для себя - и поэтому данный код вполне катит как начальный якорь root of trust. При этом разумеется надежность этой штуки равна эффективности энфорса readonly. Это же касается и bios/boot rom запускающего сие шоу. В случае ARM с накристальным ROM сие достаточно неубиваемо - перешивать maskROM еще никто не научился, так что переубедить того вгрузить другой сектор с более полезным хакеру кодом - не выйдет. С BIOS - там вариантов больше, но это потребует продвинутый хакинг биоса и резко взвинчивает уровень атаки. Ну и если на то пошло, WP# и на флехе с биосом есть, можно и его в жесткий ридонли загнать, если системное фирмваре на такое не обидится. Корбут не обидится, bios/uefi - зависит от.
Рассматривайте действия биоса как "HW sequence" который слепо доверяет нашей первой фазе. Так же как чип ME или вон тот ARM слепо доверяет своему boot ROM, просто начиная исполнять это при ресете, полагаясь на тот факт что этот код в readonly зоне которая не меняется. А вот наша первая фаза может взять root of trust в свои лапы.
> Чтобы построить цепочку доверия, внутри этого IPL должен располагаться код, который
> загрузит всё остальное, проверит подпись и передаст управление в случае успеха.
Нет. В этот момент доверие в той схеме все еще держится на том факте что и довесок догружаемый мелким лоадером - все еще readonly.
Вообще, так можно и всю систему поднять - положить систему на, допустим, SD карту, запросить readonly на носитель после этого (у SD есть такая фича) - и усе, атакующий ничего сделать с этой штукой в принципе не сможет. Система всегда будет в том виде как она задумана. Западло состоит в том что это будет неудобно юзеру - и катит только для сильно некоторой встраиваемой мелочи. Где есть железная уверенность что слепленый образ 1 раз и навсегда. Для обычного компа это дубово и неудобно - и поэтому в какой-то момент надо все же что-то разрешить что-то обновлять. Иначе это слишком уж жестко и неудобно. Кроме того при этом не получится заапдейтить систему. Лулз состоит в том что малварь даже при дырах не может закрепиться в системе и ресет вышибает гуано наповал, см как это с мыльницами всякими работает.
> А места для этого маловато.
Только из-за узости вашего мышления. У вас столько места сколько вы захотите, покуда READONLY блок подчитывает другой READONLY блок и это остается именно READONLY, так что хакер не может заменить логику всего этого на более кооперативную. В этом месте контроль у того кода и никакой обход этой логики не предусмотрен. Если 440 байт лоадер откажется читать довесок, вы пролетаете, boot failed. Если довесок откажется запускать следующую стадию, вы опять же пролетаете. И что-то по этому поводу предпринять можно разве что локальной заменой readonly чипа/карты/чтотамувас, но там и много чего еще можно предпринять.
> Так что остаётся только вариант с уводом в read-only, а
> обычный PC с обычными жёсткими дисками так (увести в r/o первые N килобайт) не умеет.
Зато он допустим умеет грузится с, например, SD карты (как минимум через usb ридер). И вот оно умеет в RO целиком уходить по одной из команд SD спеков. Ну и вот будет такая R/O бутявка, с бутлоадером который root of trust. Ну да, послать ту команду - надо mmc хост или микроконтроллер, ридеры при гейтовании mass storage -> SD такими абстракциями не оперируют, конечно. И собссно SD карточка достаточно дешевая и простая чтобы ее и целиком под "boot ROM area" отдать, не? И ей даже супербыстрой или емкой быть не надо - по минимуму только 440 байтов и оверлей, just enough чтобы прочекать чтонить на writeable носителе :)
Алсо можно сделать себе usb-бутявку из какого-нибудь МК, где фирмварь может вообще обычную запись mass storage - unimplemented. А образ залить иначе (своим протоколом, инклудом в фирмвару). И хрен оспоришь. А если сильно хочется поиздеваться над хакерами, можно даже запретендовать что запись типа-прошла, ггг.
>> Смысл всей этой гадости - убедить лоха в том что у него типа-есть-контроль.
> Смысл всех этих мер не в абсолютной защите от всех-всех подряд.
И есть один нюанс. Эта штука большая и навороченная. И поэтому в ней много багов. Я видел, как один легендарный грандмастер вынес такую схему, да еще куда более секурный вариант. Нет, он не нашел переполнение буфера. Нет, он не сменил мастер ключ. Но он качественно наел RSA одним маленьким фокусом с экспонентой. Проверки прошли - и код грандмастера стал для девайса родным. Это то что вы получаете за навороченные алгоритмы и индусню не имеющую понятия как это работает. Небольшой щелк пальцами того кто понимает - и вся навороченая
> От производителя процессора вы всё равно защититься не сможете.
А тут вопрос в том атакует ли он. И если да - возможно надо сменить процессор. Или даже в совсем пиковой ситуации - стать производителем, если других вариантов не осталось.
> Все эти меры, правильным образом задеплоенные, позволяют защититься всего от двух атак:
> 1) злоумышленник смог кратковременно получить контроль, и, переписывая критические
> компоненты системы, хочет закрепиться надолго;
Как-то так. Упомянутые фортели тоже от чего-то такого в основном. Хотя в случае с МК например можно и более злостно потрепыхаться: при защите от чтения ключ уже не вытаскивается наружу. И если например диск пошифровать, сделав какой-нить key exchange, если МК будет не в настроении, доступ к системе будет урыт не только на модификацию, но и на изучение содержимого. Что впрочем не сильно спасет от случая когда хакер влез в систему где уже все подцеплено.
> 2) компьютер является частью какой-то распределённой системмы; пользователь этого компьютера
> и есть злоумышленник — он выкинул рабочий компьютер и заменил его
> (по частям или целиком) своим, и пытается выдать его за оригинальный,
> чтобы украсть или исказить данные этой системы.
Это вообще идиотия какая-то - нормальные распределенные системы делают так, чтобы это просто не было проблемой. Не верите? Окей, попробуйте обмануть биткоин. Потратить одни и те же коины дважды уже может вас озолотить нахрен, одним чихом. Удачи :)
> Intel, разумеется, может провернуть любую из этих атак, и является стороной, которой
> мы вынуждены доверять.
Звучит прикольно для господ оставивших главный ключ себе. Ну, доверяйте. А я пешком постою таким entity "доверять".
> Заметьте, что Intel сделал ME, микрокод и много ещё что обновляемым, чтобы
> сохранить возможность исправлять свои собственные ошибки.
Даже Intel не может обновить boot ROM ME. Даже эпл не может запатчить boot ROM. И кстати поскольку они набили туда довольно много гуано - им за это недавно таки прилетело. И таки они ничерта с этим не сделают до перевыпуска новых ревизий чипов с новым ROM, а старые девайсы будут подлежать takeover'у вечно.
> Путь "сделать с первого раза всё правильно и увести в readonly" слишком сложный.
Но интел именно это и сделал для своего ME boot ROM... как и многие иные процы. Когда вы только включаете питание, проц должен знать что ему делать и откуда-то взять это знание.
Надеюсь это объясняет почему я люблю железки где boot ROM умеренного размера и худо-бедно проанализирован.
> Если не быть активистом фонда СПО, то в ME нет ничего особенно плохого.
Если включить мозг, чужой убер-привилегированный компонент с мутным НЕЗАМЕНЯЕМЫМ мной кодом, всегда работающим side by side и даже на выключеном компе - пожестче иных оруэлловских фантазий.
> vPro по-умолчанию выключен.
Это всего лишь какие-то довески на тот же ME. И что все эти мегазы блобазов с целой операционкой в комплекте реально умеют - можно подумать кто-то блин сильно анализировал.
> На мой взгляд, единственное, что в ME работает лично против меня, это возможность
> по-разному инициализировать одинаковые кристаллы,
А мне вот лично очень не нравится что резидентно висящая на отдельном проце операционка (!!!) может шарахаться допустим в RAM моей системы - да, эта штука умеет в DMA, и поэтому может просто пойти и стырить допустим вон тот пароль из памяти, если вдруг захочет. А захочет ли оно или нет - да кто эти мегазы знает? Можно подумать их кто-то в таком объеме штудировал. А когда таки штудируют - мадам Рутковска нам и показывает "ring -3 rootkit", а интель затыкает CVE в этсамом.
Ну и вообще, когда я плачу как за собственность а в результате главный ключ мне не дают - и это в принципе не оверрайдится - тут по-моему все предельно понятно кто кого за кого держит.
> выше), так как у ME не было бы возможности доказать свою собственную подлинность.
А на мой вкус он должен доказывать подлинность только мне, только моего кода. А если он вместо этого видите ли на wintel работать удумал, за мои же бабки - он тогда в общем то враг. И пучок рентгена ему в табло, по большому то счету.
> Так что можно рассматривать процессор Intel и блоб Intel
> ME, как единый программно-аппаратный комплекс.
Я предпочитаю это рассмтривать как программно-аппаратный бэкдор. Больше всего оно похоже на вот это.
> доверять. Но в большинстве случаев их можно выкинуть, а то и
> вовсе заменить весь биос на открытый coreboot.
Тем не менее, даже coreboot не снимает полностью проблемы с ME. Так что в долговременном плане я для себя хочу отделаться от x86 насовсем. Задолбали.
> Так можно договориться до того, что я не могу изменять топологию интегральных
> (микро)схем, и поэтому у меня недостаточно контроля.
Ну вообще, когда корпорации типа интела начинают феерично борзеть и заниматься именно вот таким - именно это и приходит в бошку толпе народа. Начинают активно развиваться толпы альтернативных SoC, открытые ядра, периферия, народ учится рисовать крутые печатки опенсорсным софтом, клепать открытыми тулсами прошивки FPGA, ...
И я думаю что с железом произойдет примерно то же что и с софтом. По примерно тем же причинам. Проприетарный софт толпа народа решила вынести в основном потому что он стал оборзелым куском головняка, полагающим что с нахрапом навязывать ультра-идиотские правила игры - катит.
> Контроля достаточно для того, чтобы собрать новый образ ОС, подписать его и разлить по всем
> маишнам. А также обновить все обновляемые блобы.
Иллюзия конечно забавная, но всего лишь иллюзия. Это как с кольцами Саурона. Ваши мелкие незначительные ключи - ничто против грандмастерского ключа, который шутя перекрывает все остальное одной левой. Можете махать вашими побрякушками до упада - но вы ничто против Саурона.

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

113. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 30-Июл-20, 12:07

А зачем вообще нужен secure boot, кроме как для vendor lock?

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

116. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kmeaw (?), 30-Июл-20, 12:16

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

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

178. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 30-Июл-20, 20:31

Нет, чтобы ты не дай бог, не поставил себе чего-то несертифицированного.

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

202. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Павел (??), 31-Июл-20, 07:34

Злодей, имеющий физ доступ, может прописать свои ключи в биос. Поэтому secureboot не защитит от такого злодея

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

18. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –3 +/–

Сообщение от Annoynymous (ok), 30-Июл-20, 02:26

Я прямо в предвкушении был этого комментария, открывая текст новости.
Образцовый невежда.

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

37. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (35), 30-Июл-20, 05:59

Он досих пор наверное под MSDOS сидит с дисками 100Мб

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

43. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –3 +/–

Сообщение от Адекват (ok), 30-Июл-20, 06:43

В этом все линуксоиды, взять и извратить до абсурда мысль собеседника!
-Я не хочу обновляться, потому что после обновлений что-то бывает ломается.
-А ну быстро откатился на ядро 2.4 и КДЕ2 !

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

55. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (81), 30-Июл-20, 08:44

У меня MBR работает до сих пор, главное, чтобы размер свободного места в начале диска, был больше размера ядра grub, которое включает публичные ключи, крыптографию для их проверки и крыптографию для расшифровки /boot. Если у вас не влезет, то надо дополнительный мелкий диск для ядра grub.

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

59. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от Аноним (59), 30-Июл-20, 08:52

MBR не умеет в GPT, не умеет больше 4 физических разделов, не умеет разделы > 2Тб
EFI/UEFI это хорошо, а вот SecureBoot плохо

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

63. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (60), 30-Июл-20, 08:59

не MBR не умеет, а отвратительные недостаточно модульные биосы, сделанные с расчётом на запланированное устаревание.

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

83. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (81), 30-Июл-20, 09:45

Ставь GPT и малюсенький раздел для BIOS GRUB, перед разделом /boot и все у тебя будет работать без ограничений.
SecureBoot это необходимая технология в цепочке верификации загрузки компьютера. Она нужна для проверки целостности и аутентичность загрузчика OS.

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

84. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от aa (?), 30-Июл-20, 09:51

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

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

101. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от kkk (??), 30-Июл-20, 11:35

1. GPT - это раздутая и искуственно усложнённая система разделения диска.
2. Больше 4-х основных разделов мало кому нужно. Но даже если нужно, то есть:
  А. Варианты MBR с поддержкой большего числа основных разлелов
  Б. Extended Partition, внутри которого можно насоздовать сколько угодно логических разделов
3. Partition entry в MBR имеет размер в 16 байт, которые просто используются неэффективно. Смотри сам:
1 byte - статус раздела (реально используется лишь один бит - признак того, что раздел загрузочный)
3 bytes - CHR адрес начала раздела
1 byte - тип раздела
3 bytes - CHR адрес конца раздела
4 bytes - LBA адрес начала раздела
4 bytes - LBA размер раздела
CHR давно никто не использует и эти две записи, по три байта каждая, можно использовать для расширения разрядности LBA записей. Там даже место останется, поскольку для современных LBA достаточно 48 бит. Признак расширения можно хранить в первой записе статуса раздела. Этот же признак защитит от неправильного восприятия нового формата partition entry старыми программами. Для них статус раздела, отличный от 0x00 и 0x80 - это невалидный раздел.

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

119. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от kmeaw (?), 30-Июл-20, 12:35

GPT хорош наличием GUID у диска и раздела. Это позволяет однозначно идентифицировать разделы, не залезая в структуры fs, которые могут быть неизвестны системе (например в случае, если раздел неизвестной хосту ОС прокидывается внутрь виртуальной машины), или когда ОС и прошивка видят диски в разном порядке, что неудивительно, учитывая количество интерфейсов, через которые их можно подключить. Ещё разделам можно давать человекочитаемые имена. И partition type в MBR размером в один байт уже как-то мало (Linux Swap vs Solaris).
GPT имеет две копии, в начале и в конце диска, что удобно для восстановления данных после ошибки пользователя.
GPT удобно использовать на EFI-системах — нет больше проблем с многостадийной загрузкой IPL->bootsector->stage1(\.5)?->stage2. Можно просто положить файл (с максимальным размером аж в 2G) на ESP, и прошивка его загрузит. Не надо никуда записывать загрузочные сектора, с файлами работать гораздо проще. И писать код загрузчика стало проще, никакого больше real mode с подготовкой таблиц и переключением в protected mode, а потом проблем с доступом к диску.
Для совсем простых сценариев можно обойтись вообще без разметки диска — создать файловую систему (или даже LVM) прямо на /dev/sda. А весь загрузочный код унести в прошивку.

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

125. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от kkk (??), 30-Июл-20, 13:25

Что ты понимаешь под "однозначно идентифицировать разделы"? В MBR ты знаешь всё, что тебе необходимо знать для разделения диска на разделы и старта системы. Как именно их монтировать или как они называются к MBR не относится, является избыточной и дублируемой информацией, которую придётся постоянно синхронизировать с тем, что знает OS или сами эти разделы.
Проблема многостадийной загрузки - это проблема конкретной файловой системы. Зачем городить огород с EFI программами и специальным разделом, для их хранения, когда можно загрузить код загрузчика из специально указанной области самой файловой системы? Почему код загрузчика привязан к вендору и сидит в прошиве, а не выбирается мной и сидит на диске? Прошивка должна максимум спрашивать какой раздел загружать, если, скажем, несколько разделов помечены загрузочными. Да и кроме как для пользователей нескольких OS на одном компьютере в дуалбуте это никому не нужно.

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

149. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от kmeaw (?), 30-Июл-20, 15:36

> Что ты понимаешь под "однозначно идентифицировать разделы"? В MBR ты знаешь всё, что тебе необходимо знать для разделения диска на разделы и старта системы.
После того, как система запустилась, ей может быть нужно найти раздел на диске. Например в сценарии, когда я выделил раздел для виртуальной машины на своём диске, и хочу запустить qemu, мне надо что-то написать в -drive file=/dev/sda4. Как мне найти этот sda4?
> Проблема многостадийной загрузки - это проблема конкретной файловой системы.
Нет, это проблема маленького размера IPL внутри MBR. Из-за этого разработчики загрузчиков вынуждены делать его многостадийным. Или использовать всякие хаки, типа размещения между концом MBR и началом первого раздела, запоминания конкретных сектроов, где лежит следующая стадия и так далее.
> Прошивка должна максимум спрашивать какой раздел загружать, если, скажем, несколько разделов помечены загрузочными.
В случае с EFI всё равно так и есть. Можно позвать boot menu, и тогда на экране появится список всех разделов, где есть файл EFI/BOOT/bootx64.efi.
> Да и кроме как для пользователей нескольких OS на одном компьютере в дуалбуте это никому не нужно.
При апгрейде компьютера я хочу просто скопировать все файлы с одного диска на другой, а не возиться с переносом структур, нужных для запуска загрузчика. В случае с GPT+UEFI достаточно создать два раздела: ESP и раздел с данными, после чего скопировать пофайлово (rsync -aHAXx) из источника.
Если дуалбут не нужен, и хочется минимализма без EFI, то можно и от MBR-разметки избавится. Но если разделы всё-таки нужны, то ИМХО от GPT больше пользы.

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

159. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от kkk (??), 30-Июл-20, 16:29

> После того, как система запустилась, ей может быть нужно найти раздел на диске. Например в сценарии, когда я выделил раздел для виртуальной машины на своём диске, и хочу запустить qemu, мне надо что-то написать в -drive file=/dev/sda4. Как мне найти этот sda4?
Разве Linux до сих пор не умеет находить /dev/sda4? Как он вообще работал всё это время?
> Нет, это проблема маленького размера IPL внутри MBR. Из-за этого разработчики загрузчиков вынуждены делать его многостадийным. Или использовать всякие хаки, типа размещения между концом MBR и началом первого раздела, запоминания конкретных сектроов, где лежит следующая стадия и так далее.
Boot code внутри MBR вообще не предназначен для загрузки операционной системы. Он необходим лишь для того, чтобы загрузить загрузчик из раздела, помеченного как active. Дальше должен работать другой код, специфичной для файловой и операционной системы, которые там установлены. Прошивка BIOS/UEFI/etc. не должна диктовать как это должно дальше работать, это просто не её дело.
> При апгрейде компьютера я хочу просто скопировать все файлы с одного диска на другой, а не возиться с переносом структур, нужных для запуска загрузчика.
Даже древний DOS так умеет. Почему Linux до сих пор не научился? Почему вместо решения настоящей проблемы нам навязывают UEFI, GPT и Secure Boot?

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

169. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от пох. (?), 30-Июл-20, 17:30

> Даже древний DOS так умеет. Почему Linux до сих пор не научился?
дедушка, вы таблетку от склероза забыли принять. Если сожрали вместо нее эклер - он не помогает.
Древний дос так не умеет, в нем была команда sys и format/s - и не просто так. Вам могло случайно повезти с копированием - надо было чтобы первые файлики поблочно легли в фиксированные секторы диска - этого при незамысловатости той fs и однозадачной системе кое-как можно было добиться без специальных команд, но могло и нет.
> Почему вместо решения настоящей проблемы нам навязывают UEFI, GPT и Secure
потому что uefi таки _решает_ проблему без необходимости фиксировать блжад, _логические_секторы_ ядра системы (и потом еще и читать их через апи 80го года - ломающийся на больших дисках или на недисках вообще, которых в 80м году еще вообразить не могли) - что было приемлемо во времена дос, но нихрена не выглядит разумно в XXI веке. И файлы можно просто класть в efi-раздел в любом порядке и любыми инструментами - они читаются как файлы, а не набор гвоздем прибитых секторов.
GPT - решает проблему что у современного диска нет никаких доступных загрузчику "головок", "дорожек" и так далее, а есть логический номер сектора, изрядно превосходящий возможности 16битных процессоров, для которых писали древнюю досовую partition table (попутно там еще предусмотрена некоторая дополнительная надежность, уменьшающая шанс искать потом по всему диску границы разделов из-за неудачно записавшегося одного сектора - современные диски немного долго это будут делать), да и разделов в нем может быть поболее четырех.
К сожалению, ваше старческое слабоумие мешает вам в этом разобраться, поэтому такие сложные вещи как secureboot вам лучше даже не пытаться понять.

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

179. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 30-Июл-20, 20:43

> дедушка, вы таблетку от склероза забыли принять. Если сожрали вместо нее эклер - он не помогает.
Типичный напыщенный хам. Это ты таблетку забыл принять.
> Древний дос так не умеет, в нем была команда sys и format/s - и не просто так. Вам могло случайно повезти с копированием - надо было чтобы первые файлики поблочно легли в фиксированные секторы диска - этого при незамысловатости той fs и однозадачной системе кое-как можно было добиться без специальных команд, но могло и нет.
Ты глуп и невежественен. В бутсекторе даже DOS дискеты есть код, ищущий конкретные файлы по именам, а не на фиксированных секторах.
> потому что uefi таки _решает_ проблему без необходимости фиксировать блжад, _логические_секторы_ ядра системы (и потом еще и читать их через апи 80го года - ломающийся на больших дисках или на недисках вообще, которых в 80м году еще вообразить не могли) - что было приемлемо во времена дос, но нихрена не выглядит разумно в XXI веке.
Откуда ты такой вылупился? int 13h в BIOS был расширен до 64 бит, что даже больше 48-бит LBA, в далёком 1995 году. Выдыхай, невежда!
> GPT - решает проблему что у современного диска нет никаких доступных загрузчику "головок", "дорожек" и так далее, а есть логический номер сектора, изрядно превосходящий возможности 16битных процессоров, для которых писали древнюю досовую partition table
И снова в лужу, невежда! MBR давно использует LBA, а CHR в нём не используется. Ты даже не потрудился прочесть описание partition record, которое я дал выше.
> К сожалению, ваше старческое слабоумие мешает вам в этом разобраться, поэтому такие сложные вещи как secureboot вам лучше даже не пытаться понять.
К сожалению ты просто дурак.

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

180. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 30-Июл-20, 20:53

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

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

221. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (221), 31-Июл-20, 11:38

Эм, по-моему бутсектор логического диска (не партишна) искал нечто типа IO.SYS или MSDOS.SYS? А оно потом - командкома уже.

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

249. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 31-Июл-20, 19:22

Да, именно так. А никак не на специальные секторах диска. Именно поэтому IO.SYS MSDOS.SYS и COMMAND.COM можно было копировать в корень руками, хоть на пустой диск, хоть на не очень, в любом порядке. Имена этих файлов видны даже без дизассемблирования просто в дампе бутсектора FAT.

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

265. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 01-Авг-20, 10:25

> Эм, по-моему бутсектор логического диска (не партишна) искал нечто типа IO.SYS
да ничего он не "искал", в нем за вычетом bpb места еще меньше чем в mbr, и того половина занята выводом юзерфрендли сообщения "not a dos disk, replace user and press anykey". (заметь, в груб даже такое не поместилось) Тупо сравнивал несколько байтиков по фиксированному адресу, а потом по другому адресу подряд несколько секторов читал. Поэтому байтики и секторы должны были находиться строго там, где он их рассчитывал увидеть.
Это только местный клоун может думать, что туда драйвер файловой системы мог поместиться.
grub и lilo заметь, попродвинутей будут - в них blocklist записан, а не гвоздем прибит. Правда, из-за этого уже даже на такое "юзерфрендли" не осталось места, гадай на первых буковках, почему оно вдруг повисло.
> MSDOS.SYS? А оно потом - командкома уже.
вот командцома оно уже честно читало как файл. Поскольку его уже полностью загрузившийся дос и читал уже штатными апи.

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

273. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 01-Авг-20, 17:54

Дурачок, когда же ты хотя бы просто посмотришь дамп бутсектора FAT? Я уже не говорю о том, чтобы попробовать скопировать три системных файла DOS на дискету, в любом порядке вмести с любыми другими файлами. Зачем ты так упорно несёшь откровенный бред?

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

278. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 02-Авг-20, 16:28

> Дурачок, когда же ты хотя бы просто посмотришь дамп бутсектора FAT?
ты свой ник не в то поле вписал. "дамп бутсектора" лолшта - FAT? Отлично, просто прекрасно.
> Я уже не говорю о том, чтобы попробовать скопировать три системных файла DOS на дискету, в любом
> порядке вмести с любыми другими файлами.
ну так попробуй, и убедись что не работает.
Именно так как ты описал - "в любом порядке и вместе с другими файлами" - нет. Например, сначала command.com, потом msdos.sys, потом удалить смеху ради command.com - и скопировать io.sys а потом заново command.com (кто, в отличие от тебя не "дамп посмотрел", а знает как оно устроено - поймет, в чем фишка)
Это будет нормальный fat, нормальные файлы (их даже можно cнова скопировать уже единственноправильным образом на другой носитель, и он загрузится), только не загрузится. Причем не выдаст ошибку, а повиснет.
А что ты там в ютубе нашел - так это такой же как ты дурачок, не понимающий ни смысла своих действий, ни по какой занятной причине так работает, а так как я написал - гарантированно нет.

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

286. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 03-Авг-20, 09:27

> "дамп бутсектора" лолшта - FAT?
Первый сектор файловой системы. Посмотри что написано в первом секторе, дурачок.
> ну так попробуй, и убедись что не работает.
Пробовал неоднократно, работает.
> Именно так как ты описал - "в любом порядке и вместе с другими файлами" - нет. Например, сначала command.com, потом msdos.sys, потом удалить смеху ради command.com - и скопировать io.sys а потом заново command.com
Снова специально для тебя:
https://www.youtube.com/watch?v=mk5Z2aX9kWE
> кто, в отличие от тебя не "дамп посмотрел", а знает как оно устроено - поймет, в чем фишка
В отличии от меня ты НЕ ЗНАЕШЬ как оно работает.
> Это будет нормальный fat, нормальные файлы (их даже можно cнова скопировать уже единственноправильным образом на другой носитель, и он загрузится), только не загрузится. Причем не выдаст ошибку, а повиснет.
Ты снова сел в лужу, дурачок :-))

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

248. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 31-Июл-20, 19:18

Это ты DOS никогда не видел и даже не потрудился проверить то, что тебе говорят. Типичный напыщенный идиот.

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

274. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 01-Авг-20, 19:44

Специально для тебя:
https://www.youtube.com/watch?v=V5tMCTOcg8k
Будь мужиком, признайся, что был неправ.
Я уберу слово lamer из описания.

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

172. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от Sarcastic scutosaurus (?), 30-Июл-20, 17:32

> Разве Linux до сих пор не умеет находить /dev/sda4?
Замечательно умеет. Только при очередной перезагрузке это может оказаться раздел совсем другого диска.
> Даже древний DOS так умеет. Почему Linux до сих пор не научился?
Все беды оттого, что нет диска C:. Был бы диск C: — жили бы и горя не знали.

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

184. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 20:56

>Замечательно умеет. Только при очередной перезагрузке это может оказаться раздел совсем другого диска.
Ты вменяемый?

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

187. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Sarcastic scutosaurus (?), 30-Июл-20, 21:24

Не знаю, давно не проверялся. А что?
Или ты просто не в курсе, что инициализация контроллеров в ядре происходит параллельно, так что в зависимости от того, какой проинициализируется раньше, диски sda и sdb (условно) могут внезапно поменяться местами?

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

191. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 22:08

> Не знаю, давно не проверялся. А что?
> Или ты просто не в курсе, что инициализация контроллеров в ядре происходит
> параллельно, так что в зависимости от того, какой проинициализируется раньше, диски
> sda и sdb (условно) могут внезапно поменяться местами?
Т. е. про UUID ты не в курсе?

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

242. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +1 +/–

Сообщение от Sarcastic scutosaurus (?), 31-Июл-20, 16:34

UUID чего? У раздела в случае msdos-разметки нет никакого UUID. Они могут быть у чего-то на разделе, типа файловой системы. А теперь поднимись по треду и почитай сообщения, на которые я отвечал.

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

244. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от AlexYeCu_not_logged (?), 31-Июл-20, 18:18

> UUID чего? У раздела в случае msdos-разметки нет никакого UUID. Они могут
> быть у чего-то на разделе, типа файловой системы. А теперь поднимись
> по треду и почитай сообщения, на которые я отвечал.
Ну почитал. у гражданина какие-то невнятные проблемы с поиском раздела sdx: он хочет писать именно sdx и никак иначе, вывода blkid он в жизни не видел. Ты утверждаешь, что sdx при каждой перезагрузке разный. Допустим. Но! Я смотрю в fstab — вижу UUID. Смотрю в grub.cfg — вижу UUID. То, что он «у чего-нибудь типа файловой системы» не особо важно: я в любом случае могу его получить на вменяемой системе (подсказка: на той, что « без диска C»). Так в чём проблема-то? В какой гипотетической ситуации это может сыграть?

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

246. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Sarcastic scutosaurus (?), 31-Июл-20, 18:37

> у гражданина какие-то невнятные проблемы с поиском раздела sdx: он хочет писать именно sdx и никак иначе, вывода blkid он в жизни не видел.
Проблема описана вполне внятно: на разделе может быть нечто, не идентифицируемое ядром и, соответственно, никакого UUID прочитано не будет, даже если он там есть. При использовании GPT раздел имеет UUID (или GUID, как его клятый M$ называет) независимо от содержимого.
> Ты утверждаешь, что sdx при каждой перезагрузке разный.
Ну, положим, не при каждой, а если все диски подключены к одному контроллеру, такого и вовсе не произойдёт, но всё же это случается.

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

266. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от пох. (?), 01-Авг-20, 10:39

>> Ты утверждаешь, что sdx при каждой перезагрузке разный.
> Ну, положим, не при каждой, а если все диски подключены к одному
ну могу тебе показать машину, где именно при каждой, угадай где у нас сегодня диски (затрахало преизрядно, ну ЧТО мешало дятлам научиться читать вместо этого бреда человекочитаемые labels? Они ж блжад - ЕСТЬ!  А, ну да, ну да - "как в венде, только НАХАЛЯВУ и побольше!")
> контроллеру, такого и вовсе не произойдёт, но всё же это случается.
а "контроллер" называется fc switch ;-) От какого из его хвостов миллисекундой раньше прилетит заголовок, тот первым и будет. А поскольку еще и старт асинхронный, то даже если есть еще и локальные диски - никогда не угадаешь, они до fc'шных окажутся или после.

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

269. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 01-Авг-20, 12:12

> ну ЧТО мешало дятлам научиться читать вместо этого бреда человекочитаемые labels? Они ж блжад - ЕСТЬ!
И в чём у тебя проблема с лейблами? Хоть руками mount -L делай, хоть в fstab их прописывай, хоть в командную строку ядра — отовсюду подхватятся. Только полагаться на них лично я бы не стал: воткнёт тебе кто-то незаметно флешку с лейблом TMP, потом выдернет и будет изучать, что на ней интересного осело. Или интереснее — с лейблом BOOT…

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

277. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 02-Авг-20, 16:19

> И в чём у тебя проблема с лейблами? Хоть руками mount -L делай
то что ты даже не понял, о каких лейблах речь.

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

279. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 02-Авг-20, 20:21

Заинтриговал.

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

292. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 04-Авг-20, 03:11

> Заинтриговал.
не, сам запутался - -L это именно оно, partition label (в отличие от LABEL=, который доступен только если fs вообще уже удалось как-то угадать и распарсить, поскольку он лежит внутри нее и в ей одной ведомом месте - как и почему-то горячо любимый всеми UUID= )
Жаль что в fstab их пихать некуда (в линуксный, у других есть варианты). Впрочем, все равно он немодный.

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

295. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 04-Авг-20, 22:45

> не, сам запутался - -L это именно оно, partition label (в отличие от LABEL=, который доступен только если fs вообще уже удалось как-то угадать и распарсить
Эээ… А где этот partition label лежать-то должен? В DOS disk label на каждый раздел всего 16 байт отведено, и все под другое заняты.

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

297. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 05-Авг-20, 00:17

> Эээ… А где этот partition label лежать-то должен?
в partition table, вестимо. Если она, конечно, GPT. Собственно, это одна из причин, почему хватит уже трахать мертвую бабушку доса, пора бы торжественно предать земле.
Правда, нормально пользоваться можно только во фре (бессмысленных и ненужных guid'ов там при этом даже не видно. Логично - чего на них смотреть, если ни запомнить, ни сравнить?)

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

301. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 05-Авг-20, 23:01

А, ты про GPT… Просто выше-то MBR обсуждали. Но и что в GPT можно имена разделам задавать — не знал. А для монтирования они, видимо, не используются, потому что не обязаны быть уникальными, в отличие от GUID/UUID. Если gdisk'ом делать, он по умолчанию обзовёт всё "Linux filesystem". Так себе идентификатор.

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

305. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 06-Авг-20, 18:49

> Но и что в GPT можно имена разделам задавать — не знал. А для монтирования они, видимо, не
> используются, потому что не обязаны быть уникальными, в отличие от GUID/UUID.
повторяю: в той _единственной_ реальной ситуации, когда на самом деле могут возникнуть эти проблемы - в систему воткнут диск от чужой системы - guid запросто оказывается тоже неуникальным, потому что это клон.
> Если gdisk'ом делать
отсутствие в линухе вменяемой замены для gpart - мы тут уже обсуждали, ну что ты хочешь от системы любителей синих окошечек и косплея винды? Они скосплеили древнюю досовскую утиль, которую когда-то только и застали, а на большее их фантазии не хватило. Да и ту не затянули в автоматику установки как следует, чтобы ей можно было сделать что-то разумное.
P.S. ты, кстати, тип раздела с меткой не путаешь? А то "Linux filesystem" очень похожа на тип, а не метку. Есть у microsoft такой ;-) Причем еще есть отдельный от него linux-lvm - старались.

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

302. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 05-Авг-20, 23:04

Впрочем, можно их при желании в fstab зафигачить. /dev/disk/by-partlabel/...

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

303. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 06-Авг-20, 13:38

> Впрочем, можно их при желании в fstab зафигачить. /dev/disk/by-partlabel/...
о, научились.
Но, похоже, это фича ядер после 4.какой-то, мое так не умеет и такого каталога нет вообще.

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

304. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 06-Авг-20, 16:05

На, дарю:
ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_NAME}=="?*", SYMLINK+="disk/by-partlabel/$env{ID_PART_ENTRY_NAME}"
Куда вставить, надеюсь, найдёшь.

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

306. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от пох. (?), 06-Авг-20, 18:55

> Куда вставить, надеюсь, найдёшь.
ты мне лучше найди куда вставить создание этих меток. Причем - динамическое. Причем где-то в районе firstboot или аналогов - поскольку система создается клонированием.
Собственно, я и на fs-labels согласен, только их нельзя поменять на примонтированной fs.
(для замены uuid есть специальный черезанусный апи, требующий, не много ни мало - специфических метаданных в fs)

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

307. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 07-Авг-20, 11:41

Э не, вот это уже только за деньги.

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

293. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от пох. (?), 04-Авг-20, 03:18

> И в чём у тебя проблема с лейблами? Хоть руками mount -L
то что в fstab вместо них автоматически записывается неведомая вредная херня?
> — отовсюду подхватятся. Только полагаться на них лично я бы не
> стал: воткнёт тебе кто-то незаметно флешку с лейблом TMP, потом выдернет
меня пока больше интересует что делать, если сделал dd if=/dev/sda of=/dev/sdb - и как теперь  распутать эту вермишель. Лично для меня это гораздо более реальный сценарий.
Учитывая что изменение uuid на подмонтированной fs - внезапно, нетривиальная задача, потребовавшая специфических патчей в ведре (кажется, в 3.x их еще нет ни в каких).
> и будет изучать, что на ней интересного осело. Или интереснее —
> с лейблом BOOT…
а он `hostname`.boot - и нихрена ты не угадал. А вот клонирование флэшки - куда более вероятная ситуация, и никакие бесполезно-uuid тут не помогают, только усложняют жизнь.

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

296. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (102), 04-Авг-20, 22:50

В случае с dd лейблы никак не помогут, с ними ровно такая же путаница будет.

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

298. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

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

> В случае с dd лейблы никак не помогут, с ними ровно такая
лэйблы помогут - тем что ты это увидишь и сможешь понять, где какой - если я сейчас поменял clone1 на clone2 - я не забуду это в момент редактирования fstab завтра.
А с guid через секунду будешь пялиться на бессмысленный набор знаков - "это тот который был, или который новый?" "вроде тот на 3afa начинался? Или нет?"
Поэтому и не нужны они ни для чего - ни уникальность не гарантируют, ни удобства не дают.
hostname.part в пределах локальной сети, кстати, дают и то и другое. Но дистрибутивоклепателей уже не остановить.

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

251. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от kkk (??), 31-Июл-20, 19:50

> Замечательно умеет. Только при очередной перезагрузке это может оказаться раздел совсем другого диска.
При наличии одного SATA контроллера с несколькими портами? Ты уверен?
Кроме того у тебя есть /dev/disk/by-path/ и /dev/disk/by-id/
То есть UUID снова не нужен.
И как ты запишешь UUID если не можешь идентифицировать чистый диск без него? Представь себе, что это новый или свежезабитый нулями диск. Никакого GPT на нём ещё нет.

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

182. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 20:55

>Как мне найти этот sda4?
0_0. Эм, а вы вообще /etc/fstab видели когда-нибудь?

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

133. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –3 +/–

Сообщение от Аноним (-), 30-Июл-20, 14:51

> GPT хорош наличием GUID у диска и раздела. Это позволяет однозначно идентифицировать
...всяких бакланов, подпихивая им небольшое персональное клеймо? :)

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

183. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 30-Июл-20, 20:55

>> GPT хорош наличием GUID у диска и раздела. Это позволяет однозначно идентифицировать
> ...всяких бакланов, подпихивая им небольшое персональное клеймо? :)
не будь лохом, скопируй uuid у другого баклана!
(правда, потом будет немного обидно присесть за его cp)

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

222. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от Аноним (221), 31-Июл-20, 11:39

> не будь лохом, скопируй uuid у другого баклана!
Ну, давай сюды свой :)
> (правда, потом будет немного обидно присесть за его cp)
Так зачем же CP копировать, толко гуид :)

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

299. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +/–

Сообщение от пох. (?), 05-Авг-20, 00:30

>> не будь лохом, скопируй uuid у другого баклана!
> Ну, давай сюды свой :)
держи: e139ce78-9841-40fe-8823-96a304a09859
>> (правда, потом будет немного обидно присесть за его cp)
> Так зачем же CP копировать, толко гуид :)
дык cp найдет товарищмайор, и решит что ты и есть тот баклан. Вот же, uuid тот!
P.S. не ссы, их несколько десятков тысяч. Половина хранит котиков и хомпорно.

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

181. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." –1 +/–

Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 20:53

>GPT хорош наличием GUID у диска и раздела.
Решается на уровне ОС, а за её пределами — зачем?

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

105. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..." +3 +/–

Сообщение от Аноним (102), 30-Июл-20, 11:50

> MBR не умеет в GPT
Да блин, что за каша в головах у людей? Если имеете в виду grub-pc, то так и пишите. MBR — это просто область на диске, она не может "работать" или "во что-то уметь".
P. S. Да, к сведению: на машине, с которой я пишу, grub-pc и GPT. Всё работает.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

13. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+8 +/–
Сообщение от qbr (?), 30-Июл-20, 01:42
Был же старый добрый MBR, работал и есть не просил. Нет, обязательно надо выпендриться и придумать какую-то неведомую хрень, вместо развития уже работающей технологии. В большенстве случаев MBR продолжает работать и сейчас, но в некоторых недо-дистрибах его уже не поддерживают. Уроды!
Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–2 +/–
	Сообщение от kmeaw (?), 30-Июл-20, 02:05
	Как реализовать сценарий secure boot с MBR? Где будет лежать подпись? Напомню, что размер IPL — всего 440 байт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+16 +/–
	Сообщение от Аноним 80_уровня (ok), 30-Июл-20, 02:33
	Ваш комментарий подразумевает, что реализация сценария secure boot - это что-то нужное, если не необходимое.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
	Сообщение от DerRoteBaron (ok), 30-Июл-20, 02:43
	Это что-то в некоторых случаях небесполезное, т.к. усложняет эксплуатацию физического доступа к оборудованию
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
	Сообщение от Аноним (21), 30-Июл-20, 03:12
	> эксплуатацию физического доступа закрой свой комп в тумбочку, ключ раствори в кислоте... профит! Некоторые нерадивые рабовладельцы так и делают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от RADV (?), 30-Июл-20, 11:53
	Это защита от руткитов, которые подменяют ядро на свое собственное. Это не защита от физического доступа.
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	114. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (114), 30-Июл-20, 12:08
	А нельзя было просто в биосе прописать, что без ввода пароля от биоса запретить загружаться со всяких флешек и СД ?
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	117. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 12:21
	Можно снять крышку, вытащить диск, переписать на нём загрузчик и поставить обратно. Можно найти баг в загрузчике или ОС, получить рута и переписать загрузчик. Secure Boot в таких случаях защитит пользователя, так как откажется грузиться в скомпрометированную систему. Тут конечно остаётся вопрос, раз злоумышленник смог проникнуть в систему, то он и повторить это сможет. Но это должно решаться обновлениями безопасности. Vendor-lock это хорошо, если каждый без особых усилий может стать vendor'ом — выпускать свои подписанные загрузчики и ядра. А спецификация Secure Boot требует наличия возможности загрузить пользовательские ключи, против которых проверяется загрузчик ОС.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	120. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от kkk (??), 30-Июл-20, 12:37
	Если каждый легко может стать vendor-ом, то смысл в vendor lock пропадает и этой защиты неизвестно от кого тоже нет. Если у меня есть физический доступ к компьютеру и возможность снять крышку, вытащить диск и что-то на нём переписать, почему у меня не будет возможности ещё и заменить ключи на свои и подписать ими то, что я переписал? Кому вообще нужна эта защита на десктопах и рабочих станциях?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (129), 30-Июл-20, 14:27
	> Можно снять крышку, вытащить диск, переписать на нём загрузчик и поставить обратно. Можно получить рута на компе, прописать хлам в загрузочный раздел/сектор и ... даже диск вынимать не надо. > Secure Boot в таких случаях защитит пользователя, так как откажется грузиться в > скомпрометированную систему. Но это в основном теоретически, практически мс зассал кашпировский буткит используемый хакерами зарубать потому что это и легитимным юзерам системы кирпичило заодно. > Vendor-lock это хорошо, если каждый без особых усилий может стать vendor'ом — выпускать свои > подписанные загрузчики и ядра. А спецификация Secure Boot требует наличия возможности > загрузить пользовательские ключи, против которых проверяется загрузчик ОС. А теперь коронный номер - попробуйте сменить гранд-мастер-ключ, которым блобы ME подписаны. А, не получается? Ну вот то-то - сразу и видно, кто настоящий вендор, а кто так, покурить вышел. И в этой схеме настоящий вендор вас конечно же этсамое, по иерархии.
	Ответить \| Правка \| К родителю #117 \| Наверх \| Cообщить модератору


	148. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от kmeaw (?), 30-Июл-20, 15:24
	> Можно получить рута на компе, прописать хлам в загрузочный раздел/сектор и ... даже диск вынимать не надо. А если диск зашифрован? Злоумышленнику очень бы хотелось заменить загрузчик на тот, который запомнит ключи или попатчит ещё что-нибудь, когда легитимный пользователь загрузит свой компьютер. Secure Boot не даст ему загрузиться после такого вмешательства. > А теперь коронный номер - попробуйте сменить гранд-мастер-ключ, которым блобы ME подписаны. А что вы хотите поменять в ME? Вы же не требуете от процессора быть реализованным на FPGA. И Secure Boot никак не защищает ME. Единственное отличие "настоящего вендора" от меня в том, что если я решу разработать свой болдженос, то он не загрузится на машине со включенным Secure Boot и настройками по-умолчанию — придётся либо выключить Secure Boot, либо сделать provisioning.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	198. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 31-Июл-20, 06:25
	А что помешает злоумышленнику добавить свой ключ в список доверенных SB? Если же возможности добавить свои ключи нет, то это уже совсем плохо, это получается ты не можешь на своем железе запустить свое ядро.
	Ответить \| Правка \| К родителю #117 \| Наверх \| Cообщить модератору


	34. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (31), 30-Июл-20, 05:50
	> Как реализовать сценарий secure boot с MBR? Сделать IPL и первую статию загрузчика наглухо readonly. А вот дальше в них чекать подписи уже. Злоумышленник не сможет их перезаписать - и, соответственно, перехватить управление. Ну и коли это честно проверит подписи - то собственно дело в шляпе. И таки я примерно так и делаю на некоторых одноплатниках, где в качестве boot media - sd card или spi nor, там либо аппаратный WP# есть, либо однократно выставляемый навечно флаг "readonly media" (в управляющих структурах SD card). При этом от чипа вообще не требуется уметь в secure boot - некий аналог "донавешен позднее", что впрочем совершенно не мешает. Эту идею озвучивал еще гугл с своими хромобуками лет наверное 10 назад. Нормальная идея, достигает то же самое без дикой оверинженерии как в уефанстве.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	115. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 12:15
	А как обновлять этот IPL тогда? И в 440 байт сложно уместить алгоритм проверки подписи. Смысл всех этих BIOS Guard, Secure Boot, Trusted Boot, TPM, Measured Boot в том, что система не жёстко фиксируется на readonly-носителе, а может обновляться, но не злоумышленником.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	132. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (132), 30-Июл-20, 14:40
	> А как обновлять этот IPL тогда? 1) А что если никак?! Зачем вам обновлять мелкий прелоадер? Вы же не обновляете бутром на кристалле... ну а это вот будет вашим аналогом того рома. С ровно той же фичой - атакующий не может это перефигачить под себя. 2) Если очень надо - в случае SPI NOR можно хардварный сигнал WP# юзать. Что с ним сделать?! Ну, самое очевидное - на железный джампер или кнопку загнать. Вот это как минимум ремотный атакующий совершенно точно оспорить не сможет. А локальный с физическим доступом один черт может очень много всего интересного. Вплоть до осмысленного пуляния сфокусированным рентгеном в нужную область проца в правильное время, если вопрос будет на миллион. Более продвинутый вариант - микроконтроллеру этот пин отдать. С защищенной от чтения извне прошивкой, конечно, дабы пароль не стыбзили из МК. Ну и дальше - фирмвара мк может спросить "boot update password" например. Скажете правильно - фирмвара дернет лапку МК, снимет сигнал WP# с чипа, и пишите себе свою флеху апдейтом - доказав что вы owner. Не угадали? Ну вот вам отключение ввода пароля до следующего полного poweroff, WP# остается в залоченом состоянии, основной проц это никак оспорить не сможет - он не контролит WP# напрямую. С SD так не прокатит, там хардварного пина блокировки записи нет в отличие от spi nor чипов. > И в 440 байт сложно уместить алгоритм проверки подписи. Не обязательно. Рассматривайте его + более крупную стадию как одно целое и отправьте оба в ридонли область. Все что 440 байтов будут должны - подчитать более жирный бут из ридонли и запустить его. Поскольку атакующий не может его заменить - оно ж ридонли - то и проблемы в этом нет. > Смысл всех этих BIOS Guard, Secure Boot, Trusted Boot, TPM, Measured Boot > в том, что система не жёстко фиксируется на readonly-носителе, а может > обновляться, но не злоумышленником. Смысл всей этой гадости - убедить лоха в том что у него типа-есть-контроль. А реально - фирма интел всегда может подписать своим ключом early boot своего ME. ME всегда возьмет под козырек и выполнит то что интел попросил. И вы не можете отнять у фирмы Интел эту возможность полностью и окончательно. Более подробный анализ этих подарочков есть у positive techs например. Как и некие способы перехвата. Однако это все же не отменяет того факта что бутром ME всегда охотно выполнит код подписаный интелем - и только им, это будет иметь доступ в все закоулки - и нет никакого способа радикально и совсем вырубить фирме Интел такую возможность.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	147. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 15:20
	> 1) А что если никак?! Зачем вам обновлять мелкий прелоадер? Вы уверены, что сможете с первого раза написать идеальный прелоадер без ошибок? Я скорее всего не смогу, и хотелось бы расчитывать на какую-то внешнюю систему для проверки подписи, дающей возможность выпустить новую версию (и заодно отозвать старую). > Вы же не обновляете бутром на кристалле... ну а это вот будет вашим аналогом того рома. С ровно той же фичой - атакующий не может это перефигачить под себя. Когда в ROM обнаруживается ошибка, всё становится очень плохо. Но у производителя чипов больше ресурсов, чем у меня (и у большинства разработчиков ОС), поэтому это должно происходить не слишком часто. > Ну, самое очевидное - на железный джампер или кнопку загнать. Представьте, что вы работаете в компании, и в ваши обязанности входит обслуживание рабочих мест сотрудников, которых сотни. Вот вышла новая версия ОС, в которой обновились критические компоненты (в частности ядро). Как массово накатить обновление? С boot update password конечно всё здорово придумано, но в PC такого пока что нет (что-то похожее есть на новых маках). Зато есть Secure Boot, который эту проблему решает. Вместо password используется подпись. > Не обязательно. Рассматривайте его + более крупную стадию как одно целое и отправьте оба в ридонли область. Все что 440 байтов будут должны - подчитать более жирный бут из ридонли и запустить его. Поскольку атакующий не может его заменить - оно ж ридонли - то и проблемы в этом нет. Не получится. Всё, что знает BIOS - это то, что с диска надо загрузить первый сектор и передать туда управление. Что будет грузиться дальше, какой layout у выдуманных мной структур, ему уже неизвестно. Значит единственное место, у которого он сможет проверить подпись (если бы такая функция была бы реализована) — это IPL. Чтобы построить цепочку доверия, внутри этого IPL должен располагаться код, который загрузит всё остальное, проверит подпись и передаст управление в случае успеха. А места для этого маловато. Так что остаётся только вариант с уводом в read-only, а обычный PC с обычными жёсткими дисками так (увести в r/o первые N килобайт) не умеет. > Смысл всей этой гадости - убедить лоха в том что у него типа-есть-контроль. Смысл всех этих мер не в абсолютной защите от всех-всех подряд. От производителя процессора вы всё равно защититься не сможете. Все эти меры, правильным образом задеплоенные, позволяют защититься всего от двух атак: 1) злоумышленник смог кратковременно получить контроль, и, переписывая критические компоненты системы, хочет закрепиться надолго; 2) компьютер является частью какой-то распределённой системмы; пользователь этого компьютера и есть злоумышленник — он выкинул рабочий компьютер и заменил его (по частям или целиком) своим, и пытается выдать его за оригинальный, чтобы украсть или исказить данные этой системы. Intel, разумеется, может провернуть любую из этих атак, и является стороной, которой мы вынуждены доверять. Заметьте, что Intel сделал ME, микрокод и много ещё что обновляемым, чтобы сохранить возможность исправлять свои собственные ошибки. Путь "сделать с первого раза всё правильно и увести в readonly" слишком сложный. Если не быть активистом фонда СПО, то в ME нет ничего особенно плохого. vPro по-умолчанию выключен. На мой взгляд, единственное, что в ME работает лично против меня, это возможность по-разному инициализировать одинаковые кристаллы, создавая ценовую диверсификацию — блокировка множителя, ограничение частоты памяти. Если бы ME был СПО, то я бы мог всё это выключить. Но тогда бы было невозможно защититься от атаки #2 (см. выше), так как у ME не было бы возможности доказать свою собственную подлинность. Так что можно рассматривать процессор Intel и блоб Intel ME, как единый программно-аппаратный комплекс. Некоторый вред есть от сторонних компонентов (option ROMs, модули UEFI, код SMM), которые написаны непонятно кем, часто сомнительного качества, и которым пользователь вынужден доверять. Но в большинстве случаев их можно выкинуть, а то и вовсе заменить весь биос на открытый coreboot. Так можно договориться до того, что я не могу изменять топологию интегральных (микро)схем, и поэтому у меня недостаточно контроля. Контроля достаточно для того, чтобы собрать новый образ ОС, подписать его и разлить по всем маишнам. А также обновить все обновляемые блобы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	113. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kkk (??), 30-Июл-20, 12:07
	А зачем вообще нужен secure boot, кроме как для vendor lock?
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	116. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 12:16
	Чтобы злодей, кратковременно получивший физический доступ к оборудованию или через ошибку в ОС получивший возможность писать на диск не смог закрепиться в системе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	178. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kkk (??), 30-Июл-20, 20:31
	Нет, чтобы ты не дай бог, не поставил себе чего-то несертифицированного.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	202. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Павел (??), 31-Июл-20, 07:34
	Злодей, имеющий физ доступ, может прописать свои ключи в биос. Поэтому secureboot не защитит от такого злодея
	Ответить \| Правка \| К родителю #113 \| Наверх \| Cообщить модератору


	18. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–3 +/–
	Сообщение от Annoynymous (ok), 30-Июл-20, 02:26
	Я прямо в предвкушении был этого комментария, открывая текст новости. Образцовый невежда.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	37. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (35), 30-Июл-20, 05:59
	Он досих пор наверное под MSDOS сидит с дисками 100Мб
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–3 +/–
	Сообщение от Адекват (ok), 30-Июл-20, 06:43
	В этом все линуксоиды, взять и извратить до абсурда мысль собеседника! -Я не хочу обновляться, потому что после обновлений что-то бывает ломается. -А ну быстро откатился на ядро 2.4 и КДЕ2 !
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (81), 30-Июл-20, 08:44
	У меня MBR работает до сих пор, главное, чтобы размер свободного места в начале диска, был больше размера ядра grub, которое включает публичные ключи, крыптографию для их проверки и крыптографию для расшифровки /boot. Если у вас не влезет, то надо дополнительный мелкий диск для ядра grub.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	59. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (59), 30-Июл-20, 08:52
	MBR не умеет в GPT, не умеет больше 4 физических разделов, не умеет разделы > 2Тб EFI/UEFI это хорошо, а вот SecureBoot плохо
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	63. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (60), 30-Июл-20, 08:59
	не MBR не умеет, а отвратительные недостаточно модульные биосы, сделанные с расчётом на запланированное устаревание.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (81), 30-Июл-20, 09:45
	Ставь GPT и малюсенький раздел для BIOS GRUB, перед разделом /boot и все у тебя будет работать без ограничений. SecureBoot это необходимая технология в цепочке верификации загрузки компьютера. Она нужна для проверки целостности и аутентичность загрузчика OS.
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору


	84. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от aa (?), 30-Июл-20, 09:51
	>MBR не умеет в GPT добавить поддержку никто не мешает - это всего лишь прочитать пару секторов >, не умеет больше 4 физических разделов во-первых что такое "физический раздел"? физически на диске разделы не создаются, бывают только логические во-вторых не умеет как раз таки досовская таблица разделов, а в первом пункте мы уже добавили поддержку гпт >, не умеет разделы > 2Тб см п.2
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору


	101. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от kkk (??), 30-Июл-20, 11:35
	1. GPT - это раздутая и искуственно усложнённая система разделения диска. 2. Больше 4-х основных разделов мало кому нужно. Но даже если нужно, то есть: А. Варианты MBR с поддержкой большего числа основных разлелов Б. Extended Partition, внутри которого можно насоздовать сколько угодно логических разделов 3. Partition entry в MBR имеет размер в 16 байт, которые просто используются неэффективно. Смотри сам: 1 byte - статус раздела (реально используется лишь один бит - признак того, что раздел загрузочный) 3 bytes - CHR адрес начала раздела 1 byte - тип раздела 3 bytes - CHR адрес конца раздела 4 bytes - LBA адрес начала раздела 4 bytes - LBA размер раздела CHR давно никто не использует и эти две записи, по три байта каждая, можно использовать для расширения разрядности LBA записей. Там даже место останется, поскольку для современных LBA достаточно 48 бит. Признак расширения можно хранить в первой записе статуса раздела. Этот же признак защитит от неправильного восприятия нового формата partition entry старыми программами. Для них статус раздела, отличный от 0x00 и 0x80 - это невалидный раздел.
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору


	119. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от kmeaw (?), 30-Июл-20, 12:35
	GPT хорош наличием GUID у диска и раздела. Это позволяет однозначно идентифицировать разделы, не залезая в структуры fs, которые могут быть неизвестны системе (например в случае, если раздел неизвестной хосту ОС прокидывается внутрь виртуальной машины), или когда ОС и прошивка видят диски в разном порядке, что неудивительно, учитывая количество интерфейсов, через которые их можно подключить. Ещё разделам можно давать человекочитаемые имена. И partition type в MBR размером в один байт уже как-то мало (Linux Swap vs Solaris). GPT имеет две копии, в начале и в конце диска, что удобно для восстановления данных после ошибки пользователя. GPT удобно использовать на EFI-системах — нет больше проблем с многостадийной загрузкой IPL->bootsector->stage1(\.5)?->stage2. Можно просто положить файл (с максимальным размером аж в 2G) на ESP, и прошивка его загрузит. Не надо никуда записывать загрузочные сектора, с файлами работать гораздо проще. И писать код загрузчика стало проще, никакого больше real mode с подготовкой таблиц и переключением в protected mode, а потом проблем с доступом к диску. Для совсем простых сценариев можно обойтись вообще без разметки диска — создать файловую систему (или даже LVM) прямо на /dev/sda. А весь загрузочный код унести в прошивку.
	Ответить \| Правка \| Наверх \| Cообщить модератору