The OpenNET Project / Index page

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



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

Оглавление

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

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


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.dev/openforum/vsluhforumID3/121426.html#47

Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!

Зачем же ее придумали в TedHat?

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

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

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

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

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

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

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




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

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