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

"Критическая уязвимость в загрузчике GRUB2, позволяющая обойти UEFI Secure Boot"	+/–
Сообщение от opennews (?), 30-Июл-20, 00:22
В загрузчике GRUB2 выявлено 8 уязвимостей. Наиболее опасная проблема (CVE-2020-10713), которой присвоено кодовое имя  BootHole, даёт возможность обойти механизм UEFI Secure Boot и добиться установки неверифицированного вредоносного ПО. Особенностью данной уязвимости является то, что для её устранения не достаточно обновить GRUB2, так как атакующий может использовать загрузочный носитель со старой уязвимой версией, заверенной цифровой подписью, и скомпрометировать процесс верификации не только при загрузке Linux, но и Windows... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53454
Ответить | Правка | Cообщить модератору

Сообщения

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

47. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+18 +/–
Сообщение от Аноним (47), 30-Июл-20, 07:44
1. > Уязвимость проявляется при разборе содержимого файла конфигурации grub.cfg, который обычно размещается в разделе ESP (EFI System Partition) и может быть отредактирован атакующим, имеющим права администратора, без нарушения целостности подписанных исполняемых файлов shim и GRUB2. https://www.gnu.org/software/grub/manual/grub/grub.html#Usin... У меня ВСЕ модули и ВСЕ настройки grub, включая grub.cfg и прочие которые он подгружает подписаны, так же как и ВСЕ ядра и инитрд. Не подписанный файл или с плохой цифровой подписью grub незагрузит и может прервать загрузку системы: set check_signatures=enforce . Если grub.cfg изменить, то уязвимость не проявится, grub проверит цифровую подпись, увидеть что файл плохой и не будет его подгружать. Цепочку доверия и верификации между secure boot и IMA/EVM GRUB не нарушит. Значит "уважаемая" RedHat опять что-то мутит... PS: У grub2 всеже есть баг или фичя: 1. Обнаружив плохую подпись или ее отсутствие grub не остановит загрузку, просто не будет загружать данный файл, и если возможно продолжит загрузку. Например в grub.cfg можно с помощью configfile включать другие конфигурационные файлы (https://www.gnu.org/software/grub/manual/grub/grub.html#Embe... и если изменить их то grub.cfg отработает нормально но без загрузки измененного файла. 2. Если загрузка таки невозможна grub2 вываливается в рутовую "рескуэ" консоль где можно вводить ЛЮБЫЕ команды, включая: set check_signatures=no и дальше грузить все что захочешь!!! Я лично не раз этим пользовался чтобы прервать доверительную сертифицированный цепочку между secure boot и IMA/EVM. Баг это или фичя такая? В любом случае надо или отдельно от стандартного пароля grub (в core.img) защищать вываливание в консоль граба паролем или иметь опцию на подобие set rescue_console=off и устанавливать ее в переменные окружения как и check_signatures в grub core.img который верифицируется secure boot. 2. > В большинстве Linux-дистрибутивов для верифицированной загрузки используется небольшая прослойка shim, заверенная цифровой подписью Microsoft. С secure boot ВСЕ чужие публичные ключи должны удалятся. Это незыблемое требование Integrity. Вы сами, лично, должны создать свой ключ для secure boot и подписывать им grub core.img в котором находятся установленные переменные и публичный ключ для проверки подписей модулей grub, его настроек, а также ядер и инитрд. Наличие любого чужого публичного ключа, даже, такой уважаемой фирмы как M$, в secure boot неприемлимо!
Ответить | Правка | Наверх | Cообщить модератору

	49. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+3 +/–
	Сообщение от Аноним (49), 30-Июл-20, 08:09
	> Значит "уважаемая" RedHat опять что-то мутит... 100% хотят дрянь типа systemd в grub засунуть под предлогом исправления из пальца высосанной, практично не реализуемой проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+4 +/–
	Сообщение от Аноним (81), 30-Июл-20, 09:36
	> Проблема решается только обновлением в системе списка отозванных сертификатов (dbx, UEFI Revocation List), но в этом случае будет потеряна возможность использования старых установочных носителей c Linux. Некоторые производители оборудования уже включили в свои прошивки обновлённый список отозванных сертификатов, на таких системах в режиме UEFI Secure Boot можно будет загрузить только обновлённые сборки дистрибутивов Linux. А может дрянь не в сам grub совать будут, а в "обновлённые сборки дистрибутивов Linux" уже засунули... А чтобы со старых, чистых образов не грузились и не ставили чистую систему отозвали в UEFI старые ключи! RedHat с systemd любимого Потеринга начало жесткое наступление.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+2 +/–
	Сообщение от Аноним (91), 30-Июл-20, 10:22
	Уже есть systemd boot.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	96. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	–1 +/–
	Сообщение от Анноним (?), 30-Июл-20, 10:34
	До GNU/Systemd осталось немного )
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	–2 +/–
	Сообщение от anonymous (??), 30-Июл-20, 10:39
	Обсуждаю с коллегами варианты защиты, и ребята говорят, что надо внедрять systemd bootloader :)
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	136. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+2 +/–
	Сообщение от anonom (?), 30-Июл-20, 14:56
	лавров.jpg
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от anonymous (??), 30-Июл-20, 19:02
	А если откинуть эмоции, то технические аргументы какие forward-нуть?
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (219), 31-Июл-20, 11:17
	Форкнуть хотели сказать? Описанная уязвимость boothole практично нереализуема! У меня ее нет! Рассмотривалм варианты: 1. с шифрованым /boot 2. с шифрованым /boot на загрузочной флешке 3. с шифрованым заглавием LUCS на загрузочной флешке. Заметь, мало того, что grub проверит все подписи, так еще шифрование /boot не даст ничего в нем поменять.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от anonymous (??), 31-Июл-20, 14:39
	> шифрование /boot А ключ для шифрования откуда берётся? Вручную вводится? Или из TPM? А проблема реализуется очень просто на машинах, где запрещено шифрование данных из-за проблем с performance: просто грузишься по сети с побитым grub.cfg (который обычно не измеряется, ибо слишком динамичный) и получаешь полный контроль над системой с правильными значениями в TPM :)
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от anonymous (??), 31-Июл-20, 14:39
	Да даже если разрешено шифрование с ключом в TPM -- та же проблема.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (241), 31-Июл-20, 14:56
	Значит так ребята. Давайте версии используемого вами grub пишите и дистрибутива!
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (241), 31-Июл-20, 14:53
	Не должно быть проблем ни с ручным вводом пароля ни с ключом. Измененный grub.cfg не загрузится, подпись не прокатит!!! Можно и Libre BOOT шифровать диск, он тоже умеет.
	Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

	253. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от anonymous (??), 31-Июл-20, 19:59
	> ни с ручным вводом пароля Когда у тебя миллион серверов, это уже становится проблемным. А про ключик из TPM я сказал чуть выше. > Libre BOOT Не работает на современных серверных платформах.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (255), 01-Авг-20, 07:16
	> А про ключик из TPM я сказал чуть выше. С каким конкретно TPM и какая конкретно версия GRYB не работает? > Когда у тебя миллион серверов, это уже становится проблемным. >> Libre BOOT > Не работает на современных серверных платформах. Если лям серваков то можно и Libreboot на них портировать.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (258), 01-Авг-20, 08:09
	> Если лям серваков то можно и Libreboot на них портировать. Или coreboot затрояненый проприетарные блобами обучить шифровать /boot. Портировать поддержку LUKS с GRUB2 или LibreBOOT не сложная задача.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от anonymous (??), 01-Авг-20, 10:12
	> Или coreboot затрояненый проприетарные блобами обучить шифровать /boot. Портировать поддержку LUKS с GRUB2 или LibreBOOT не сложная задача. Не могу распарсить написанное ^ :(
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (288), 03-Авг-20, 14:16
	Coreboot обучить шифровать /boot портировав в него поддержку LUKS с GRUB2 или LibreBOOT.
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от anonymous (??), 01-Авг-20, 10:09
	> С каким конкретно TPM и какая конкретно версия GRYB не работает? Почему не работает? Работает. Просто тут выбор: 1. Либо запретить менять конфиг grub, иначе потеряешь доступ к диску. А это трудновыполнимое требование (всё же постоянно надо что-то менять и улучшать). 2. Либо не измерять конфиг grub. Тогда обсуждаемая уязвимость позволяет получить ключик для шифрования диска какой-нибудь malware. Что конкретно предлагаете выбрать? :) > Если лям серваков то можно и Libreboot на них портировать. Очень похожий проект у нас тоже есть, но до полномасштабного запуска ещё несколько лет. Там есть множество сложностей, которые, к сожалению, попадают под NDA от Intel :(
	Ответить | Правка | К родителю #255 | Наверх | Cообщить модератору

	289. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (288), 03-Авг-20, 14:29
	> Что конкретно предлагаете выбрать? :) Не понял вашей политики организации изменения конфигурации grub. Для изменения конфигурации надо: 1. Расшифровать и примонтировать /boot 2. Изменить конфиг 3. Изменить подпись конфига 4. Отмонтировать и закрыть /boot Как обсуждаемая уязвимость поможет получить ключ от шифрования диска когда grub.cfg подписан и его подпись проверяется при загрузке? Этой уязвимости практично не существует.
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (308), 18-Авг-20, 14:54
	> полный контроль над системой с правильными значениями в TPM :) Нет такого в природе, подпись grub.cfg проверяется и "побитого" GRUB не загрузит. Кроме того в TPM GRUB пишет все свои действия, которые изменяют его значение: https://www.gnu.org/software/grub/manual/grub/grub.html#Meas... "If the tpm module is loaded and the platform has a Trusted Platform Module installed, GRUB will log each command executed and each file loaded into the TPM event log and extend the PCR values in the TPM correspondingly."
	Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

	231. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"	+/–
	Сообщение от Аноним (231), 31-Июл-20, 13:24
	Он курящий.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

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

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

	102. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (102), 30-Июл-20, 11:36
	> У меня ВСЕ модули и ВСЕ настройки grub, включая grub.cfg и прочие которые он подгружает подписаны А можно поподробнее, каким образом он подписывается? И как после этого обновлять ядро? Конфиг же перегенерируется, значит, его надо снова подписать, а для этого в системе должен быть приватный ключ. Но тогда вся секурность идёт лесом.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	207. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (207), 31-Июл-20, 08:47
	https://www.gnu.org/software/grub/manual/grub/grub.html#Usin... Скрипт для подписи другой, подписываю все файлы в каталоге /boot, можете начать из того что в документации. Подписывать надо только если меняете ядро, инитрд, grub или его конфиги. Обновление и настройка организованы так чтобы в рабочей системе приватных ключей не было. Если ключ граб изменился то измененный надо добавить в core.img, grub-install это делает. И потом подписать ключом UEFI.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (230), 31-Июл-20, 12:59
	https://www.linux.org.ru/forum/admin/15742224?cid=15744272
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

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

	216. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (219), 31-Июл-20, 10:46
	> Какой дистр? Сам себе дистростроитель. Свой дистр свои правила. Сегодня нет популярных дистров с полностью включенной Integrity. Спросите Мишу пусть нам расскажет почему в ALT Linux политика IMA проверяет только модули ядра и прочие критические элементы, а не всю систему: /bin /sbin /lib /etc /usr ? > Что мешает на компе прописать зловредные ключи при наличии физ доступа? В каком месте собираешься подставить зловредный ключ: https://www.opennet.ru/openforum/vsluhforumID3/121426.html#62 Этот зловредный ключ должен иметь подпись ключа с предыдущего этапа загрузки. Есть такое понятие "верифицированная цепочка загрузки".
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (219), 31-Июл-20, 11:08
	> У grub2 всеже есть баг или фичя: > Если загрузка таки невозможна grub2 вываливается в рутовую "рескуэ" консоль где можно вводить ЛЮБЫЕ команды Документированная фичя: https://www.gnu.org/software/grub/manual/grub/grub.html#GRUB... https://www.gnu.org/software/grub/manual/grub/grub.html#Usin... "Note that signature checking does not prevent an attacker with (serial, physical, ...) console access from dropping manually to the GRUB console and executing: set check_signatures=no To prevent this, password-protection (see Authentication and authorisation) is essential. Note that even with GRUB password protection, GRUB itself cannot prevent someone with physical access to the machine from altering that machine’s firmware (e.g., Coreboot or BIOS) configuration to cause the machine to boot from a different (attacker-controlled) device. GRUB is at best only one link in a secure boot chain." Дыра полудокументирована. Внимание пароль на консоль grub спрашивает только после загрузки grub.cfg где этот пароль находится. До загрузки grub.cfg о паролях grub  ничего не знает и соответственно спрашивать не будет!!! Эту фичу надо профиксить через добавление переменной окружения: rescue_console=on/off она реально удобная и иногда крайне нужная.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	257. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (258), 01-Авг-20, 08:03
	Наверно все же лучшим решением будет перенос пароля с grub.cfg в grub core.img. И всегда при переходе в rescue консоль запрашивать этот пароль. Здесь "уязвимость"/фичя того же порядка как shell busybox в initrd или режим single user mode в Linux. Если диски /boot и / шифрованы, то никто чужой этими фичами воспользовался не сможет.
	Ответить | Правка | Наверх | Cообщить модератору

1. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+6 +/–
Сообщение от Consta (?), 30-Июл-20, 00:22
Богато накопали, однако.
Ответить | Правка | Наверх | Cообщить модератору

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

	30. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+6 +/–
	Сообщение от Аноним (30), 30-Июл-20, 05:35
	> а вот если бы писали на расте - то было бы бедно. А раст что, телепатить умеет? Там ошибка в том что все должно было вырубиться после ошибки, а оно ругнулось сообщением и как ни в чем не бывало продолжило пахать дальше. Раст сам по себе от такого не поможет. И вообще, секурбут очень забавная штука. Ну вот например с ним бывает так: https://www.securityweek.com/microsoft-pulls-uefi-related-wi... ...так что даже если вы и пропатчите grub, это еще не значит что хаксор не загрузит трэшак с касперского буткита. Более того - попытка это заткнуть привела к unbootable системам у хомячков и мс быренько убрал апдейт, видимо не жаждя отвечать за "кирпичи" :D
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от asdasd (?), 30-Июл-20, 07:41
	Не говоря уже о том, что низкоуровневые вещи один черт в unsafe будут, а мантра "небезопасные блоки локализированы и будет проще найти" в жизни не сработает. У C/C++ одних только санитайзеров у компилятора тьма.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+3 +/–
	Сообщение от Аноним (57), 30-Июл-20, 08:47
	> Не говоря уже о том, что низкоуровневые вещи один черт в unsafe > будут, а мантра "небезопасные блоки локализированы и будет проще найти" в > жизни не сработает. У C/C++ одних только санитайзеров у компилятора тьма. Да просто на самом деле правда жизни такова что GRUB жирная и фичастая скотина, почти операционка. И никогда не писался с security in mind - потому что десятилетиями этого от бутлоадеров ну вот вообще совсем не требовалось. Секурбутов не было, а в сеть он особо и не высовывался, особенно большую часть времени работы компа. Так что проблем этого никому не создавало. А тут вдруг внезапно мерзкософты с винтелями решили устроить огораживание своей платформе, в DRMно-ограничительных целях - и требования стали несколько иными. Так то в секурбуте может и есть какой-то пойнт, но в реализации от wintel это лишь кусок пранка да попытка тягануть одеяло на себя, залочив платформу и назначив себя главными кто решает кому из софта жить, а кому умирать.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (60), 30-Июл-20, 08:55
	Эти санитайзеры ругаются на функции glibc. Приходится заменять на аналоги, на которые не ругается, специально, чтобы удовлетворить санитайзеры.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

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

	70. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (70), 30-Июл-20, 09:12
	p.s. в grub нет вызовов glibc :P
	Ответить | Правка | Наверх | Cообщить модератору

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

	272. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Forth (ok), 01-Авг-20, 14:57
	Валезание за пределы буфера заканчивается panic, который приводит к остановке программы. Да, принципиальная возможность перехватить панику есть, задумана для модульных тестов, проверять паникуют ли, когда надо. Использование такого в обычной программе порицается :)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

4. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–10 +/–
Сообщение от marios (ok), 30-Июл-20, 00:41
А всё почему? Потому что GRUB надо переписать на Rust :)
Ответить | Правка | Наверх | Cообщить модератору

	22. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+3 +/–
	Сообщение от Аноним (21), 30-Июл-20, 03:06
	и вообще всю ефи тоже на раст переписать.
	Ответить | Правка | Наверх | Cообщить модератору

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

	94. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+6 +/–
	Сообщение от Аноним (94), 30-Июл-20, 10:27
	EFI лучше выуинуть к чертям собачьим. Производитьелям материнок никто не запрещает пользоваться Coreboot.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	150. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от None (??), 30-Июл-20, 15:37
	Таки да. Оно породило больше проблем, чем решило.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Анином (?), 30-Июл-20, 09:03
	https://www.myinstants.com/instant/counter-strike-go-go-go/
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	93. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (94), 30-Июл-20, 10:25
	Минусующие не понимают в сарказм.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	121. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 30-Июл-20, 12:42
	на JavaScript
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	268. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (231), 01-Авг-20, 11:49
	На Дерипаско.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

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

	6. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+25 +/–
	Сообщение от Аноним (6), 30-Июл-20, 01:14
	если у атакующего есть физический доступ к системе - дырка в грубом это меньшее о чем стоит беспокоиться
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от sysrise (ok), 30-Июл-20, 04:15
	"если у атакующего есть физический доступ к системе...." То перед ним открываются просто безграничные возможности, если конечное он профессиональный IT специалист, а не секретарь руководителя с белыми волосами...
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+3 +/–
	Сообщение от lleeree_ (ok), 30-Июл-20, 10:24
	Это может быть обезьяна с подготовленной флешкой, обученная нажать несколько кнопок.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от rshadow (ok), 30-Июл-20, 15:18
	Да можно и просто с молотком. Потеря машины и данных гарантирована.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от lleeree_ (ok), 30-Июл-20, 16:58
	Шуруповёрт надежнее.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от хотел спросить (?), 30-Июл-20, 06:58
	Ну и какие у него шансы с Epyc, где есть TSME и FDE? Скажем так не очень большие... несанкционированную перезагрузку скрыть нельзя. Вмешательство в корпус тоже сложно не заметить. В таком случае физический доступ дает лишь физическое уничтожение или кражу оборудования. Все пишут как это легко и просто, но это ничерта непросто. Может быть возможно, но точно не просто. Или вы мне расскажете много нового?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	48. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (49), 30-Июл-20, 08:01
	Пункт 2. https://www.opennet.ru/openforum/vsluhforumID3/121426.html#47
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от хотел спросить (?), 31-Июл-20, 09:07
	> Пункт 2. https://www.opennet.ru/openforum/vsluhforumID3/121426.html#47 если факт несанкцированной перезагрузки установлен, то всё - система скомпрометирована - можно восстанавливать бутовый раздел короче это все геморно для прода, но можно заморочиться, особенно если colocation и доступ к железу есть для обслуживания
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 01-Авг-20, 07:55
	> если факт несанкцированной перезагрузки установлен, то всё - система скомпрометирована > - можно восстанавливать бутовый раздел Вы серьезно на каждый проскок питания или что там у вас это делаете? А не проще тогда сделать напрочь readonly образ или грузить сие по сети, etc? Так что образ каждый раз будет правильным? Если уж такой радикализм?
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от хотел спросить (?), 02-Авг-20, 06:07
	>> если факт несанкцированной перезагрузки установлен, то всё - система скомпрометирована >> - можно восстанавливать бутовый раздел > Вы серьезно на каждый проскок питания или что там у вас это > делаете? А не проще тогда сделать напрочь readonly образ или грузить > сие по сети, etc? Так что образ каждый раз будет правильным? > Если уж такой радикализм? в датацентре с аптаймом 99.99? какой-такой проскок питания? грузить по сети через потенциально недоверенную сеть провайдера? можно грузить сервер с флешки во время обслуживания но я уже говорил физически надо быть рядом с датацентром как вариант, снимать хеш бутового раздела (но это не панацея потому что доступ опять таки через KVM) так что дя, я предупреждал параноидальный режим требует соотвествующей и геморной активности хотите почти 100% вероятность от принокновения? придется забыть о комфорте
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (57), 30-Июл-20, 08:56
	> Скажем так не очень большие... несанкционированную перезагрузку скрыть нельзя. Оптимизм это конечно круто, да. Еше скажи что ты полностью понимаешь как все это работает и даже списки CVE регулярно читаешь. > Вмешательство в корпус тоже сложно не заметить. ...поэтому всякие интели сделали чудный, кхе-кхе, дебажный интерфейс через usb. А если покажется мало, они все время норовят вынуть pcie под каким-нибудь предлогом за пределы корпуса. Ну так клево же DMA снаружи отфигачить, комар носа не подточит! Теоретически, конечно, iommu бывает, практически же он есть не у всех, или сконфигурен абы как, и то что от всех выходок железки с dma спасет - где-то 50/50. > В таком случае физический доступ дает лишь физическое уничтожение или кражу оборудования. Или немного dma/debug или даже просто badusb, чтоли, какого, если уж совсем по ламерски :) Ну, блин, оставить вон ту козявку в порту и если ты прошляпишь, она тебе какнить впечатает при удобном случае в консольку лулзов. > Или вы мне расскажете много нового? Можно начать с хотя-бы описальников всего этого от positive techs. Они умеют рассказывать много нового о таких вещах. А, да, и в PSP и в ME, кстати, CVE вполне себе находили. И что может быть прикольнее невидимого кода, который вы даже просканить не можете, в отдельном убер-привилегированном процыке? :)
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	211. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от хотел спросить (?), 31-Июл-20, 09:16
	> Оптимизм это конечно круто, да. Еше скажи что ты полностью понимаешь как все это работает и даже списки CVE регулярно читаешь. Читаю не списки а профильные сайты. И да я смотрел конференцию CCC где эпики раскурочивали. > Ну, блин, оставить вон ту козявку в порту и если ты прошляпишь, она тебе какнить впечатает при удобном случае в консольку лулзов. USB Guard или правила udev. На винде кстати у меня настроены Group Policy которые не подключают устройства пока не будет явного разрешения ))) > Или немного dma/debug или даже просто badusb, чтоли, какого, если уж совсем по ламерски :) Про физическое уничтожение я говорил. А вот DMA? А откуда оно там? TB нету.. USB4 тоже. > А, да, и в PSP и в ME, кстати, CVE вполне себе находили. И что может быть прикольнее невидимого кода, который вы даже просканить не можете, в отдельном убер-привилегированном процыке? :) Это можно сделать на рабочей системе не перегружая кирпич? ))) И да находили 1 CVE с помощью которого кстати Epyc и ковыряли. Дыру закрыли... Короче атака возможна в любом случае только до запуска. В общем я про то что если заморочиться процедура физического доступа без детектирвания вмешательства очень сложна. Вырубается питание на сервере в случае албанского ахтунга и всё. После этого данные недоступны совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (247), 31-Июл-20, 18:40
	> Читаю не списки а профильные сайты. Однако ж CVE были и в PSP и в ME. И что характерно, хаксорский код потом вообще хрен задетектишь и хрен вытряхнешь, а вот он может делать с системой все что возжелает. > И да я смотрел конференцию CCC где эпики раскурочивали. А, хорошая штука. > USB Guard или правила udev. Можно попытаться с тем или иным успехом. На то оно и борьба брони с снарядом. Атакующий может сделать то чего не предусмотрели вы. Как насчет информированной атаки, когда дескриптор копирует вашу клаву? Врядли вы именно число клав в системе считали же. С другой стороны можно сделать и то что атакующий не предусмотрел. Если все же считали - ну, блин, паливо. Крутая атака раскрыта, аверы выстроятся в очередь за экспонатом в коллекцию. > На винде кстати у меня настроены Group Policy которые не подключают устройства > пока не будет явного разрешения ))) Group policy довольно декративная штука на самом деле. Ну и честно говоря не вижу смысла особо трепыхаться в винде. Там MS один черт will prevail и их довольно трудно назвать доверяемыми, дружественными и все такое, как по мне. > Про физическое уничтожение я говорил. Тут смотря насколько далеко с этим хочется зайти и что под этим понимать. С практической точки зрения - есть множество интересных сервисных команд, делающих знатное ололо-пыщ-пыщ. Поимев рута и тем более кернелмод можно нехило покомандовать периферией, так что костей не соберешь. Современное железо весьма хлипкое на самом деле. > А вот DMA? А откуда оно там? TB нету.. USB4 тоже. Интелу очень зудит pcie вынуть. В usb4 проброс pcie таки сделали вроде. В NVME. В новых SD картах тоже вроде ифейсом сделали линии pcie. И маленький гаденыш в сцаной карточке внезапно получает возможность огорошить здорового громилу DMA в память. Еще они любят всякие дебагифейсы в usb высовывать, IIRC что-то типа jtag по смыслу - позволяет очень продвинутый и полный takeover дебажного уровня. Для девов это тул чтобы отлаживать ранний код и изучать состояние железки снаружи, даже если код помер. И кстати JTAG в более мелких чипах тоже много лулзов на тему подкидывает. Вон actel в своих FPGA тоже сделал себе фавор с недокументированными командами, сливаюшими прошивку в обход их хваленого шифрования. А какой-то хмырь поFUZZил jtag да нашел команды случайно. > Это можно сделать на рабочей системе не перегружая кирпич? ))) Это сложные и капризные атаки. Но их возможность была доказана. И если вам кажется что так не бывает, посмотрите как иранцам вынесли центрифуги для понимания того как это может быть. > И да находили 1 CVE с помощью которого кстати Epyc и ковыряли. Первый не последний, да и не все юзеры заапдейтят фирмваре. И кроме того ничего хорошего от такого вендыря ждать уже не приходится. Новые железки будут все подлей и гаже. > Дыру закрыли... Короче атака возможна в любом случае только до запуска. И все же мне сильно не нравится привилегированная, резидентная фигня side by side с моей ос с мутным левым блобокодом и максимальными правами в системе под прикрытием что это "для безопасности". Это очень хреновая "безопасность" и больше всего похоже по конструкции на троянского коня. > Вырубается питание на сервере в случае албанского ахтунга и всё. > После этого данные недоступны совсем. Шифрование дисков? Но с шифрованием проблема в том что если интрудер все же пролез в именно живую систему, он таки имеет доступ в расшифрованное добро. И тут такая дилемма что атакующий в принципе может все то же что и легитимный юзер, если пролез.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (81), 30-Июл-20, 09:10
	Вот, еще один Аноним задался правильным вопросом! https://www.opennet.ru/openforum/vsluhforumID3/121426.html#47 Практично уязвимости CVE-2020-10713 (BootHole) не существует!!! Зачем же ее придумали в TedHat? Правильно, чтобы под предлогом исправления внести какую-то дрянь и что-то похерить...
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	290. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (290), 03-Авг-20, 14:41
	Похерили? http://techrights.org/2020/07/30/wontboot/
	Ответить | Правка | Наверх | Cообщить модератору

7. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
Сообщение от Аноним (7), 30-Июл-20, 01:14
Ну а что мешает ровно таким же образом вместо grub.cfg подменить ядро/инитрамфс на бэкдорнутое?
Ответить | Правка | Наверх | Cообщить модератору

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

	58. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (81), 30-Июл-20, 08:49
	Кем должно проверяется ядро если в процессе загрузки используется grub? Внимательно смотри на картинку!
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (206), 31-Июл-20, 08:41
	> Кем должно проверяется ядро если в процессе загрузки используется grub? Grub, разумеется.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от AnonPlus (?), 30-Июл-20, 01:36
	Ну как бы SecureBoot именно против такой подмены и существует. Ты загоняешь в прошивку свои ключи вместо Microsoft-овских, подписываешь загрузчик, подписываешь ядро и всё - при подмене загрузчика или ядра на неподписанное (у злоумышленника твоей подписи же нет), будет облом.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	32. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–2 +/–
	Сообщение от Аноним (31), 30-Июл-20, 05:43
	> Ну как бы SecureBoot именно против такой подмены и существует. Ты загоняешь > в прошивку свои ключи вместо Microsoft-овских, подписываешь загрузчик, подписываешь ядро > и всё - при подмене загрузчика или ядра на неподписанное (у > злоумышленника твоей подписи же нет), будет облом. Вот та часть "вместо" может и не получиться. Потому что они предустановлены и не факт что удастся вытряхнуть. А "вместе" с мсовскими - ну вон там блэкхэты какой-то буткит касперского подписаный мсом вон освоили для этого дела. И попытки это зарубить сделали юзерам кирпичи, так что ms отпедалил взад.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (35), 30-Июл-20, 05:54
	Это только если биос кривой, ну или еще если это ноут по акции с Microsoft куплен Windows only. Secureboot тут непричем.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (-), 30-Июл-20, 09:00
	> Это только если биос кривой, ну или еще если это ноут по > акции с Microsoft куплен Windows only. Secureboot тут непричем. Ну, блин, биос по жизни так или иначе кривой. Другим он просто не бывает. Уж допустим безглючный ACPI в этом хламе я вообще ни разу в жизни не встречал. Зато встречал всякие инженерные пароли и прочие предустановленные ключи, намекающие кто кого и за что держит, а для пущей "безопасности" еще бутгад какой-нибудь. Проблема только в том что в этой схеме безопасно в результате интелу, майкрософту, ну может OEM еще накрайняк. А юзер и его проблемы в эту формулу так и вообще не входят - юзеру вообще возможность настоящего take ownership не оставлена. Это когда root key - того юзера, код - юзера, а все остальное, соответственно, железка шлет стройными рядами на йух. Вот так оно конечно могло бы стать безопаснее - но лошпедам потребителям это как-то зело жирновато будет и такой руль им почему-то как обычно не отсыпали, вместо этого подсунув сундук с двойным дном.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от AnonPlus (?), 31-Июл-20, 02:12
	Просто не покупай Surface и подобные железки, где ключи нельзя вытряхнуть. Во всех виденных мною десктопных материнках, можно удалить предустановленные ключи. Особые параноики могут также раздербанить прошивку и физически вычистить эти предустановленные ключи, благо утилит для работы с UEFI-прошивками в достатке.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	204. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (206), 31-Июл-20, 08:36
	> Просто не покупай Surface и подобные железки, где ключи нельзя вытряхнуть. На железке заранее не написано - можно там или нельзя. > Во всех виденных мною десктопных материнках, можно удалить предустановленные ключи. Особые > параноики могут также раздербанить прошивку и физически вычистить эти предустановленные > ключи, благо утилит для работы с UEFI-прошивками в достатке. Увы, это не особые параноики а мамкины кулхаксоры из уютной виндочки с довольно так себе понятиями о информационной безопасности. И как максимум все это голимые полумеры. Даже если все это сделать с всеми этими тантрами, у меня останутся несколько мегов мутных блобов без сорца делающих фиг знает что. И это фиг знает что - совсем никто не аудитил, по большому счету.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (81), 30-Июл-20, 08:58
	> Ну как бы SecureBoot именно против такой подмены и существует. Ты загоняешь в прошивку свои ключи вместо Microsoft-овских, подписываешь загрузчик, подписываешь ядро и всё - при подмене загрузчика или ядра... Кто проверяет подписи: 1. Самого UEFI перед его загрузкой и испоьнением? 2. Ядро grub с необходимыми модулями крыптографии для расшифровки /boot, публичными ключами grub, модулями grub для проверки подписей и переменными окружения grub? 3. Подгружаемые по требованию модули, настройки grub? 4. Ядра и инитрд OS? 5. Процесс #1 init и все остальные исполняемые в системе файлы, библиотеки, настройки и данные доступные только для чтения? Что такое доверительную сертифицированная цепочка загрузки OS?
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	66. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 30-Июл-20, 09:05
	> 1. Самого UEFI перед его загрузкой и испоьнением? На интеле потенциально бутгад может. Проблема в том что это подписывается ну вообще совсем не вашим ключом. И стало быть - обороняет систему от вас и вашего софта, ололо. На случай если вы корбут какой удумаете втулить вместо мутной блоботы, например, оно вам неплохо врежет, хаха :) > 2. Ядро grub с необходимыми модулями крыптографии для расшифровки /boot, публичными ключами > grub, модулями grub для проверки подписей и переменными окружения grub? Теоретически первую часть сам секурбут, свои компоненты уже grub ессно. > 3. Подгружаемые по требованию модули, настройки grub? Это уже сам grub. > 4. Ядра и инитрд OS? См. выше. > 5. Процесс #1 init и все остальные исполняемые в системе файлы, библиотеки, > настройки и данные доступные только для чтения? Это уже епархия ядра и ОС. Для этого в лине уже тоже есть всяческие. Хотите познакомиться с ними сложным методом? Купите флагман на смартфоне и поизучайте как оно OEMа от вас умеет оборонять. А если сможете надуть, резко станете звездой XDA или что там кому по вкусу :)
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (81), 30-Июл-20, 09:29
	> > 1. Самого UEFI перед его загрузкой и испоьнением? > На интеле потенциально бутгад может. Проблема в том что это подписывается ну вообще совсем не вашим ключом. И стало быть - обороняет систему от вас и вашего софта, ололо. На случай если вы корбут какой удумаете втулить вместо мутной блоботы, например, оно вам неплохо врежет, хаха :) Зависит от производителя. В идеале процессором аппаратно есть возможность шифрования корневого ключа платформы. Сам корневой ключ платформы, должен генерироваться когда комп стрит уже у пользователя и этим, своим, корневым ключом платформы пользователь подписывает свой UEFI со своими публичными ключами secure boot. >> 2. Ядро grub с необходимыми модулями крыптографии для расшифровки /boot, публичными ключами grub, модулями grub для проверки подписей и переменными окружения grub? > Теоретически первую часть сам секурбут, свои компоненты уже grub ессно. Здесь все целиком должно быть подписано ключом secure boot и проверяет: ядро grub с необходимыми модулями крыптографии для расшифровки /boot, публичными ключами grub, модулями grub для проверки подписей и переменными окружения grub - только secure boot. Оно все идет одним образом, одним загрузочным файлом, на который ставится одна подпись от ключа secure boot. >> 5. Процесс #1 init и все остальные исполняемые в системе файлы, библиотеки, настройки и данные доступные только для чтения? > Это уже епархия ядра и ОС. Для этого в лине уже тоже есть всяческие. Хотите познакомиться с ними сложным методом? Купите флагман на смартфоне и поизучайте как оно OEMа от вас умеет оборонять. А если сможете надуть, резко станете звездой XDA или что там кому по вкусу :) Есть много но по дефолту, родным в Linux уже 10 лет есть реализация Integrity от IBM в ввиде IMA/EVM. Она имеет свои нюансы, но если их учесть замечательно работает на серверах и рабочих станциях.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (126), 30-Июл-20, 14:10
	> Зависит от производителя. С точки зрения покупателя - лотерея! Без возможности оверрайда, если не угадал. Ну разве что железку назад в магазин сдать, но это канительно уже. > В идеале процессором аппаратно есть возможность шифрования корневого ключа платформы. А в реалиях гранд-мастер-ключ вообще у фирмы Интел! В ME зашит - и на самом деле рулит планетой все же эта чудная фирмочка. Ну а для развесивших уши лохов они как максимум имеют предложить лишь декоративную иллюзию контроля. О чем я? Самым привилегированным хозяином системы, с правом так сказать, первой ночи (подпись кода который начинает раскочегарку и имеет максимальные доступы) почему-то внезапно оказывается фирма Интел. И вы вообще не можете лишить их этого - их кей вхардкожен в boot ROM ME, насколько я понял :) Ну и с PSP амд видимо в том же направлении двигает, вы ж не думаете что то что вы галочку в биосе поставили и правда его полностью отрубает, не? Низя быть столь наивным лохом - лучше посмотреть на процедуру старта платформы. И если он вам DRAM подымает, если вы его реально вырубите - то обломаетесь по полной :) > Сам корневой ключ платформы, должен генерироваться когда комп стрит > уже у пользователя и этим, своим, корневым ключом платформы пользователь подписывает > свой UEFI со своими публичными ключами secure boot. Я бы сказал что вся эта махровая оверинженерия служит в основном одной цели: создать у лоха иллюзию контроля, в то время как де-факто максимальный уровень контроля над происходящим окажется почему-то у совсем других физиономий. А так чтобы просто, прозрачно и все честно - ага, ща! > Здесь все целиком должно быть подписано ключом secure boot и проверяет: ядро > grub с необходимыми модулями крыптографии для расшифровки /boot, публичными ключами grub, > модулями grub для проверки подписей и переменными окружения grub - только secure boot. Boot loaders i-го уровня один хрен by design грузят какой-то код дальше. И будет ли это кернель операционки или модули самого лоадера - а в чем принципиальная разница? Что именно бут сделает - implementation specific. И даже более того - ядро тоже грузит модули. И даже kexec() может устроить. Поэтому для сохранения концепции бут проверяет ядро и, вероятно, инитрд если он есть. А ядро должно проверить свои модули, соответственно. > Оно все идет одним образом, одним загрузочным файлом, на который ставится одна > подпись от ключа secure boot. Вы вообще grub видели, на минуточку? Каким к хренам отдельным образом? У него кучка файликов модулей еще есть. Которые он может загружать, не только сразу но и динамически, позже, вроде бы опосля уже. И его обязанность стало быть для поддержания концепции - проверить эти компоненты. И да, если вы не поняли: после того как энную часть последовательности пнули, поддержка иллюзии или ее разрушение - на совести этой части уже. Если этот лоадер, кернел или кто там сделает явно провальное действо (или добровольно решит прервать цепочку) - концепция пойдет лесом. В Nokia N900 так например было сделано - ROM OMAP-а честно проверял X-Loader, но далее тот запускал более жирный лоадер которому пофиг на подписи, цепочка прерывается и юзерам доступна загрузка любых ядер которые они там хотят. Это так и было задумано, но зачем они вообще активиоровали секурбут чтобы потом его картинно зарубить на ранней стадии так и осталось небольшой инженерной загадкой. Возможно у них был большой сток чипов где он уже активен с фабы, или типа того. > Есть много но по дефолту, родным в Linux уже 10 лет есть > реализация Integrity от IBM в ввиде IMA/EVM. Она имеет свои нюансы, > но если их учесть замечательно работает на серверах и рабочих станциях. Ну да, при сильном желании чем-то таким можно попытаться линуха огородить. Насчет замечательно - ну, вообще, оно никогда не делалось с настолько параноидальной security in mind - и поэтому логических лазеек бывает довольно много. Однако lockdown я себе все же включил, благо у меня ключ на подпись ядра есть и вот так он мне вовсе даже и фича, ага :). Но, блин, для этого по факту надо стать ... почти сам себе OEM'ом.
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (219), 31-Июл-20, 10:37
	> С точки зрения покупателя - лотерея! Читать документацию перед покупкой системы. > И вы вообще не можете лишить их этого - их кей вхардкожен в boot ROM ME, насколько я понял :) На сколько я понял вхардкорен куда-то только "аппаратный ключ платформы", который идентичен для всех чипов одной модели и он используется только для шифрования/расшифровки "корневого ключа платформы", которым и подписывается UEFI. "Корневой ключ платформы уже уникален для каждого компа и может создаватся его владельцем! > А в реалиях гранд-мастер-ключ вообще у фирмы Интел! В ME зашит - и на самом деле рулит планетой все же эта чудная фирмочка. Ну а для развесивших уши лохов они как максимум имеют предложить лишь декоративную иллюзию контроля. > Ну и с PSP амд видимо в том же направлении двигает, вы ж не думаете что то что вы галочку в биосе поставили и правда его полностью отрубает, не? Низя быть столь наивным лохом - лучше посмотреть на процедуру старта платформы. И если он вам DRAM подымает, если вы его реально вырубите - то обломаетесь по полной :) Меня не спрашивал никто когда строили этот мир. Да сегодня государства хотят шпионить за своими гражданами. Intel наверняка попросили поделится нужным, а быть может даже обязали сделать. Производителей поставят раком и обяжут сделать так чтобы государство имело возможность пасти своих граждан. Пример: КОЛЛЕГИЯ ЕВРАЗИЙСКОЙ ЭКОНОМИЧЕСКОЙ КОМИССИИ РЕШЕНИЕ от 21 апреля 2015 года N 30 "О мерах нетарифного регулирования" http://docs.cntd.ru/document/420269541 блок 40 Кажись о компах. Всех неугодных на рынок не пустят административными методами, а если кто ввезет неудобный для государства комп - посадят. Да вы правы, что речь о лохах, но не в магазине без выбора, а на избирательных участках и изберательных коммисиях... > В Nokia N900 так например было сделано - ROM OMAP-а честно проверял X-Loader, но далее тот запускал более жирный лоадер которому пофиг на подписи, цепочка прерывается и юзерам доступна загрузка любых ядер которые они там хотят.  Это так и было задумано, но зачем они вообще активиоровали секурбут чтобы потом его картинно зарубить на ранней стадии так и осталось небольшой инженерной загадкой. Похоже на недоделку. Или технически не знали как сделать или им административно запретили. > Насчет замечательно - ну, вообще, оно никогда не делалось с настолько параноидальной security in mind - и поэтому логических лазеек бывает довольно много. IBM нормально сделало IMA/EVM я его патчу чтобы ACL и PAX мне защищало, а SELinux, SMAC не использую. Оно работает очень быстро. Есть документированна лазейка в ввиде подмены каталога на символьческую ссылку, но она проявляется не во всех политиках IMA и подробно описаны методы чтобы от нее защитится. > Но, блин, для этого по факту надо стать ... почти сам себе OEM'ом. Пока топовые дистры игнорируют Integrity, а в РФ есть административный запрет: https://www.linux.org.ru/forum/security/15283293?cid=15285785
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 31-Июл-20, 19:36
	> Читать документацию перед покупкой системы. Честно сказать юзеру что его держат за лоха? Это не очень популярно :) > На сколько я понял вхардкорен куда-то только "аппаратный ключ платформы", Вхардкожено то что делает owner'а настоящим owner'ом - первый ключ который и дает полный, безусловный, фактический руль от системы. Точнее, вроде, как обычно, его хэш в фьюзы. Это самый крутой ключ который есть в системе с такой технологией. И он "почему-то" не ваш. И стало быть вы там всего лишь гость и делаете там не более чем одобрил хозяин того ключа. А все остальные ключи в системе соотносятся с этим так же как фуфельные кольца соотносились с кольцом Саурона, прикольно абстракция разрисована. > "корневого ключа платформы", которым и подписывается UEFI. "Корневой ключ платформы уже > уникален для каждого компа и может создаватся его владельцем! Угу, угу, как там, 9 [фуфельных] колец каким-то лохам-гномам, другим тоже побрякушек отсыпать. Лохи будут ходить с важным видом, думая что чем-то рулят. Хмырь в темной башне ржот в тряпочку, а когда наступит время - популярно объяснит. > может даже обязали сделать. Довольно трудно обязать людей что-то сделать если они это не хотят сделать. Судя по тому что я вижу wintel это все для себя прежде всего сделали, в DRMно-ограничительных и бабкоотжимательных целях, а остальное до кучи, коли оно уж есть. > Производителей поставят раком и обяжут сделать так чтобы государство имело возможность > пасти своих граждан. Не надо мерять по совдепу все остальное. В США например если такое реально всплывет, скандалы будут знатные, производитель по судам задолбается бегать. См. чего было после сноудэна. Но интель свои замашки порулить планетой, на пару с мс, демонстрировал давно. SMM они сделали аж в 386, когда компы были уделом узкой группы фриков и никого не интересовали особо. Кроме руководства интеля, которое видимо уже тогда прочухало что порулить планетой - прикольно. > выбора, а на избирательных участках и изберательных коммисиях... Ну я и выбрал - голосануть ногами, в место поприличней. Надоели бандюки. > Похоже на недоделку. Нет. У них была полная схема в других девайсах. Вполне эффективная. Просто это был первый девайс с Linux - и это было для dev-like народца. Который зарубать не очень катит, и репутационно, и с точки зрения разработки, так что 99% что это именно осмысленная целенаправленная активность. Они специально подписали разлоченый бут походу, специфика девайса. Я только не понял почему они не могли в камне разлочить. Может техасцы не такие гибкие в этом. Большая часть ARM идет с фаб нулевые: секур бут вырублен, ключ в фузах не прописан. Можно самому свой вписать - кто первый встал, того и тапки. Возможно техасцы настолько наглые что сами и лезли в тапки, не доверяя нокии, или черт их там знает. > Или технически не знали как сделать или им административно запретили. Все они знали и умели - в соседних "BB5" и даже сотовом модеме того же N900 (он архитектурно второй чип похожий по структуре, но с RTOS) это активно и работает. > IBM нормально сделало IMA/EVM я его патчу чтобы ACL и PAX мне > защищало, а SELinux, SMAC не использую. На мой вкус selinux - куча геморроя с минимальным результатом. Я предпочитаю контейнеры и виртуалки - эффект в ограничении урона и изоляции сравнимый, нарулить неизмеримо проще. > Пока топовые дистры игнорируют Integrity, Можно придумать множество иных вариантов, сравнимых по эффективности. Ну там readonly файлуху. Собственно половина "мыльниц" так и сделаны. Там чисто технически записать в ФС ничего нельзя, squashfs вообще запись не предусматривает. > а в РФ есть административный запрет: > https://www.linux.org.ru/forum/security/15283293?cid=15285785 Я не по паспорту а по морде. И спокойно ходил с GPS когда какого-то неудачника пытались посадить за это. Но как вы поняли, естественно, я дважды подумаю до оказания таких услуг на коммерческой основе гражданам РФ. В РФ видите ли вообще бизнес вести в принципе достаточно опасно.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (258), 01-Авг-20, 08:58
	> Вхардкожено то что делает owner'а настоящим owner'ом - первый ключ который и дает полный, безусловный, фактический руль от системы. Точнее, вроде, как обычно, его хэш в фьюзы. Это самый крутой ключ который есть в системе с такой технологией. И он "почему-то" не ваш. И стало быть вы там всего лишь гость и делаете там не более чем одобрил хозяин того ключа. > А все остальные ключи в системе соотносятся с этим так же как фуфельные кольца соотносились с кольцом Саурона, прикольно абстракция разрисована. Я подробностей реальной технической реализации не знаю. Читал популярные, а не технические статейки с официальных сайтов. > Честно сказать юзеру что его держат за лоха? Это не очень популярно :) Да! Вы правы. Но если допустить, что Intel не солгала о "аппаратном ключе платформы" и о "корневом ключе платформы", то из их док следует: 1. "Аппаратный ключ платформы" изменить невозможно и он идентичен для одной модели чипсета. Разные модели чипсетов имеют разные "аппаратные ключи платформы". 2. "Аппаратный ключ платформы" Intel никому не дает. ;) 3. "Аппаратный ключ платформы это не сертификат и не публичный ключ, он не может ничего проверять и ничего не удостоверяет. Его задача обеспечить шифрование/расшифровку приватного "корневого ключа платформы". 4. "Корневой ключ платформы" уникален для каждого компа. Создается на самом компе пользователя и никогда его не покидает. ;) Охраняется "аппаратным ключом платформы". Приватный "Корневой ключ платформы" подписывает UEFI. Публичный "корневой ключ платформы" проверяет целостность UEFI и Secure Boot ключей в нем каждый раз при загрузки компа. Можно Intel сказать спасибо за работу. > Угу, угу, как там, 9 [фуфельных] колец каким-то лохам-гномам, другим тоже побрякушек отсыпать. Лохи будут ходить с важным видом, думая что чем-то рулят. Хмырь в темной башне ржот в тряпочку, а когда наступит время - популярно объяснит. Хотя бы от Васи соседа защитит. > Довольно трудно обязать людей что-то сделать если они это не хотят сделать. Судя по тому что я вижу wintel это все для себя прежде всего сделали, в DRMно-ограничительных и бабкоотжимательных целях, а остальное до кучи, коли оно уж есть. Да, "корневой ключ платформы" защищает DRM идентификатор вашего компа EPID (Enhanced Privacy ID) от вас! Чтобы вы его не изменили и не выдали свой комп за другой в сети. > Не надо мерять по совдепу все остальное. В США например если такое реально всплывет, скандалы будут знатные, производитель по судам задолбается бегать. См. чего было после сноудэна. Но интель свои замашки порулить планетой, на пару с мс, демонстрировал давно. SMM они сделали аж в 386, когда компы были уделом узкой группы фриков и никого не интересовали особо. Кроме руководства интеля, которое видимо уже тогда прочухало что порулить планетой - прикольно. Сравнивать можно и с северной Кореей и радоваться что у нас лучше. Скандалы будут, но их замнут... > Ну я и выбрал - голосануть ногами, в место поприличней. Надоели бандюки. Сам прикол в том что Путин с Единой Россией думают, что они решением N 30 "О мерах нетарифного регулирования" решают какая криптография в РФ разрешена. В реалиях на 90% разрешенные алгоритмы криптографии на территории РФ определяют экспортные ограничения в США. > На мой вкус selinux - куча геморроя с минимальным результатом. Я предпочитаю контейнеры и виртуалки - эффект в ограничении урона и изоляции сравнимый, нарулить неизмеримо проще Нравится RSBAC от Grsecurity. Кто чему верит, я так изолируют: https://wiki.gentoo.org/wiki/Chrooting_proxy_services > В РФ видите ли вообще бизнес вести в принципе достаточно опасно. Точно, особенно в ИТ и с Secure Boot: https://www.linux.org.ru/forum/security/15283293?cid=15285785
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от AnonPlus (?), 31-Июл-20, 02:15
	1. Никто, но есть такая прекрасная штука как TPM-модуль. Задействуй его в процессе шифрования накопителя (у TPM один из регистров отвечает за контрольную сумму прошивки). В этом случае, если хоть байт в прошивке изменится, регистры TPM выдадут иное значение и накопитель не расшифруется. А дальше уже по цепочке: UEFI проверяет подпись загрузчка, загрузчик - подпись ядра.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	196. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от AnonPlus (?), 31-Июл-20, 02:17
	Уточнение, есть еще BootGuard, вот он может проверять подпись прошивки. Но он лишает тебя возможности самому модифицировать прошивку. Поэтому я предпочитаю связку "шифрование системного раздела + TPM", что обеспечивает защиту от незаметного изменения прошивки.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (81), 30-Июл-20, 09:11
	Вот, еще один Аноним задался правильным вопросом! https://www.opennet.ru/openforum/vsluhforumID3/121426.html#47 Практично уязвимости CVE-2020-10713 (BootHole) не существует!!! Зачем же ее придумали в TedHat? Правильно, чтобы под предлогом исправления внести какую-то дрянь и что-то похерить...
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	71. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (70), 30-Июл-20, 09:14
	> Зачем же ее придумали в TedHat? Однако демьян апдейты grub все же выкатил. А то что она не эксплуатируемая в большинстве конфиг - отлично, но баги чинить все же надо.
	Ответить | Правка | Наверх | Cообщить модератору

9. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–4 +/–
Сообщение от foo (?), 30-Июл-20, 01:20
systemd-boot рулит, systemd-boot неуязвим
Ответить | Правка | Наверх | Cообщить модератору

10. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
Сообщение от Андрей (??), 30-Июл-20, 01:30
Дыра в самом SB, но виноват grub ? :think:
Ответить | Правка | Наверх | Cообщить модератору

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

	33. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (31), 30-Июл-20, 05:45
	> Переполнение буфера в grub, читаем внимательно, да? Там соль не в этом, а в том что он продолжил как ни в чем ни бывало пахать после явно фатально ошибки. Всего-то выкинув сообщение и продолжив. То что за таким поведением проги следует - в общем то undefined.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (102), 30-Июл-20, 11:44
	Фатальная ошибка в загрузчике = кирпич.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (129), 30-Июл-20, 14:22
	> Фатальная ошибка в загрузчике = кирпич. Вы только подумайте, секурбут в лучшем для вас случае ничего не делает. В случае срабатывания он делает вам именно кирпич. Это некий tradeoff: вы просаживаете reliabilty в пользу security - потому что измененный код делающий нечто непредсказуемое как минимум теоретически будет зарублен. У самого по себе линукскернела есть более мягкая и менее саботерская реализация, кста: оно при несовпадении подписи модуля может пометить себя как tainted но продолжить работу. Однако при этом стоит понимать что особо наглый и прошареный ("хакерский") модуль может в принципе tainted состояние в памяти и почистить если ему сильно надо софт наесть.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 15:43
	Поэтому в Linux есть режим lockdown, в котором хакерские модули грузить нельзя.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 31-Июл-20, 19:51
	> Поэтому в Linux есть режим lockdown, в котором хакерские модули грузить нельзя. А прикольно о нем рассказать тому кто его как раз у себя и включил?
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноньимъ (?), 01-Авг-20, 11:18
	Концептуально, в чем безопасность URFI секур бута если ошибка в приложении вне UEFI его ломает? Если соответствие загружаемых в память блобов проверяет не ваше железо, условный UEFI который прошит в биосе, то накой оно сдалось вообще? Ну то есть, цепочка доверия, ага. Я относительно простым UEFI загружаю очень сложный Груб с сотнями тысяч строк когда, которому я должен доверять, я именно должен доверять его способности ПРОВЕРИТЬ достоверность загружаемых модулей ведра или чего там. А потом то, что загрузил груб, то-же должно проверять уже то что загружает ОНО. И я должен доверять и ЕМУ. То есть "цепочка доверия" это не цепочка, это дырявое ведро, каждый новый "загружатель" в цепочке - новая дыра. А "пользователь", системный инженер, должен убить кучу сил и времени на организацию подписывания всей этой хтонической ядромодульной сороконожки, приэтом система становиться дубовой и неюзабельной, потому что, конфиг груба нужно то-же подписывать. Это типичный лютейший безумный поттерринг, решение проблемы которой нет и быть не должно.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

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ообщить модератору

15. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
Сообщение от Аноним (15), 30-Июл-20, 02:09
Критическая необходимость...
Ответить | Правка | Наверх | Cообщить модератору

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

	36. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (36), 30-Июл-20, 05:56
	> Когда трудности нет, то что тогда преодолевать? Возьми шмот и айда в горы, узнаешь :)
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (81), 30-Июл-20, 08:37
	Куда ты его посылаеш? Там сдохнуть вполне реально! Прочти статистику по РФ: в год ~1000 пропавших без вести в лесах...
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (70), 30-Июл-20, 09:19
	> Куда ты его посылаеш? Там сдохнуть вполне реально! К преодолению трудностей. К тому же по своему прикольному. Вообще, так по жизни - сдохнуть вполне реально. Гарантия 100%. Поэтому щелкать клювом вообще не рекомендуется. > Прочти статистику по РФ: в год ~1000 пропавших без вести в лесах... А теперь посмотрим статистику ДТП, почувствуем разницу. Но да, безбашенно такие вещи делать не рекомендуется.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Sgt. Gram (?), 30-Июл-20, 11:51
	> Когда трудности нет, то что тогда преодолевать? Русский не родной?
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	175. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Alexey (??), 30-Июл-20, 19:03
	Даже если был бы не родной, то как показать где должно быть разделение и как читать то, что написал автор? По произношению между "то" и "что" нет препинания. В данной теме описывается загрузчик, а не правила написания. Всё-равно присутствует загрузочная область с прошитым указателем, который начинает загрузку. Способ загрузки не сильно влияет на безопасность, с моей точки зрения :) Придумывать разные способы для одного и того же действия, это хорошо, для тех, кто так зарабатывает.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Sgt. Gram (?), 30-Июл-20, 21:35
	Да какое препинание? Союзы научись употреблять. Либо s/когда/если/, либо s/то\(гда\)?//g.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Alexey (??), 31-Июл-20, 10:14
	Про союзы на regteston@mail.ru аж интересно стало, научи будь добр в данном конкретном примере.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Sgt. Gram (?), 31-Июл-20, 16:43
	Что тебе непонятно? Если что-то, то нечто. Когда что-то, нечто. И никак иначе.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Alexey (??), 31-Июл-20, 20:56
	А почему нельзя? Или он не Великий и могучий.. пиши разъяснения на почту с примерами и пунктами правил не забудь указать применение кем в литературе, а то складывается впечатление, что я Тебя не понял.
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Sgt. Gram (?), 02-Авг-20, 15:10
	Купи учебник, найми препода нормального (не репетитора для ЕГЭ). Ишь какой, на халяву ему всё подавай.
	Ответить | Правка | Наверх | Cообщить модератору

	291. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Alexey (??), 04-Авг-20, 00:14
	Тебе трудно указать где это правило, когда оно было введено и на основании чего? Сам то русский знаешь?  Благодарю модератора за терпение к данному флейму.
	Ответить | Правка | Наверх | Cообщить модератору

17. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
Сообщение от Аноним (17), 30-Июл-20, 02:20
>GRUB2 Чем оно лучше lilo?
Ответить | Правка | Наверх | Cообщить модератору

	24. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (21), 30-Июл-20, 03:13
	Оно лучше, чем lilo
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (35), 30-Июл-20, 06:00
	Своей громоздкостью, глючностью и вечными проблемами
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	44. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+5 +/–
	Сообщение от Адекват (ok), 30-Июл-20, 06:47
	А еще негуманоидным синтаксисом, реально нужно иметь степени по клинописи, криптографии, латыни, изотереке, чтобы понять что там к чему. Вот в grub 0.97 был гуманоидный синтаксис: # ((1) Arch Linux title  Arch Linux Fallback root   (hd0,0) kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/131aa439-f2c0-41e3-b239-c778fcf572a5 rootfstype=xfs ro initrd /boot/kernel26-fallback.img просто запомнить можно было, а по примеру интуитивно понять что к чему, попробуйте без интернетов и манов понять что в конфиге груб2. Нет, реально же просто три строчки, ну 4, 4ая титл, но для загрузки - три блин строчки нужно всего !!
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+7 +/–
	Сообщение от пох. (?), 30-Июл-20, 09:36
	> Вот в grub 0.97 был гуманоидный синтаксис: но к сожалению, альтернативно-одаренным его было никак не понять. Поэтому он объявлен нимодна-нималадежна, разработка запрещена под страхом отлучения от святого гна, и вместо него запилена невменяемая блоатварь, синтаксис которой предназначен вовсе не для гуманоидов, а для косоруких скриптов. СКРИПТОВ, блжад, в initial loader, который когда-то в 440 байт помещался. Зато, вот, с нескучным insecure boot (поздравляем со скомпроментированным ключом глупой microsoft - а нехрен было подписывать гнутый трешак) и кучей других интересных свойств - например, возможностью после (ненужного!) автообновления попасть в "rescue mode" и обнаружить что прочитать диск нам нечем - модуль не подгрузился, необходимый для загрузки модуля.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 30-Июл-20, 14:55
	> СКРИПТОВ, блжад, в initial loader, который когда-то в 440 байт помещался. Так он и теперь помещается. Просто он запускает более жирный лоадер, тот догружает основную тушку груба, тот всякие модули и проч. А вот сам этот 440 байтный бут как максимум умел пинать себе подобного в партиции. И не то чтобы тот был сильно умнее - в конечном итоге он тоже запускал что-то более жирное. > Зато, вот, с нескучным insecure boot (поздравляем со скомпроментированным ключом глупой > microsoft - а нехрен было подписывать гнутый трешак) Да нисы, там у кашпировского буткит который вон мс зассал зарубить потому что это юзерям машины кирпичит. Так что если хакерье захочет тебе вгрузить гуано - они его возьмут. Нафиг им целая операционка типа груба для этого? Это ж паливо какое. Кроме того операционка являет собой примерно то же самое, ее в конечном итоге тоже запустят, ну и смысла с твоего пиндежа в итоге мало.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 30-Июл-20, 16:23
	> Так он и теперь помещается. Просто он запускает более жирный лоадер или не запускает, и ты сосешь лапу и бежишь за rescue диском (а потом разгадываешь ребус, что ж этой твари такого было надо) > А вот сам этот 440 байтный бут как максимум умел пинать себе подобного в партиции. он умел блоклист прочитать, составленный и подсунутый заранее - чему нынешний разучился (точнее, использует не по делу и в результате ломается на пустом месте). Особенно бредово выглядит их реализация для efi, где не надо было никаких специальных умений и блоклистов - но вместо того чтобы просто прочитать два файла, понах...вертили цепочку загрузчиков опять же умудряющихся терять свои бестолковые бесполезные модули и не работать. Зато вот, мы умеем нескучные скрипты в загрузчике! Ой, нас через них поимели, кто бы мог подумать да и было ли ему чем?!
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 31-Июл-20, 12:02
	> или не запускает, и ты сосешь лапу и бежишь за rescue диском > (а потом разгадываешь ребус, что ж этой твари такого было надо) Я видел много странной фигни, но вот именно такого ни разу не встречал. За десятилетия. Нет, наверное, теоретически и так можно, но практически для этого похом надо быть :P. > он умел блоклист прочитать, составленный и подсунутый заранее - чему нынешний разучился > (точнее, использует не по делу и в результате ломается на пустом месте). У GRUB он так вообще обычно подчитывает оверлей в "track0" (сразу за партишн тэйбл, именно поэтому советуют оставлять там пару мегов до начала партишнов) - а вот тот уже более жирный, умный и подгружает основную тушку более продвинуто. > Особенно бредово выглядит их реализация для efi, где не надо было никаких > специальных умений и блоклистов - но вместо того чтобы просто прочитать > два файла, понах...вертили цепочку загрузчиков опять же умудряющихся терять свои бестолковые > бесполезные модули и не работать. Вот это я особо не изучал, честно говоря. И не знаю какие там были предпосылки. Мне уефанство в целом интересно только в контексте "must die" :D > Зато вот, мы умеем нескучные скрипты в загрузчике! Ой, нас через них > поимели, кто бы мог подумать да и было ли ему чем?! Ну вообще скрипты в загрузчике бывают и достаточно прикольно - типа попробовали раз, FAIL, двас, FAIL, трис, FAIL - о, а давайте-ка recovery?! Но да, и тот же uboot этим малость анноит, особенно учитывая что дефолтные скрипты бывают долбанутые донельзя. Я вот например на sunxi оборвал к хренам probing usb и (где есть) sata. При этом с командлайна при сильной нужде оно таки доступно, но скрипт больше это не трогает вообще каждый раз - и сцуко экономит секунд 15 времени загрузки. При том что демьян там секунд за 5-6 взлетает, это было полным ололо. И, блин, загрузка не отваливается, если воткнуть сдуру что-то не то в usb-порт девайса, что совсем уж якорь для автоматики, киосков и прочей лабуды где такое поведение форменный булшит.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 05-Авг-20, 00:59
	> Я видел много странной фигни, но вот именно такого ни разу не > встречал. За десятилетия. Нет, наверное, теоретически и так можно, но практически зато https://bugzilla.redhat.com/show_bug.cgi?id=1861977 встретили. > У GRUB он так вообще обычно подчитывает оверлей в "track0" (сразу за это у lilo (он почему-то никак не помещался в один сектор), у grub с самого рождения это не было острой необходимостью - можно было его и туда класть, с некоторым риском потерять, а можно и не - blocklist stage2 (лежащей прямо в файловой системе как обычный файл) помещался прямо в mbr. stage1.5 была в общем-то феерическим ненужно. Сейчас все то же самое тоже работает, но уже через задницу. >> Особенно бредово выглядит их реализация для efi, где не надо было никаких >> специальных умений и блоклистов - но вместо того чтобы просто прочитать > Вот это я особо не изучал, честно говоря. И не знаю какие efi дает апи, вполне достаточный для чтения файлов. Любых. Можно и для записи (если так хотелось любимый grubenv, то еще порождение бреда). И предоставляет раздел, куда их можно просто положить. Как файлы, никакой мистики, блоклистов прибитых гвоздем, писания в файловую систему в обход файловой системы, необходимости таскать за собой драйвер линуксной fs угадай какой на этой системе и не потеряй. > там были предпосылки. Мне уефанство в целом интересно только в контексте > "must die" :D Ну и напрасно. must die вот все что там выше - потому что и уродливо, и не нужно, все, кончилось время legacy boot. >> Зато вот, мы умеем нескучные скрипты в загрузчике! Ой, нас через них >> поимели, кто бы мог подумать да и было ли ему чем?! > Ну вообще скрипты в загрузчике бывают и достаточно прикольно - типа попробовали > раз, FAIL, двас, FAIL, трис, FAIL - о, а давайте-ка recovery?! а зачем для этого скрипты? Для этого нужна малоприятная, на самом деле (без uefi, с ней - простая и логичная) возможность записать что-то на диск (что не очень хорошо,учитывая что полноценного драйвера fs в грубе нет, и есть риск что-то все же попортить) или в efivar, потому что после fail будет reset без возможности иным способом сохранить состояние. И fallback был в grub 0.93 без всяких скриптов. Скрипт запускался штатно, из init, уже по факту загрузки - фиксируя с каким по счету ведром на самом деле загрузились. > Но да, и тот же uboot этим малость анноит, особенно учитывая что у него другого выхода нет - там вообще никакого интерфейса может не быть, даже serial, а загрузка быть с чего-то весьма нетривиального (да и до загрузки иногда десять приседаний). А у grub на uefi задача ровно одна - выбрать нужные файлы с подставленного диска. Но и это умудрились сделать в виде невменяемой блоатвари.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от kmeaw (?), 30-Июл-20, 15:45
	grub2: menuentry 'Arch Linux Fallback' {     set root='hd1,msdos1'     linux /boot/vmlinuz26 root=/dev/disk/by-uuid/131aa439-f2c0-41e3-b239-c778fcf572a5 rootfstype=xfs ro     initrd /boot/kernel26-fallback.img } Разве сложно? Строк почти столько же.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	163. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
	Сообщение от пох. (?), 30-Июл-20, 16:45
	> grub2: > Разве сложно? Строк почти столько же. если бы еще и работал - то цены бы ему не было. Только он у тебя не сработает - не сможет прочитать /boot, угадай почему. и в результате дистрибутивный код ляпает вот такую у6людину:                 recordfail (ок, ладно, хоть что-то полезное)                 load_video                 insmod gzio                 if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi                 insmod part_gpt                 insmod ext2                 set root='hd0,gpt2'                 if [ x$feature_platform_search_hint = xy ]; then                   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  ec470a0a-67de-11e8-8cb8-005056bd6c27                 else                   search --no-floppy --fs-uuid --set=root ec470a0a-67de-11e8-8cb8-005056bd6c27                 fi что это, блжад, нахера оно, кто придумал весь этот п-ц и почему его не сдали в дурку а код в утиль, вместо того чтобы этот весь "супермодульный" перескриптованный мусор растаскивать по дистрибутивам? Я отлично помню что без всего этого дерьма мы вполне обходились. Заметим, это _в_довесок_ к uefi grub. С которым вся эта ненужная механика становится не нужна соврешенно - но ее не только не выпиливают, но тщательно "улучшают" - потому что uefi grub не умеет ровно ничего (кроме как опять же запутаться в уже отдельных, своих собственных searchмусорных скриптах, наступить себе на шнурки и йапнуться вместо загрузки).
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 17:25
	Ровно так у меня и работает. Только сверху есть ещё кусок: if loadfont /EFI/boot/unicode.pf2 ; then         set gfxmode=1024x768,800x600,640x480,auto         set gfxpayload=keep         insmod efi_gop         insmod efi_uga         insmod video_bochs         insmod video_cirrus         insmod all_video         insmod gfxterm         insmod gfxterm_background         terminal_output gfxterm         background_image --mode stretch /splash.png fi set menu_color_normal=white/black set menu_color_highlight=black/light-gray set timeout=10 set default=0 Из которого тоже есть, что повыкидывать, если не нужен графический режим. Бинарник grub взят из http://mirror.centos.org/centos/7/os/x86_64/EFI/BOOT/bootx64... Аналогично работает, если собрать бинарник самому с помощью: grub-mkimage -O x86_64-efi -o /boot/EFI/BOOT/bootx64.efi -p '' part_gpt part_msdos fat ext2 normal chain boot configfile linux multiboot
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 30-Июл-20, 21:04
	> Ровно так у меня и работает. Только сверху есть ещё кусок: > if loadfont /EFI/boot/unicode.pf2 ; then ох, да, как это - да чтоб в загрузчик (сцуко - в ЗАГРУЗЧИК, Карл!) да не подгрузить нескучных шрифтецов! > Из которого тоже есть, что повыкидывать, если не нужен графический режим. я бы его весь выкинул, с большим удовольствием. > Аналогично работает, если собрать бинарник самому с помощью: знаешь, даже lilo как-то попроще был. И главное - в эпоху uefi это все нужно прямо как телеге гусеница от трактора.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 21:56
	> ох, да, как это - да чтоб в загрузчик (сцуко - в ЗАГРУЗЧИК, Карл!) да не подгрузить нескучных шрифтецов! Так не подгружай. Он всё равно будет работать. Разве это плохо, когда фича есть, и если ты хочешь, то можешь ей воспользоваться? Или не воспользоваться. > знаешь, даже lilo как-то попроще был. LILO использовал хак с запоминанием расположения ядра в физических блоках. Случайно подвинул или испортил ядро — всё, грузись с другого носителя и переустанавливай загрузчик. Самая ценная фича grub — возможность более-менее интерактивно ходить по файловой системе и загружать оттуда ядра и initrd, которых нет в конфиге. А во времена популярности LILO ядро прекрасно умело загружать самого себя с диска, да и initrd заодно ("insert root disk and press enter" или как-то так). > И главное - в эпоху uefi это все нужно прямо как телеге гусеница от трактора. В целом да, согласен. Пакеты с ядром вполне могут прописывать новые версии ядра в nvram. Тогда и откатиться на предыдущую версию можно будет прямо из boot menu. Разве что параметры ядра нельзя будет интерактивно изменить, но это не так часто требуется — обычно хватает возможности загрузить последнее удачное ядро, а дальше починить загрузку уже из хоть как-то работающей ОС. grub2-efi нужен для унификации процесса загрузки с legacy BIOS-системами и для реализации экзотических сценариев (какая-нибудь хитрая магия с lvm snapshots, raid, шифрованием и проверкой целостности, вытаскивания ядер из iso-образов). А ещё пользователи привыкли к нему. Странно, что на x86 не приживаются kexec-based загрузчики, типа petitboot. Так можно повторить всю функциональность grub2, только правильно и с гораздо более проверенной кодовой базой.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 31-Июл-20, 08:52
	> Так не подгружай. Он всё равно будет работать. Разве это плохо, когда фича есть расскажи это вот теперь счастливеньким де6иллиано-убунтоюзерам. У которых ночью системы превратились в тыкву из-за бесполезной блоатвари, но они об этом еще не в курсе - пока не попытаются перезагрузиться. Причем никакой secureboot им нахрен был не нужен и они им никогда не пользовались. Просто подфартило, нежданчик. Причем, судя по особенностям "фикса" - проблема именно в нагромождении невменяемых скриптов, генерящих чудо-конфиги, раз оно лечится переустановкой штатными же дерьмоскриптами. > Тогда и откатиться на предыдущую версию можно будет прямо из boot menu. Но в спецификации efi нет никакого boot menu. Это тебе подарок от твоего асуся. У какого-нибудь hp его просто не будет. И даже efi shell доступен только если не нашлось ни одного загрузчика. Ну или если его включить из уже загрузившейся системы. > Разве что параметры ядра нельзя будет интерактивно изменить, но это не так часто требуется — угу, система не грузится из-за проблем в бестолковом systemd и его миллиарде запчастей - переустанавливай, ведь даже в single-user теперь не загрузишься. ВСЕ эти проблемы решал elilo (и попутно он же - единственный, кто, иногда и кое-как, умел 32битный uefi) - но альтернативно-одаренным понадобилось его похерить. Ведь он не умеет нескучных шрифтиков.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Адекват (ok), 31-Июл-20, 07:08
	>> Ровно так у меня и работает. Только сверху есть ещё кусок: >> if loadfont /EFI/boot/unicode.pf2 ; then > ох, да, как это - да чтоб в загрузчик (сцуко - в > ЗАГРУЗЧИК, Карл!) да не подгрузить нескучных шрифтецов! Кстати, там что, ссылка на файл шрифта ? а если вместо шрифта будет какой-то свой файлик, специальный, может в этом плане тоже есть дырочка ? ну выход там за пределы ? никто не исследовал этот вопрос ?
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	260. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 01-Авг-20, 08:46
	> ЗАГРУЗЧИК, Карл!) да не подгрузить нескучных шрифтецов! Собственно, а почему бы загрузчику и не уметь нормально рисовать в гуевый режим, в том числе и текст? Благо про 80x25 все предпочли забыть как страшный сон. К тому же "unicode" намекает что он может матюкнуться и по русски, или чего вы там хотели. В принципе логично для пользователей отличных от US. > я бы его весь выкинул, с большим удовольствием. А что мешает? > И главное - в эпоху uefi это все нужно прямо как телеге > гусеница от трактора. Кроме уефи GRUB и на bios работает. А ты можешь юзать ядро как uefi stub :D :D
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	259. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (259), 01-Авг-20, 08:42
	> что это, блжад, нахера оно, кто придумал весь этот п-ц Это для интеграции с пакетниками, апдейтами ядер и всем таким. Теперь пакетник поставив ядро запускает генератор конфигов и тот .. быренько делает зашибись. Перегенерив конфиг и добавив туда все ядра которые есть. Ну а заодно он систему в run time видит и знает какие там uuid всего этого и проч. В демьяне допустим на эту тему есть /etc/default/grub описывающий как его такой генерить. А в этом твоем grub 0.97 - ахто будет новый кернель в меню добавлять? И как в меню поиметь все кернелы имеющиеся в системе, допустим? Ну, дабы в случае невзлета нового кернела, допустим, был фалбак на более старые из менюхи бута? Не, можно как тот арчевод при этом - "ухтыб%#?!", но есть мнение что это малость непрактично :)
	Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

	270. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 01-Авг-20, 13:15
	> Это для интеграции с пакетниками, апдейтами ядер и всем таким. вы забыли добавить - написанными вчерародившимися, ниасиляторами sed. > А в этом твоем grub 0.97 - ахто будет новый кернель в меню добавлять? > И как в меню поиметь все кернелы имеющиеся в системе, допустим? Вот вам суперпроблемы ниасиляторов-зуммерков. А так-то у меня все нормально было и с lilo, и с one-true grub - написанные прямыми руками скрипты не запускали маразматические "генераторы конфигов", просто добавляли пару строчек туда, куда им было разрешено лазить, и не трогали то, куда лазить было не положено. > В демьяне допустим на эту тему есть /etc/default/grub описывающий как его такой генерить. а нормальной документации еще и на ЭТОТ отдельный нескучный мусор - нет. Поэтому загадочные заклинания копипастятся с серверфолта. Это ведь куда проще чем нормальный человекочитаемый конфиг, исправляемый при необходимости человеком.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Адекват (ok), 31-Июл-20, 06:39
	Нет, то что я показал - это реальный пример тех веремен, когда grub 0.97 был, а вот реальный пример из линукс минта: # # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### if [ -s $prefix/grubenv ]; then   set have_grubenv=true   load_env fi if [ "${next_entry}" ] ; then    set default="${next_entry}"    set next_entry=    save_env next_entry    set boot_once=true else    set default="0" fi if [ x"${feature_menuentry_id}" = xy ]; then   menuentry_id_option="--id" else   menuentry_id_option="" fi export menuentry_id_option if [ "${prev_saved_entry}" ]; then   set saved_entry="${prev_saved_entry}"   save_env saved_entry   set prev_saved_entry=   save_env prev_saved_entry   set boot_once=true fi function savedefault {   if [ -z "${boot_once}" ]; then     saved_entry="${chosen}"     save_env saved_entry   fi } function recordfail {   set recordfail=1   if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi } function load_video {   if [ x$feature_all_video_module = xy ]; then     insmod all_video   else     insmod efi_gop     insmod efi_uga     insmod ieee1275_fb     insmod vbe     insmod vga     insmod video_bochs     insmod video_cirrus   fi } insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53 else   search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53 fi if loadfont /boot/grub/fonts/UbuntuMono16.pf2 ; then   set gfxmode=auto   load_video   insmod gfxterm   set locale_dir=$prefix/locale   set lang=ru_RU   insmod gettext fi terminal_output gfxterm insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53 else   search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53 fi insmod gfxmenu insmod png set theme=($root)/boot/grub/themes/linuxmint/theme.txt export theme if [ "${recordfail}" = 1 ] ; then   set timeout=30 else   if [ x$feature_timeout_style = xy ] ; then     set timeout_style=hidden     set timeout=0   # Fallback hidden-timeout code in case the timeout_style feature is   # unavailable.   elif sleep --interruptible 0 ; then     set timeout=0   fi fi ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/05_debian_theme ### set menu_color_normal=white/black set menu_color_highlight=black/light-gray ### END /etc/grub.d/05_debian_theme ### ### BEGIN /etc/grub.d/10_linux ### function gfxmode {     set gfxpayload="${1}"     if [ "${1}" = "keep" ]; then         set vt_handoff=vt.handoff=1     else         set vt_handoff=     fi } if [ "${recordfail}" != 1 ]; then   if [ -e ${prefix}/gfxblacklist.txt ]; then     if hwmatch ${prefix}/gfxblacklist.txt 3; then       if [ ${match} = 0 ]; then         set linux_gfx_mode=keep       else         set linux_gfx_mode=text       fi     else       set linux_gfx_mode=text     fi   else     set linux_gfx_mode=keep   fi else   set linux_gfx_mode=text fi export linux_gfx_mode menuentry 'Linux Mint 19.3 Xfce' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {     recordfail     load_video     gfxmode $linux_gfx_mode     insmod gzio     if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi     insmod part_msdos     insmod ext2     set root='hd0,msdos1'     if [ x$feature_platform_search_hint = xy ]; then       search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53     else       search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53     fi         linux    /boot/vmlinuz-5.3.0-40-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro  quiet splash $vt_handoff     initrd    /boot/initrd.img-5.3.0-40-generic } submenu 'Дополнительные параметры для Linux Mint 19.3 Xfce' $menuentry_id_option 'gnulinux-advanced-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.3.0-40-generic' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.3.0-40-generic-advanced-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         gfxmode $linux_gfx_mode         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.3.0-40-generic …'             linux    /boot/vmlinuz-5.3.0-40-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro  quiet splash $vt_handoff         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.3.0-40-generic     }     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.3.0-40-generic (recovery mode)' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.3.0-40-generic-recovery-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.3.0-40-generic …'             linux    /boot/vmlinuz-5.3.0-40-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro recovery nomodeset         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.3.0-40-generic     }     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.3.0-28-generic' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.3.0-28-generic-advanced-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         gfxmode $linux_gfx_mode         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.3.0-28-generic …'             linux    /boot/vmlinuz-5.3.0-28-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro  quiet splash $vt_handoff         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.3.0-28-generic     }     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.3.0-28-generic (recovery mode)' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.3.0-28-generic-recovery-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.3.0-28-generic …'             linux    /boot/vmlinuz-5.3.0-28-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro recovery nomodeset         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.3.0-28-generic     }     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.0.0-37-generic' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-37-generic-advanced-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         gfxmode $linux_gfx_mode         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.0.0-37-generic …'             linux    /boot/vmlinuz-5.0.0-37-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro  quiet splash $vt_handoff         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.0.0-37-generic     }     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.0.0-37-generic (recovery mode)' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-37-generic-recovery-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.0.0-37-generic …'             linux    /boot/vmlinuz-5.0.0-37-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro recovery nomodeset         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.0.0-37-generic     }     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.0.0-32-generic' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-32-generic-advanced-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         gfxmode $linux_gfx_mode         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.0.0-32-generic …'             linux    /boot/vmlinuz-5.0.0-32-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro  quiet splash $vt_handoff         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.0.0-32-generic     }     menuentry 'Linux Mint 19.3 Xfce, с Linux 5.0.0-32-generic (recovery mode)' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-32-generic-recovery-2976ef73-6fb5-4c42-b626-48b9b0a49c53' {         recordfail         load_video         insmod gzio         if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi         insmod part_msdos         insmod ext2         set root='hd0,msdos1'         if [ x$feature_platform_search_hint = xy ]; then           search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53         else           search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53         fi         echo    'Загружается Linux 5.0.0-32-generic …'             linux    /boot/vmlinuz-5.0.0-32-generic root=UUID=2976ef73-6fb5-4c42-b626-48b9b0a49c53 ro recovery nomodeset         echo    'Загружается начальный виртуальный диск …'         initrd    /boot/initrd.img-5.0.0-32-generic     } } ### END /etc/grub.d/10_linux ### ### BEGIN /etc/grub.d/20_linux_xen ### ### END /etc/grub.d/20_linux_xen ### ### BEGIN /etc/grub.d/20_memtest86+ ### menuentry 'Memory test (memtest86+)' {     insmod part_msdos     insmod ext2     set root='hd0,msdos1'     if [ x$feature_platform_search_hint = xy ]; then       search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53     else       search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53     fi     knetbsd    /boot/memtest86+.elf } menuentry 'Memory test (memtest86+, serial console 115200)' {     insmod part_msdos     insmod ext2     set root='hd0,msdos1'     if [ x$feature_platform_search_hint = xy ]; then       search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  2976ef73-6fb5-4c42-b626-48b9b0a49c53     else       search --no-floppy --fs-uuid --set=root 2976ef73-6fb5-4c42-b626-48b9b0a49c53     fi     linux16    /boot/memtest86+.bin console=ttyS0,115200n8 } ### END /etc/grub.d/20_memtest86+ ### ### BEGIN /etc/grub.d/30_os-prober ### ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/30_uefi-firmware ### ### END /etc/grub.d/30_uefi-firmware ### ### BEGIN /etc/grub.d/40_custom ### # This file provides an easy way to add custom menu entries.  Simply type the # menu entries you want to add after this comment.  Be careful not to change # the 'exec tail' line above. ### END /etc/grub.d/40_custom ### ### BEGIN /etc/grub.d/41_custom ### if [ -f  ${config_directory}/custom.cfg ]; then   source ${config_directory}/custom.cfg elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then   source $prefix/custom.cfg; fi ### END /etc/grub.d/41_custom ### Ну разве все не интуитивно понятно ? и если срочно нужно будет установить систему по этим примерам и новичек же справится с первого раза, да ? ЗЫ{ Особенно это доставляет { # # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # }};
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	209. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+3 +/–
	Сообщение от пох. (?), 31-Июл-20, 09:02
	> Ну разве все не интуитивно понятно ? ну в первых же строчках все интуитивно-понятно - "мы написали прекрасный конфиг - для РОБОТОВ. А людям тут делать нечего. Вон там лежит косорукий набор из недокументированных толком пяти параметров - а больше ничего редактировать тебе не положено, робот сломается и систему тебе убьет - ведь его даже не научили проверять этот факт и аккуратно отдавать инициативу (что умели в 2000м). Потому что мы и сами ниасиляторы, и линукс изуродовали для таких же". И да, как переключить эту адскую е...нину на serial port, если видюха вообще сдохла? А-а-а, "это другое", да. (freebsd можно (было) переключить вслепую, поскольку это _две_буквы_ - но там для людей делали, а не для смухихлебов и туповатых роботов) Зато смотри, смотри - оно умеет ПА РЮЙСКЕ "Загружается начальный виртуальный диск" (блжад, да на каком это собачьем языке? ) - это ли не прогресс! Правда, на самом деле у тебя устаревшая и немодная система, срочно обновись - теперь не принято "загружается", теперь принято не отвлекать пользователя от ковыряния пальцем в носу, и на экране не показывается вообще ничего до старта системдешной помойки.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 01-Авг-20, 08:48
	> ну в первых же строчках все интуитивно-понятно - "мы написали прекрасный конфиг > - для РОБОТОВ. А людям тут делать нечего. Абсолютно!!! Если что-то надо - айда менять ШАБЛОН. А этот список динамический, он меняется каждый раз когда пакетник кернель ставит/сносит, например. И это по своему логично. Не надо самому прописывать новый кернель и можно при факапе выбрать более старый кернель в меню бутлоадера, если новый вдруг почему-то не прокатил.
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от пох. (?), 01-Авг-20, 13:24
	> Абсолютно!!! Если что-то надо - айда менять ШАБЛОН. А этот список динамический, да, щас, щас, еще один нескучный язычок вызубрю только. > он меняется каждый раз когда пакетник кернель ставит/сносит, например. к0к0к0й ужос! Ведь sed-то вы не умеете, да? > И это по своему логично. Не надо самому прописывать новый кернель и да, очень логично - кривые скрипты писать умеете, юникс не умеете. > можно при факапе выбрать более старый кернель в меню бутлоадера, если а если его в меню нет - быстро-быстро поизучать нескучные язычки. А то набрать пару строк (с tab completion) и загрузить что угодно, вплоть до /usr/src/linux/arch/гдеонотамвзаднице/bzImage - для зуммерка слишком сложно. А на практике при реальном факапе - у вас rescue mode> - и никакой возможности ВООБЩЕ восстановить загрузку без внешнего носителя. Вот это достижение, вот это XXI век, а не эти ваши нимодные поделки. А лучший проект (который подобным образом сломать вообще невозможно) - вообще брошен автором, которому пришлось идти горбатиться на дядю, делая что велено, а не как надо - потому что ниасиляторы ниасиляют. В стороне же от мэйнстрима вообще творится адская дичь - типа ручного переписывания содержимого /boot (которое нахер никому не нужно, ибо данная платформа не оборудована умением читать extfs) в реальный загрузочный раздел - он fat, и ничто не мешало бы просто смонтировать его в /boot - кроме, конечно же, наговняканных зуммерками скриптов, неспособных работать на fat. Вот так сюрпризец.
	Ответить | Правка | Наверх | Cообщить модератору

26. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+3 +/–
Сообщение от Аноним (26), 30-Июл-20, 04:35
Какой смысл вообще использовать Secure Boot с GRUB? Изначально понятно, что так будет. В UEFI есть свой менеджер загрузки, туда можно добавить любое приложение для UEFI типа ядра Linux.
Ответить | Правка | Наверх | Cообщить модератору

	27. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (27), 30-Июл-20, 05:00
	Доступ к bios может быть ограничен на уровне uefi
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+5 +/–
	Сообщение от Аноним (38), 30-Июл-20, 05:59
	UEFI давно уже выяснено ломается и из системы получается доступ к изменению настроек. Поэтому люди развивают coreboot. А данная новость славна тем, что позволяет ставить Gentoo/Void с самосборным ядром даже на радикально огороженные устройства. И вот если убрать лаг загрузки биоса и использовать runit система внезапно грузится за несколько секунд даже с жесткого диска. Все эти ключи и подписи для болванов, которые верят, что им собрали ядро или всю систему без дыр. Мелкомягкие этим особр грешат. Впрочем занды есть и в коммерческих линуксах о чем давно рассказал Столлман.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
	Сообщение от Аноним (-), 30-Июл-20, 05:22
	> туда можно добавить любое приложение для UEFI типа ядра Linux. Ога, только ни рамдиск не положишь, ни командлайн не поменяешь небось. Поэтому фича больше для галочки - на самый крайний случай, конечно, линух и так позволяет, но это явно не есть удобное и функциональное использование ОС.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	160. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 30-Июл-20, 16:32
	>> туда можно добавить любое приложение для UEFI типа ядра Linux. > Ога, только ни рамдиск не положишь, ни командлайн не поменяешь небось. Поэтому ну вот этим должен был заниматься как раз grub или какая-нибудь его замена. В идеале - встроенная в само ведро, потому что неясно, зачем нужна еще отдельная прокладка. Но нет. Это было бы слишком уж просто. Поэтому он делает кучу невменяемой ненужной хни ВМЕСТО того. Даже убогий systemd-boot (вопреки названию вообще ничего не умеющий загружать) выглядит меньшим г-ном.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 17:31
	Если прописывать ядро в nvram, то без проблем и командлайн, и initrd= туда же можно указать. В последнем случае ядро используя сервисы EFI загрузит с той же файловой системы initrd с диска. Раньше в NixOS была возможность использовать efibootmgr вместо grub, и тогда всё это делалось автоматически при обновлении системы. Не знаю, как сейчас — перешёл на systemd-boot. Если же просто положить bootx64.efi в /EFI/BOOT не трогая nvram, то да, не получится — придётся command line и initrd задавать при компиляции и жёстко зашивать внутрь образа ядра. Но дистростроители тоже могут автоматизировать этот процесс (сделав что-то похожее на dkms, специализирующее полуфабрикат ядра для конкретной конфигурации в момент установки пакета). А с помощью sbsign можно этот bootx64.efi сразу же подписать.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	40. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (35), 30-Июл-20, 06:03
	Согласен. GRUB ненужен как и другие загрузчики. У меня ядро напрямую грузится из EFI
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

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

	51. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от ryoken (ok), 30-Июл-20, 08:20
	У вас, простите, 1 ядро необновляемое? В том же Дебе сразу после установки системы и установки всех обнов будет минимум 2-3. Это если не апгрейдиться до testing/sid. Вам доставляет удовольствие всю эту толпу прописывать?
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	90. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (90), 30-Июл-20, 10:18
	Во всяких рачах ядро называется просто как-нибудь вроде vmlinuz-linux и раскатывается поверх старого
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (102), 30-Июл-20, 11:54
	Чё, правда? Прямо поверх, не симлинком? Отчаянные ребята.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (-), 30-Июл-20, 14:58
	> Во всяких рачах ядро называется просто как-нибудь вроде vmlinuz-linux и раскатывается поверх старого А если вдруг система с новым ядром не запустилась - мы произносим удивленное "ухтыб$%?!" :D :D :D ...в то время как юзерь grub и какого там дебиана или убунт просто выбирает прошлый кернель и уже более предметно разбирается WTF. Или там кернелу командлайн меняет, типа nomodeset. А упомянутый подход катит для какого-нибудь киоска, но вот для компа относительно продвинутого юзера уже как-то не то.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	161. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 30-Июл-20, 16:34
	> А если вдруг система с новым ядром не запустилась - мы произносим > удивленное "ухтыб$%?!" :D :D :D это рач, они даже не удивляются. > ...в то время как юзерь grub и какого там дебиана или убунт не может загрузиться даже со старым ведром - ведь у него (в связи с вот этой новооткрытой увизгвимостью, например) grub обновился, и теперь не может прочитать свою собственную жопу и вываливается в бесполезный rescue mode.
	Ответить | Правка | Наверх | Cообщить модератору

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

	225. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 31-Июл-20, 12:08
	> бть! > Сглазил. Чего? Кернел? Или сабжа? :)
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от пох. (?), 31-Июл-20, 14:18
	>> бть! >> Сглазил. > Чего? Кернел? Или сабжа? :) сабжа - реально все по моему сценарию и слуцилась этой же ночью - > не может загрузиться даже со старым ведром - ведь у него (в связи с вот этой новооткрытой > увизгвимостью, например) grub обновился, и теперь не может прочитать свою собственную жопу - и у убунтоидов, и дебианщикам прилетело, и даже энтер-прайс не забыли. Ну только недоработочка - не в resсue mode, в чорном экране виснет. А жаль, в моем-то варианте еще можно было заставить протрахаться пару часов в бесплодных попытках. Да блин, ну я ж троллил, ну дорогое мироздание, не надо ж так!
	Ответить | Правка | Наверх | Cообщить модератору

	285. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Авг-20, 08:22
	> Да блин, ну я ж троллил, ну дорогое мироздание, не надо ж так! "режьте ОСТОРОЖНЕЙ" (ц) PS: http://bugzilla.redhat.com/1861977 -- оно? PPS: это у Арсака же цитировалось в безумной книжке по играм/головоломкам? :)
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 04-Авг-20, 14:50
	> PS: http://bugzilla.redhat.com/1861977 -- оно? угу, и нифига так и не понятно - ни что это было, ни где запатчено в очередной раз. А я уже на незагружабельность с uefi напарывался, поэтому придется блокировать везде обновления всего связанного с грубом (и "угадай как это называется", в каждом дистре отдельно)
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 31-Июл-20, 12:07
	> это рач, они даже не удивляются. Ну так тем более - мне казалось, лезть каждый раз за загрузочной флехой должно бы и подзадолбать? Не? :) > не может загрузиться даже со старым ведром - ведь у него (в > связи с вот этой новооткрытой увизгвимостью, например) grub обновился, и теперь > не может прочитать свою собственную жопу и вываливается в бесполезный rescue mode. Ну вот если grub обломался - тогда уже упс, придется за флехой все же слазить и таки переставить старый.
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	236. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 31-Июл-20, 14:21
	>> это рач, они даже не удивляются. > Ну так тем более - мне казалось, лезть каждый раз за загрузочной > флехой должно бы и подзадолбать? Не? :) да куда лезть, она ж у них напостой в разъем воткнута, только диск выбрать (ой, сцыстемде несовместимой с ведром версии... ну я прям и не знаю) > Ну вот если grub обломался - тогда уже упс, придется за флехой > все же слазить и таки переставить старый. воот. а теперь угадай, кому это проще - любителю рача, или б-жественной бубунточки, привыкшему что за него все делали.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (102), 30-Июл-20, 14:56
	> Какой смысл вообще использовать Secure Boot? Вот так достаточно.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

28. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
Сообщение от Аноним (-), 30-Июл-20, 05:20
> но и других операционных систем, включая Windows. Дык там один из довереных ключей ms утек, так что не похрен ли? Кто этого хотел - и так сто лет это могли. Блочить ключ не стали - загрузка, видите ли, сломается :)
Ответить | Правка | Наверх | Cообщить модератору

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

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

	226. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (-), 31-Июл-20, 12:12
	>> Дык там один из довереных ключей ms утек, так что не похрен ли? > А можно ссылочку на ключ или сам ключ? Я такое не коллекционирую, но на форониксе новость была про малварь подписанную таким. И еще по ссылям в сабже можно найти рассказ про буткит касперыча с какого-то его rescue диска, чтоли, которым блэкхэты научились что попало грузить, аннулировав всю схему к хренам опять же. MS попробовал это зарубить - и быро отпедалил взад под вой окирпиченых юзерей. Поэтому оно так вроде и осталось работающим по сей день. Выбирая между просером своей репутации и вашей безопасностью MS выбрал понятно чего.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Авг-20, 08:18
	Ну там и ещё вариант был...
	Ответить | Правка | Наверх | Cообщить модератору

42. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–6 +/–
Сообщение от Fracta1L (ok), 30-Июл-20, 06:41
> Уязвимость вызвана переполнением буфера Хахаха, как обычно. Жду от мамкиных экспертов визгов про кривые руки программистов и вот это всё.
Ответить | Правка | Наверх | Cообщить модератору

	52. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (49), 30-Июл-20, 08:27
	>> Уязвимость вызвана переполнением буфера > Хахаха, как обычно. 1. Тебе надо прочесть учебник о защите памяти в OS: Можно на C написать OS которая даст гарантию невозможности эксплуатации уязвимости переполнения буфера как в самом ядре OS, так и во всех программах, написанных на C и запускаемых на этом ядре OS! 2. GRUB, пренебрегает безопасностью в угоду минималмстичности и простоты. Но одного Integrity, которое в GRUB есть, хватит чтобы сделать практическое использование уязвимости переполнения буфера нереальным - Integrity в grub верифицируется все, как исполняемые программы, так и данные.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–2 +/–
	Сообщение от Fracta1L (ok), 30-Июл-20, 08:45
	> Можно на C написать... Вот и начались мантры))
	Ответить | Правка | Наверх | Cообщить модератору

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

	88. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Fracta1L (ok), 30-Июл-20, 10:06
	Ну так покажи хоть одну используемую программу на Сишке без дыр
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 30-Июл-20, 15:04
	> Ну так покажи хоть одну используемую программу на Сишке без дыр Ну дык djbdns например. А так что совсем без дыр и нафиченые проги - блин, поимейте совесть, дыры даже в пихоногуане бывают, хоть там яп и сделан для совсем уж имбецилов из младшей коррекционной группы детсада. Но отдельные тела все-равно умудряются прострелить себе пятки. Иногда достаточно остроумно, типа eval() на входных данных. Может эти веьмакаки в глубине души мечтали бутлоадер накодить, но стеснялись себе признаться в этом, мало ли :D
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Fracta1L (ok), 30-Июл-20, 16:44
	> Ну дык djbdns например Ахахахаха https://www.webcitation.org/68AXHUSJp?url=http://securityand.../
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (102), 30-Июл-20, 17:18
	Это не сишная дыра, а логическая. Такое на любом языке могло бы быть. Гугли дальше, мастер гугл-фу.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Fracta1L (ok), 31-Июл-20, 07:43
	Найс манявры)
	Ответить | Правка | Наверх | Cообщить модератору

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

	283. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Авг-20, 08:17
	Вы пытаетесь спорить с упоротым глупцом, который мнит себя троллем.  Смысл?  Он так ничего и не поймёт, а Вы зря потратите время.
	Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

	212. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (219), 31-Июл-20, 09:50
	Двоечник, марш за учебниками! И чтобы до 1 сентября вот здесь: https://www.opennet.ru/tips/sml/#5 была твоя статья на тему "Как на C написать OS которая даст гарантию невозможности эксплуатации уязвимости переполнения буфера как в самом ядре OS, так и во всех программах, написанных на C и запускаемых на этом ядре OS"! Приведешь в статье примеры современных ядер OS которые дают гарантию невозможности эксплуатации уязвимости переполнения буфера.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

Часть нити удалена модератором

	220. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
	Сообщение от Аноним (219), 31-Июл-20, 11:20
	Linux+PAX тебе ничего не говорит?
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	73. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (75), 30-Июл-20, 09:22
	>> Уязвимость вызвана переполнением буфера Она для начала вызвана игнором ошибки парсера, а это уже следствие обшего undefined behavior. Если прога игнорит фатальную ошибку - может быть все что угодно, это UB на вообще совсем любом ЯП. И кстати если ты не заметил - мегадыра в практических конфигах еще и неэксплуатируемая к тому же. Но исследователю про это указывать не с руки - а как же тогда быть с вот таким вот пиаром? Неспортивно! :)))
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	111. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (102), 30-Июл-20, 11:57
	> Жду от мамкиных экспертов визгов Товарищ папкин эксперт, покажи-ка свой код. Интересно, писал ли ты вообще на чём-то кроме КУМира.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

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

74. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+4 +/–
Сообщение от Онаним (?), 30-Июл-20, 09:23
Ужас-ужас! А по сути - ничего собственно не произошло. Как был весь этот секуребут бессмысленным баззом, так и остаётся. Надеятся, что он реально обеспечит какие-то гарантии - ну так себе.
Ответить | Правка | Наверх | Cообщить модератору

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

78. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
Сообщение от svsd_val (ok), 30-Июл-20, 09:35
Хм, это за частую даже удобно, можно спокойно заливать любые системы на эту бесполезную хрень под названием уёфи... от неё толку мало только больше геморроя ...
Ответить | Правка | Наверх | Cообщить модератору

79. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
Сообщение от Hellraiser (??), 30-Июл-20, 09:35
> даёт возможность обойти механизм UEFI Secure Boot так это ж не уязвимость, а True-функционал; дурачок Мэтью Гаррет в ногах у микрософта валялся, чтобы "серьёзные дяденьки" подписали его прокладку для загрузки в uefi; а оказывается grub2 из коробки может обходиться без этого извращения :D
Ответить | Правка | Наверх | Cообщить модератору

	82. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от пох. (?), 30-Июл-20, 09:43
	Мальчик, ты дурачок. В том и дело что НЕ может. И вот те серьезные дядечки - ХРЕН теперь другим дурачкам что подпишут, сколько ни умоляй, поскольку по факту поделка скомпроментировала их ключ. Ищите по помойкам уникальные платы, позволяющие вручную запихивать в них ключи, или вон - венду грузите, она загрузится. P.S. а яббл, получается, что-то знал, когда с именно этим ключом не захотел иметь дело, при том что ключи от десяточки (ms тоже о чем-то догадывалась и использовала для нее отдельную пару) принимал.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Hellraiser (??), 30-Июл-20, 09:58
	девочка, не надо обзываться, это невежливо; лучше расскажи нам сказку, что только на уникальных платах с помоек можно загрузиться без ключа от мелгомягких
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Авг-20, 08:15
	Из коробки -- только с ним, увы.  По факту.  Отключение -- действие, которое далеко не каждый пользователь осилит (начиная с собственно "зайти в менюшки", что также постарались сделать более сложным и менее очевидным, плюс порой требующим реакции, а порой и вовсе загрузки винды -- возможно, с принятием EULA -- и уже оттуда перезагрузкой в фирмварь, чтобы тут же отключить FastBoot). Но вроде бы как по спецификации на x86 секирбут должен быть отключаемым, а ключи -- заменяемыми пользователем. PS: когда копал это всё дело -- вот что написал: http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO PPS: как же хорошо на эльбрусах без вот этого всего...
	Ответить | Правка | Наверх | Cообщить модератору

	287. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 03-Авг-20, 13:59
	> начиная с собственно "зайти в менюшки" Менюшек может просто не быть - вообще. > Но вроде бы как по спецификации на x86 секирбут должен быть отключаемым, а ключи -- заменяемыми > пользователем. ну да - зайдите в менюшку _своей_операционной_системы_ - и, если вам позволено политикой - отключите. Угадай о какой операционной системе тут речь, и почему. А вот заменять ключи та система не умеет - ей-то без надобности, она каким надо ключом подписана.
	Ответить | Правка | Наверх | Cообщить модератору

86. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
Сообщение от Укуренный (?), 30-Июл-20, 10:01
Именно благодаря этой "уязвимости" у меня получилось установить линукс на hp pavilion вместо виндуса10, теперь после обновления линукс перестанет запускаться и я снова перейду на виндус10 или выкину ноут на помойку, спасибо.
Ответить | Правка | Наверх | Cообщить модератору

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

97. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+3 +/–
Сообщение от mikevmk (??), 30-Июл-20, 10:35
А может мне кто-нибудь доходчиво объяснить, зачем в реальном мире нужен SecureBoot? Каков РЕАЛЬНЫЙ кейс использования? Где ты предполагаешь физический доступ проходимцев, но чтоб загрузить не смогли свое?
Ответить | Правка | Наверх | Cообщить модератору

	99. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от tolstushka.ru (ok), 30-Июл-20, 10:51
	Загрузочные вирусы же! Другое дело - кто их видел вобще за последние лет 5?
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от mikevmk (??), 30-Июл-20, 11:22
	Ну это ж никакой критики не выдерживает Т.е. получается, что вендор лок как мало-мальски рациональное предположение только и остается
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от InuYasha (??), 30-Июл-20, 11:49
	На самом деле этот SecureBoot - ТОЛЬКО НАЗВАНИЕ И НИЧЕГО БОЛЬЕЕ! Он НЕ SECURE, он ни от чего не спасает, никакие данные не защищает. ВОТ ИНФА О РЕАЛЬНЫХ ПРИНЦИПАХ UEFI:SecureBoot: https://github.com/pbatard/rufus/wiki/FAQ#Why_do_I_need_to_d...
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	107. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+5 +/–
	Сообщение от RADV (?), 30-Июл-20, 11:52
	СПАСИБО, БОЛЬШИЕ БУКОВЫ ЛУЧШЕ ВИДНО
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	141. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (102), 30-Июл-20, 14:59
	> облачные ОС, облачные программы, всех в сад/инет Ты правда думаешь, что там девляпсы что-то проверяют?
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от vitalif (ok), 30-Июл-20, 14:59
	это не идеал, это антиутопия
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	142. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (102), 30-Июл-20, 15:02
	Иедальный, от слова "идея" — воображаемый, на практике недостижимый. Идеальный газ, всё такое. К моральной оценке отношения не имеет.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–4 +/–
	Сообщение от Нанобот (ok), 30-Июл-20, 12:52
	>зачем в реальном мире нужен SecureBoot ну, допустим есть сервер банка и нужно защитить его от руткитов режима ядра
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	124. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+4 +/–
	Сообщение от mikevmk (??), 30-Июл-20, 13:24
	Ты кейс целиком расскажи. А то это получается как турникеты в школах против террористов. Террорист придет таой, увидет турникет и уйдет не солоно хлебавши Вот ты, допустим, злоумышленник. Злоумышляешь против банка и умеет в руткиты. Твои действия?
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от Аноним (21), 30-Июл-20, 14:17
	> Твои действия? Ну как-то так: 1. прихожу в банк 2. захожу в серверную 3. вставляю флэшку с руткитом в усб 4. перезагружаю сервер с флэшки 5. используя уязвимость уефи, устанавливаю руткит.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+4 +/–
	Сообщение от Аноним (-), 30-Июл-20, 15:07
	> Ну как-то так: > 1. прихожу в банк > 2. захожу в серверную > 3. вставляю флэшку с руткитом в усб > 4. перезагружаю сервер с флэшки > 5. используя уязвимость уефи, устанавливаю руткит. А охрана банка, соответственно, спокойно на все это втыкает? А не проще было тогда просто забрать, простите, деньги из банкомата? Особо наглые в принципе вместе с банкоматом иногда забирают даже.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 30-Июл-20, 17:11
	> А охрана банка, соответственно, спокойно на все это втыкает? А не проще охрана втыкает нервно - потому что из стены в серверную хлещет дерьмо, и он вообще-то сантехник, срочно вызванный заткнуть свищ. Поэтому долго копаться в серверах ему не удастся, но один раз на пару минут отвлечь внимание - можно. secureboot как раз от таких сценариев.
	Ответить | Правка | Наверх | Cообщить модератору

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

	228. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (-), 31-Июл-20, 12:20
	> Поэтому долго копаться в серверах ему не удастся, но один раз на > пару минут отвлечь внимание - можно. secureboot как раз от таких сценариев. Понятно! Помогает только при съемке попсовых фильмов про хакеров, и то приходится писать UEFI аддон показывающий для дебилов большими красными буквами [ACCESS DENIED] на весь экран. И то - через пять минут по сценарию мегахакер делает какую-то мутную фигню и надпись меняется на [ACCESS GRANTED!!1111] и банкоматы начинают дико изрыгать купюры во всех направлениях. А довольный хакер с дружбанами быстро набивают сумки и карманы, стало быть, пока о...шая от такой наглости охрана не снялась с ручника.
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	229. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 31-Июл-20, 12:38
	> Понятно! Помогает только при съемке попсовых фильмов про хакеров да в чем проблема-то? Было бы мне надо - вполне мог бы что-то в этом роде исполнить. Потому что в подвальчики банков - захаживалось, да. И хотя там не стояк протек, а другое говнище надо было разгрести, если бы в процессе сребутился какой серверок - списали бы на неаккуратность с кабелями, вероятнее всего. Над душой у меня постоянно стоять грамотным людям скучно, дерьмо нюхать, а неграмотные и не поймут нихрена.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Нанобот (ok), 30-Июл-20, 17:32
	> Вот ты, допустим, злоумышленник. Злоумышляешь против банка и умеет в руткиты. Твои действия? допустим, я уже работаю в этом банке и имею полный доступ. но в один прекрасным момент решаю уволиться и оставить себе "на чёрный день" доступ ввиде руткита на сервере. человек, нанятый на моё место (вариант2: без увольнений, просто какой-то независимый аудит захотят провести) должен удостовериться, что система на сервере не имеет скрытых функций. с secureboot это просто - код ядра подписан цифровой подписью и функционал соответствует заявленому, без secureboot - сложно сказать или другой вариант, из другой области: разработчик игровой приставки хочет быть уверен, что на его приставке будет запускаться только то, что он разрешил. подписал ядро, запретил запуск неподписаного кода и греби бабло лопатой :)
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	176. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от Аноним (173), 30-Июл-20, 19:05
	Если есть полный доступ можно и программатор принести и переписать всю уефину нахрен вместе со всеми ее секурбутами. Только не надо про раздевают и проверяют не засунул ли ты в программатор в анус, в банках таким не занимаются.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от пох. (?), 30-Июл-20, 21:14
	> удостовериться, что система на сервере не имеет скрытых функций. с secureboot > это просто - код ядра подписан цифровой подписью и функционал соответствует это просто невозможно. Код ядра безусловно подписан какой-то подписью, а вот вся остальная система - нет. И раз тебя там держали в принципе - значит наверняка в ней полно твоих собственных поделок, любая из которых может внезапно делать не только то, для чего якобы предназначена, причем через штатные конфиги писятого уровня вложенности, генерящиеся хрен знает какими скриптами. И проверять все это стороннему аудитору - абсолютно без шансов. Один коллега вон после себя цельный майнинговый кластер оставил. Причем все задокументировано, все системы занесены в табличку, ну есть в той табличке мелкие недочеты - не вполне очевидно, какую функцию выполняют некоторые детали комплекса, но так обычно в сложных системах всегда бывает. И ни один аудитор так глубоко не докопается. > или другой вариант, из другой области: разработчик игровой приставки хочет быть уверен, > что на его приставке будет запускаться только то, что он разрешил. а это да. Но местные фанатики не одобряют, это ж нельзя сломать приставку и поставить туда линyпс, чтоб ничего не работало затозагружаетцайакрутой!
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	234. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Нанобот (ok), 31-Июл-20, 14:19
	> Код ядра безусловно подписан какой-то подписью, а вот вся остальная система - нет. И раз тебя там держали в принципе - значит наверняка > в ней полно твоих собственных поделок, любая из которых может внезапно > делать не только то, для чего якобы предназначена, причем через штатные > конфиги писятого уровня вложенности, генерящиеся хрен знает какими скриптами. да, 100% защиты системы оно не даёт, оно защищает только одну конкретную область - ядро ос. тем не менее, наличие защиты всё равно лучше отсутствия защиты (за исключением тех случаев, когда защита создаёт больше проблем, чем решает)
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от пох. (?), 31-Июл-20, 14:27
	> да, 100% защиты системы оно не даёт, оно защищает только одну конкретную область - ядро ос. ну да, о том и речь - от другой совсем модели угроз, нежели полноправный админ с неограниченным временем, который там был описан. Вот от мимопробегающего с флэшкой малоквалифицированного биоробота - да. Ну так и увизгвимость вполне тому биороботу по силам (программу,разумеется, не он составит)
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (-), 31-Июл-20, 06:29
	> secureboot это просто - код ядра подписан цифровой подписью чьей именно цифровой подписью?
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

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

	155. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от kmeaw (?), 30-Июл-20, 15:53
	SecureBoot — это гибкая альтернатива перемычке read-only на загрузочном носителе. Реальный кейс использования — массовое обновление ОС рабочих станций. От физического доступа не защищает почти ничего. Но испортить жизнь злоумышленнику, у которого есть только кратковременный физический доступ всё-таки можно. Если загрузочный носитель не read-only, то туда можно записать буткит (например через 0day-уязвимость в ядре ОС, которая будет исправлена завтра). Если read-only, то неудобно обновлять. Если Secure Boot, то обе проблемы решены.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

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

131. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
Сообщение от RedEyedMan (ok), 30-Июл-20, 14:35
Атакующий столкнет меня с моего места и взломает граб чтобы добраться до UEFI. Уязвимость, но мне пофиг. Другие сами знают что им делать.
Ответить | Правка | Наверх | Cообщить модератору

134. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–5 +/–
Сообщение от Аноним (-), 30-Июл-20, 14:51
GRUB, GRUB2, LILO - это всё эпоха древнего Биоса. Парни сейчас эпоха UEFI, давайте попрощаемся с этими загрузчиками!
Ответить | Правка | Наверх | Cообщить модератору

	144. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+3 +/–
	Сообщение от Sarcastic scutosaurus (?), 30-Июл-20, 15:05
	Не дёргайся, они и UEFI благополучно переживут.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от пох. (?), 30-Июл-20, 16:58
	> GRUB, GRUB2, LILO - это всё эпоха древнего Биоса. Парни сейчас эпоха > UEFI, давайте попрощаемся с этими загрузчиками! угу, systemd-boot наше всь... стоп, но это не загрузчик! Он ничего без дурацкого shim загрузить-то не может. А по факту как раз единственное с чем мы благополучно попрощались - это elilo. Который как раз был загрузчик, и, в отличие от настоящего lilo, не был непонятным недоразумением, унаследованным от флоппидисковых систем, а действительно разумным решением для uefi. В каком там году брошен - в 2012м, или раньше?
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

139. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
Сообщение от vitalif (ok), 30-Июл-20, 14:58
Надоели мне эти "уязвимости". Физический доступ к девайсу должен означать полное овладевание всеми его внутренностями, несменяемые блобами прошивок и т.п. Вреда от залочек куда больше чем пользы
Ответить | Правка | Наверх | Cообщить модератору

	156. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+1 +/–
	Сообщение от kmeaw (?), 30-Июл-20, 15:55
	Тогда нельзя будет реализовать защиту от подмены компьютера или его частей, когда он является куском какого-нибудь кластера. Если "залочки" существуют, то можно заставить удалённую машину пройти аттестацию, и только после этого доверять ей работу с секретными данными. Да, обычному пользователю всё это скорее всего не нужно. Ну разве что secure boot может быть полезен, чтобы не бояться буткитов.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
	Сообщение от AlexYeCu_not_logged (?), 31-Июл-20, 00:15
	>Если "залочки" существуют, то можно заставить удалённую машину пройти аттестацию, и только после этого доверять ей работу с секретными данными. Забавно, что именно те, кто на самом деле работает с секретными данными, таки предпочитают всё это новомодное и дурнопахнущее отключать. Например: >Исследователи из компании Positive Technologies выявили недокументированную опцию для отключения механизма Intel ME 11 (Management Engine) >Компания Intel подтвердила, что опция была добавлена по запросу некоторых производителей оборудования, которые выполняют поставки по контракту с правительством США. Новость с этого же сайта, если что, 2017 год.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
	Сообщение от kmeaw (?), 31-Июл-20, 01:56
	Им проще обойтись физическими регламентами и по старинке поставить по парню с пулемётом у каждого входа. Так надёжнее. А превичную установку и настройку выполнять группами по несколько людей, чтобы шпион не смог единолично и без лишних глаз установить бэкдор. А вот как сделать распределённое вычислительное облако на узлах, которые находятся в недоверенных руках — это уже гораздо более интересная задача. Тут без подобных технологий не обойтись.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от Аноним (21), 31-Июл-20, 04:14
	Облако в недоверенных руках будет тебе по пятницам 13-го выдавать 2+2=5. И не сразу заметишь. Что, забыли ошибки интела?
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от AlexYeCu_not_logged (?), 31-Июл-20, 18:21
	>и только после этого доверять ей работу с секретными данными > Им проще обойтись физическими регламентами Забавно.
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	280. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+/–
	Сообщение от vitalif (ok), 03-Авг-20, 01:39
	> распределённое вычислительное облако на узлах, которые находятся в > недоверенных руках — это уже гораздо более интересная задача. Тут без > подобных технологий не обойтись. Дурацкая задача, на руку только проприерастам
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

154. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	+2 +/–
Сообщение от Аноним (154), 30-Июл-20, 15:50
Буквально неделю назад думал себе на ноутбуке поменять GRUB 2 на Syslinux или LILO, ибо GRUB жирный и тормозной, хоть и использую его с MBR.
Ответить | Правка | Наверх | Cообщить модератору

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

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

281. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."	–1 +/–
Сообщение от Michael Shigorin (ok), 03-Авг-20, 08:08
Если у кого-то шляпа не загрузится после штатных обновлений -- это сюда: http://bugzilla.redhat.com/show_bug.cgi?id=1861977 (раз уж попалась ссылка на глаза).
Ответить | Правка | Наверх | Cообщить модератору

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

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