Исследователи безопасности из компании Binarly выявили возможность обхода режима верифицированной загрузки UEFI Secure Boot на более чем 800 моделях материнских плат, выпущенных компаниями Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo и Supermicro. Проблема получила кодовое имя PKfail и связана с использованием в прошивках не заслуживающего доверия ключа платформы (PK, Platform Key), сгенерированного компанией AMI (American Megatrends International) и поставляемого в качестве тестового примера. Наиболее старые прошивки, в которых использовался тестовый ключ, выпущены в 2012 году, а самые новые датированы июнем 2024 года. По данным исследователей проблеме подвержены более 10% всех проверенных прошивок...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61610
> производители не обратили внимание на предупреждениену один не обратил внимание, ну два, но восемь сразу?
У всех time to market горит, всем не до этого.
Они хорошие и этот ключ оставили чтобы вы свой core.img от GRUB подписали.
> Они хорошие и этот ключ оставили чтобы вы свой core.img от GRUB подписали.Да, и AWARD_SW вон те тоже сделали чтобы мне удобнее было в чужой BIOS заходить и менять столь вредным админам их пароль на BIOS. И ведь хрен поспоришь - удобно же!
(Upd: Обновленно)
/// > Да, и AWARD_SW вон те тоже сделали чтобы мне удобнее было в чужой BIOS заходить и менять столь вредным админам их пароль на BIOS. И ведь хрен поспоришь - удобно же!
Не вам, а сервис центру, куда вы сами понесёте свой ПК если забудете свой же пароль
(я вот когда то тоже думал что даже по спец шаблону составляя пароль не забуду, а как то недолго времени спустя оказалось что я недооценивал паскудскость человеческой памяти)> В параметрах ключа указывалось, что он не заслуживает доверия и его не следует поставлять в своих продуктах.
Лично мне как то не ясно куда это %censored% и прч.такое там у них смотрит, и т.б.на шифрацию аккаунтов и т.б.дисков, ведь им же самим м.б.понадобится очень быстро получить доступ, не тратя время на переборы(всяких аж 48 битных ключей) что к тому же требует сверх мощности, да даже если по дыре в алгоритме быстрей - что доступно же далеко не каждому их агенту и т.б.может быть надо быстро. В общем, подозреваю со временем все пароли, %censored%, будут попросту запрещенны, включая BIOS'овские. Впрочем, одна из тенденций - идентификация по карточкам и face-контроль, их то так легко не проверить в коде любому желающему на AWARD-SW-"вшивость"...
И доверие у пользователей создают...
>> производители не обратили внимание на предупреждение
>ну один не обратил внимание, ну два, но восемь сразу?А что тут такого?
Это же всё - солидные коммерческие предприятия.
А у нынешних коммерсантов девиз: "Ерак, ерак, и - в продакшен!"
Этот "девиз" - у всех кто сейчас что-то полезное делает. Времена "проэктирования" где 5 лет могли переливать из пустого в порожнее прошли.
поэтому нате вам закрытый ключ от всего - на шитхаб, с паролем 1234 (и тот в соседнем файлике записан)спринт же ж не может ждать.
Время тяпляперов.
А, в добавок какой резон заморачиваться когда пароли всёравно - у другого (MS подписанта)...
Более, когда на продажу же - заранее даже не пойми кому(вкл.своих скрыто врагов разнообразных, начиная с народа, любого), да и конкурентам, в т.ч.и начиная с MSже.
Ну и линуксы и прочее никто не отменял же, их может и мало, %-но у пользователей, зато вони так много что, зачем им это.
Ой, да ладно, как будто раздолбаи только от смузи заводятся. Если вспомнить, то капитаны волчьих стай паролем в энигме матерное слово ставили, чем бритишам облегчили расшифровку на пару порядков
те кто 5 лет гнали такой порожняк, сейчас гонят таймтумаркет, т.е. для твоего контингента ничего изменилось, упорно делаете вид, что работаете, а пипл не владеющий профильными знаниями хавает это все (не все конечно)есть производители, кто всегда делал по-другому, хотя конечно конкурировать с девляперами и прочим "ширпотребом" сложнее, потому что пользователь сам же их поощряеет
Когда загремишь в больничку и протестируешь на себе сделанную сейчас полезную продукцию - отпишись о впечатлениях. Если сможешь.
> Когда загремишь в больничку и протестируешь на себе сделанную сейчас полезную продукцию
> - отпишись о впечатлениях. Если сможешь.Намного лучше попасть в больничку где вот те бинт, вот те зеленка - а больше мы вообще нихрена не разработали. Какие тебе еще нафиг томографы?!
>> Когда загремишь в больничку и протестируешь на себе сделанную сейчас полезную продукцию
>> - отпишись о впечатлениях. Если сможешь.
> Намного лучше попасть в больничку где вот те бинт, вот те зеленка
> - а больше мы вообще нихрена не разработали. Какие тебе еще
> нафиг томографы?!возможно с твоим насморком - это было бы сильно лучше, чем тот японский томограф, который добавил бы к нему лучевую болезнь в тяжелой форме только потому, что доктор захотел посмотреть, что у тебя в легких точно чисто.
И история с очень полезной и эффективной не имеющей побочек вакцинкой от того же насморка тоже ничему, я смотрю, не научила.
Многие из производителей ноутов являются, по сути, брендами, заказывающими железо вплоть до полной разработки и изготовления плат на стороне. Обычно это одна из нескольких ОЕМ контор в ЮВА. Те, кто разрабатывал и делал лично( тот же самсунг ) в списках, по случайному совпадению, не оказался
Для этих уже и аббревиатура своя есть: ODM. Суть: после них наклейку нанести и продать с наценкой. Часто с "тех. поддержкой" и сурьёзным маркетингом.
>> производители не обратили внимание на предупреждение
> ну один не обратил внимание, ну два, но восемь сразу?А ты их BIOS'ы вообще видел? Там такая продукция раджей что они работают по принципу "как-то сбилдилось, вроде не очень глючит, идем продавать!"
Де факто вон то - жесткая индусятина. В хучшем ее виде. Таком что даже DLink на этом фоне может показаться не такой уж плохой. Достаточно посмотреть что например Linux пищет про таблицы ACPI при загрузке. Там баг на баге и багом погоняет. И если кто думал что это только в ACPI так - ага, щас. Индусский кот - так уж по всей площади.
> Достаточно посмотреть что например Linux пищет про таблицы ACPI при загрузке. Там баг на баге и багом погоняет.Это скорей всего не баг(и) - а, сознательная вредоносность.
Мин.вредоносный маркетинг, направленый на уничтожение самой возможности любых альтернативных ОС и просто совместимости с DOS и всякие UEFI тут были уже ранее.
Вредоносность так же как и например с графической VESA2 API в BIOS видеокарт, где и ранее как только не пакостили её(от ограничений кол-ва видеорежимов и вообще так и не начале поддержки WideScreen до порча значений регистров при вызовах) так по ныне с nV 900-йо серсии и выше - вообще уже несколько раз пакостя, например, вообще выпилив функции API в защищённом режиме - что не постандарту в итоге в ч.н.все VESA DOS игры уже вываливаются (правда нек.игроманы сделали свои драйвер(а):] но, альт.ОС на такое паскудство не расчитанные т.е.и все более ранние вообще линуксы в ч.н., котрые заведомо можно запустить уже только на VESA-драйвере, уже собственно даже не запустить... Рука MS? М.б.но не только им это выгодно а и всяким зловредным структурам псевдо-гос. и не очень)
> Это скорей всего не баг(и) - а, сознательная вредоносность.Нагамнякать таблицу ACPI - ну даже не знаю. А что оно так то дает?
> Мин.вредоносный маркетинг, направленый на уничтожение самой возможности любых альтернативных
> ОС и просто совместимости с DOS и всякие UEFI тут были уже ранее.Совместимостью с DOS имхо никто не парится. А так - индусы сами порой от этой рукоджопии и страдают. Не, на самом деле все проще: они тестят этот кус крапа с 1 версией винды, которую планируют преинсталить en masse. Остальное разве что по остаточному принципу и скорей продавать. Получается ессно весьма ожидаемый ужастик от индусов которые вообще не понимали что делали - но с 1 виндой как-то вроде заработало, так что - скорей-быстрей продавать.
Все тайванокитайские OEM в этом смысле одинаковые. Что производители мамок, что *-линки. Это копипастеры почти без локальной экспертизы.
> видеорежимов и вообще так и не начале поддержки WideScreen до порча
> значений регистров при вызовах)Да тоже небось не со зла - а потому что никто вообще это не тестировал даже. Так, на минималках при загрузке что-то рисует - а потом после старта ОС все равно драйвер в нативный режим это переключает - и там в этом массиве числокрушилок с кучей сервисных процов - ничего общего с VESA нет вообще совсем никак. А то что оно немного умеет это косплеить для всякого легаси и чтобы показывать что-то при загрузке - так оно "до кучи".
Более того - на ARM64, RISCV64 и проч - с PCIe - вообще никакого "vesa bios" при всем желании выполнить не получится.
> в ч.н.все VESA DOS игры уже вываливаются (правда нек.игроманы сделали свои
> драйвер(а):] но, альт.ОС на такое паскудство не расчитанные т.е.и все более
> ранние вообще линуксы в ч.н., котрые заведомо можно запустить уже только
> на VESA-драйвере, уже собственно даже не запустить... Рука MS? М.б.но не
> только им это выгодно а и всяким зловредным структурам псевдо-гос. и не очень)Да не, просто эта эмуляция доисторического легаси вон теми числодробилками - тестирована совсем по минимуму. Достаточно чтобы что-то на экране при загрузке казалось - а детали всяких продвинутых видеорежимов ессно никто не тестирует и близко. А т.к. это в общем то та еще эмуляция, и внутрях оно уже давно вообще совсем не ЭТО...
Считаю я досточно привёл аргументов, в отличие ваших "да ну..." в качестве "аргументов".
Которые к тому же разбиваются о ещё один факт - в их более ранних BIOS - всё работало, поломки - сознательные.
Аппаратных изменений, чтобы на них сваливать, так мало что, как ук. - сами игроки правят, беря куски драйверов от древних(10+ лет) версий карт.
Тестировать производителю, даже любой самой задрыпанной компании но, с много-сот миллионным оборотом, - не то что не сложно а, обязательно делается ибо иначе сразу сверхмассовые возвраты, и просто копейки для их бюджета.
Незаметить незапуск даже всех VESA DOS игр, не говоря про альтернативных отн-но MS/Mac ОСей, можно конечно, если не желать это замечать. Т.б.уже на протяжении почти десятилетия...
> Которые к тому же разбиваются о ещё один факт - в их
> более ранних BIOS - всё работало, поломки - сознательные.Если учесть что BIOS у сабжей стал UEFI так то - и какой-то compat с BIOS работает как правило поверх этого и оно, таки, ремимплементация - тут тоже никаких теорий заговора может и не быть.
Обычное сочетание оверинженерии, битрота и хренового тестирования может то, что никакому заговорщику не под силу. Бизнес жадный. Времена разработки и тесты - по минимуму. И скорей-быстрей продавать. Ну оно и получается чем должно.
> Аппаратных изменений, чтобы на них сваливать, так мало что, как ук. -
> сами игроки правят, беря куски драйверов от древних(10+ лет) версий карт.Аппаратных изменений в видеокартах - немеряно. Вплоть до смены всей микроархитектуры раза 3-4 уже. Но чтобы это знать - надо в топике немного разбираться. И, конечно, внутрях оно не имеет ничерта общего с VGA адаптерами и чем там еще. Так, эмулирует абстракцию на минималках чтобы что-то показывать вон там при загрузке. Тестится тоже на минималках.
> Тестировать производителю, даже любой самой задрыпанной компании но, с много-сот миллионным
> оборотом, - не то что не сложно а, обязательно делаетсяВидите ли, сейчас массовый клиент не вызывает VESA BIOS. Вообще совсем никак. Ну, может, при загрузке пару менюх. Ну вот это и проверят. И да, там даже допустимо если оно выглядит компромиссно, нормальный юзер видит это - раз в эн лет.
> ибо иначе сразу сверхмассовые возвраты, и просто копейки для их бюджета.Откуда какие сверхмассовые возвраты из-за кривой VESA? Кто ей пользуется? Оно должно "что-то показывать" до момента пока юзер не вкатит драйвер. На этом требования к нему заканчиваются.
> Незаметить незапуск даже всех VESA DOS игр,
...проще простого, intel вообще уже грозится окончательно убабахать compat с BIOS в новых компах. DOS игры если кто и запускает - то в чем-то типа DOSBOX. А DOS в диком виде я видел лет цать назад - на какой-то старинной кассе. Больше он вообще хождения в современном мире не имеет.
> не говоря про альтернативных отн-но MS/Mac ОСей, можно конечно,
Ну, как бы вон тех это все не очволнует. Вон там для пингвина дрова есть еще, и хорош. Кто там и как в колибри это прикручивать бу - никого не е.
> протяжении почти десятилетия...
Чуть больше я думаю. Замена dos-based win 9x -> NT based win случилась около 20 лет назад. В примерно те же поры массовый софт перестал что либо делать с VGA/VESA BIOS'ами.
Драйвер первым делом переводит GPU в нативный режим, vga-фэйк с шины пропадает нафиг, и на этом - гудбай, его до ресета железки более никто не увидит там :)
Bios кто делал? Зачем произодителю плат туда лезть?
Да никому этот UEFI Secure Boot не usralsa, вот и всё. Чтоб действительно оно как-то секурно работало, там надо проделать тонну вообще не очевидных действий. И не единожды - технология совершенно не жизне способна - маркетинговое гонево не более.
Миллионы глаз смотрели.
Думаете, этот "secure boot" хоть сколько-нибудь нужен производителям материнских плат?
Думаете, этот самы "secure boot" зачем-то нужен пользователям этих материнских плат?Нет, вся эта хрень нужна только копирастам.
Поэтому, разумеется, производитель материнской платы делает строгий минимум, необходимый, чтобы его материнка была помечена как "совместимая" и "поддерживающая" эту хрень.
Соответственно, отсюда - минимальный объем тестирования.
А криптография - это всегда сложно и дорого. Поэтому - если на неё можно забить, на неё - забьют.
Секурно, что ещё сказать. Не то что BIOS.
Шо то, шо это, вот это таких два...
Ах, господа, первая сущность равно как и вторая мне одинаково постылы и столь решительно безрадостны, что скорее...
Эхх, где же OpenFirmware...
https://support.system76.com/articles/open-firmware-systems/Тут, например.
> https://support.system76.com/articles/open-firmware-systems/
> Тут, например.Батенька, вы бы сходили сами и прочли что там у них накорябано :).
AMI BIOS
> AMI BIOSДавние тралициию AMI_SW же. Ну, это их ответ AWARD_SW такой был :).
Так то удобно. Если с правильной стороны монитора, конечно. Я как-то так по приколу заметил что админы пароль поставили. Ну по приколу - вырубил кеш у проца да сменил пароль, чтобы им не скучно было.
Вот ты приколист конечно.
ох.. универсальный пароль AWARD Bios все помнят ?
AWARDSW
:-)
Почти угадали
EFI без U вполне себе торт.
Театр безопасности. Реальная защита - зашифрованный корень и проверка с livecd хешсумм grub и boot при каждой загрузке.
Хорошо бы название театра и фамилию Карабаса.
Лично я фанат японского театра теней Букаккэ
Придумала Intel. А попыталась залочить на себя Microsoft. В последнем случае, как и все ее инициативы, один вред, а пользы нуль.
это не реальная защита, потому что Secure Boot происходит до проверки хэшсумм grub и boot
Перечитайте ещё раз моё сообщение. Вставляем флешку с livecd, проверяем хешсуммы. Если верные - вынимаем флешку, загружаемся в установленнуо ос. Всё, загрузка верифицирована. А в самой системе защита обеспечивается прямыми руками (не устанавливать из васянских сборок) и apparmor с selinux.
Думаешь тебе в Сиэтл (или где там вы хоститесь?) командировки светят а?, вставляльщик лайвсидей? :)
Так нет же - образ того лавсидя ваши девопсы точно так же на гитхаб положат :) Чтоб по сети монтировать и чекать :)Нонешнее оЙтЕ - бессмысленное и беспощадное, да :))))
Думаешь, твои выдуманные проекции на других что-то значат в реальности?
Перечитал еще раз ваше сообщение и понял, что вы не читали Reflections on Trusting Trust Кена Томпсона.Root of Trust идущая от железа - это именно научный подход к устранению этой проблемы (чтобы не придирались: применительно к безопасной загрузке). Простыми словами: evil maid создает зеркало с правильными/измененными файлами. Все хэши в первый раз сходятся. А при исполнении кода грузится другой сектор. Или проще. Прошитый непонятно куда вредоносный драйвер UEFI. Удачи в вычислениях.
> Root of Trust идущая от железа - этоНовость перечитай теперь.
Новость - брешь в реализации Secureboot (который в исполнении производителей ради ограничения пользователей я нисколько не оправдываю).А livecd поверх потенциально скомпрометированной системы - это by design. На первом шагу возможен дамп livecd для последующего pwnage. Первое будут исправлять, а это нет.
> Театр безопасности. Реальная защита - зашифрованный корень и проверка с livecd хешсумм grub и boot при каждой загрузке.Это уже цирк безопасности.
от кого защищаться собрался онон?
Я свой худший враг. Так что все очевидно!
А еще не забывай пересчитать хэши после каждого обновления grub и boot.
Это уже было 30 лет назад под DOS. Называлось ADinf
Это же все для пользователей линуха, что бы не отключать SecureBoot и подписывать что сам насобирал себе =)
Выразился бы точнее - для пользователей не-Windows.
Нет, он всё правильно написал. Все остальные ОС на реальном железе не работают.
И Фантом?!
Чтобы подписывать самосбор, никакие ключи не нужны, кроме тех, которые сгенерируешь сам.
В этой новости отражена вся заинтересованность многих производителей мат. плат в качественной прошивке.
Это интересует ни пользователей, ни производителей.
Потому что от стандартных ключей SecureBoot никакого смысла нет, шифрование диска с tpm2 оно чаще всего не защищает, потому что зависимость PCR регистров от ядра системы и прочего делать неудобно и опасно, а со стандартными ключами никто не мешает загрузить любую другую систему.PlatformKey нужно выпускать свой, и загрузчик/ядро/прочее подписывать им, тогда и появляется реальная польза от SecureBoot.
> а со стандартными ключами никто не мешает загрузить любую другую системуЭто не так.
При загрузке "любой другой системы" (пусть хоть другой винды c LiveCD) у тебя диск не расшифруется автоматически, и тебе понадобится какой-то запасной вариант (при условии, что владелец машины его предусмотрел, например, настроил авторасшифровку при обычной загрузке и расшифровку с паролем при "необычной" загрузке).
Отключил его сам. Какие подводные? Кто-то прошелестят ко мне в конуру и установит винду?
Можно установить троянца в ESP, чтобы перехватить пароль расшифровки твоего корня. Если он, конечно, у тебя зашифрован.
Интересно, эти ключи брутфорсом подбирались или АНБ намекнуло производителям?
>Интересно, эти ключи брутфорсом подбирались4 символа бро - мои часы наверное секунд аж 30 бы подбирали пароль ... Serious Security(C)
"если выглядишь вкусно - не гуляй вечером в парке!"отрежут же часы вместе с рукой, и сам будешь виноват.
Пароль "abcd". `john --incremental:Alnum --min-length=4 --max-length=4 --format=pfx-opencl` справился за одну секунду, благо, длину пароля нам любезно сообщили авторы доклада, но даже без этого в режиме incremental он справился бы крайне быстро.
Секурбут это бэкдор для блатных - есть хоть кто-то, кто сомневался?Существует исключительно в падлостроительных целях как явно, так и подводнокаменно.
Тут постоянно проскакивают люди из мира розовых пони которые уверены что это просто ошибки. Даже не верят что IME это зонд. Таких уже на вылечить.
А революцию социалистическую если?
Зато теперь можно клепать болгеносы, гордо заявляя о поддержке uefi sb, даже для самого себя.
100% машин идет с ключем МС, которым они подписывают все, что под руку попадет.
потому, для "обхода UEFI Secure Boot" достаточно поставить пакет shim-signed, или как он в репах вашего дистрибутива называется, перенести один файлик на флешку и преспокойно грузить все, что душе угодно на любом компьютере с включеным sb.
хотите безопасности - убирайте дофлтные ключи, вместе с shim'ом, ставьте свои, и настройте загрузку либо через UKI, либо efi-stub ядра. это парочка команд.
только вот, при этом сценарии и никакие дефолтные ключи AMI не страшны, так что, мне совершенно не ясно, что так удивило автора новости.
если кому интересно,
про shim и нерабочий secure boot из каробки: https://habr.com/ru/post/446072/
гайд по настройке secure boot(на английском): https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
Ну зачем такие сложности? Вынул жесткий диск. Скопировал, что надо. Вернул назад. Если запаролен, ломается на ура что в Windows, что в Linux.
сломать условный luks легче, чем выполнить cp в терминале?
ну, кому как. особенно, в случае современных систем, где 100 лет в обед, как argon2id с tpm и пароль спокойно может быть и дампом из /dev/urandom
И как вы будете ломать LUKS у которого ключи в TPM модуле, например? Разве что вас зовут Барак Байден, тогда вопросов нет.
Гаечным ключем и пустырником.
Ключом. Извините ) https://youtu.be/tLsef4HaXOk
> И как вы будете ломать LUKS у которого ключи в TPM модуле, например?Терморектальный криптоанализ пока никто не отменял...
>> И как вы будете ломать LUKS у которого ключи в TPM модуле, например?
> Терморектальный криптоанализ пока никто не отменял...Ну до пустим вы выкрали диск (а может быть даже его образ, побайтовый) и даже нашли чела который знает пароль\PIN к TPM модулю, но самого модуля у вас нет, или он был обнулен, потому что насколько я помню нельзя так просто переставить съемный с одной материнки на другую. Что дальше? Ключ-то был в TPM.
Как ни крути оказывается что вам уже нужен весь "программно-аппаратный комплекс".
еще большее веселье наинается когда у пользователя запоминаемая часть в голове, а незапоминаемая - в tpm.
у меня так, по крайней мере
> еще большее веселье наинается когда у пользователя запоминаемая часть в голове, а
> незапоминаемая - в tpm.
> у меня так, по крайней мереА это обычная история, "я зашифровал диск по туториалу", а теперь чет нихрена не работает, плиз хелп, резервных копий нет, ключи похерены.
Смысл TPM же что вашь пароль к нему - это пароль к "аппаратной связке ключей". Вот только связка эта сама опорожняется порой.
А вообще, если у вас LUKS то можно FIDO2 попробовать, в свежих версиях это работает, хотя и не без неудобств.
А можно и в pkcs11 держать ключик, тоже работает
я не про пин tpm'а, а про кусок пароля диска. полностью ему диск доверять как то страшно.
и да, бэкапы есть, в том числе, ключей из tpm.
что до аппаратных ключей.. в чем отличие, кроме того, что я их с большим шансом посею? фактически, они тоже ломаются и тоже могут выйти из строя, только вот tpm у меня в ноуте уже был, а это еще покупать нужно.
> я не про пин tpm'а, а про кусок пароля диска. полностью ему
> диск доверять как то страшно.
> и да, бэкапы есть, в том числе, ключей из tpm.
> что до аппаратных ключей.. в чем отличие, кроме того, что я их
> с большим шансом посею? фактически, они тоже ломаются и тоже могут
> выйти из строя, только вот tpm у меня в ноуте
> уже был, а это еще покупать нужно.Ну если переломить пополам - сломается, а так задуман быть прочным. Можно ли потерять - конечно, с другой стороны - не впаян в ноутбук.
Что до покупать нужно - на самом деле найти можно достаточно недорого, спасибо параллельному импорту и Авито (лол).
> Ну до пустим вы выкрали дискЗачем мне чего-то красть?)) Если будет очень надо, я просто возьму владельца диска и вежливо спрошу, что на нём находится. Сам жёсткий диск мне для этого не нужен. Причём спрашивать сначала буду действительно вежливо - далеко не всегда нужно человека резать на куски, чтобы он рассказал всё, что знает. Обычно достаточно просто продемонстрировать, что ты можешь и готов это сделать.
>> Ну до пустим вы выкрали диск
> Зачем мне чего-то красть?)) Если будет очень надо, я просто возьму владельца
> диска и вежливо спрошу, что на нём находится. Сам жёсткий диск
> мне для этого не нужен. Причём спрашивать сначала буду действительно вежливо
> - далеко не всегда нужно человека резать на куски, чтобы он
> рассказал всё, что знает. Обычно достаточно просто продемонстрировать, что ты можешь
> и готов это сделать.А на диске - снимки обратной стороны Луны, на которых видны вкрапления ледников (ну гипотетически) ну или что-то такое, может быть бухгалтерия Обамы. На допросе вы конечно скажете что там примерно содержится, но не карту же вы по памяти рисовать будете?
> А на диске - снимки обратной стороны Луны, на которых видны вкрапления
> ледников (ну гипотетически) ну или что-то такое, может быть бухгалтерия Обамы.
> На допросе вы конечно скажете что там примерно содержится, но не
> карту же вы по памяти рисовать будете?А зачем мне вся карта или вся бухгалтерия Обамы? Обычно требуется нечто вполне конкретное. Например места расположения условных баз или номера условных левых счетов и способы доступа к ним. Такое человек расскажет вам по памяти легко. Вы даже не представляете, что вы помните и что из вас при должной стимуляции можно достать. Как-то по работе потребовалось по дням восстановить в какие дни в прошлом месяце был дождь, а в какие нет. И в какое конкретно время. И, знаете, вчетвером головы почесали и таки вспомнили. Отвязались от значимых событий, которые каждый помнил, а дальше по ассоциациям всё восстановили.
Да и с картой тоже возможны варианты. Вы удивитесь, но достаточно долго например на море картами особо не пользовались - они шли больше как вспомогательный материал, чтобы представлять общую картину. А главной ценностью были самописные лоции, где хранились сведения вида "после мыса N повернуть на север-северо-восток и так держать три дня, после чего появится побережье острова M, где можно набрать пресной воды и есть дичь для пропитания".
И с рисованием карты целиком тоже возможны варианты - это я вам как профессиональный штурман говорю.
>[оверквотинг удален]
> вчетвером головы почесали и таки вспомнили. Отвязались от значимых событий, которые
> каждый помнил, а дальше по ассоциациям всё восстановили.
> Да и с картой тоже возможны варианты. Вы удивитесь, но достаточно долго
> например на море картами особо не пользовались - они шли больше
> как вспомогательный материал, чтобы представлять общую картину. А главной ценностью были
> самописные лоции, где хранились сведения вида "после мыса N повернуть на
> север-северо-восток и так держать три дня, после чего появится побережье острова
> M, где можно набрать пресной воды и есть дичь для пропитания".
> И с рисованием карты целиком тоже возможны варианты - это я вам
> как профессиональный штурман говорю.Ну вы уже, отчасти, придираетесь по мелочам. Да в каких-то случаях вам может быть нужна одна строчка из базы, или достаточно одного ориентира (что кстати совсем не вариант для условной точки в условном Море Спокойствия, где зондирование показало что-то под поверхностью, ткнете пальцем - ошибетесь на многие сотни километров в лучшем случае).
Может быть вам нужна ВСЯ база данных, в доказательных целях, скажем, может быть это исходный код нового ИИ и "ой, ну ты тот потеряли чутка" - не приемлемо. Залатаете код Скайнет абы как - он вас первого и взорвет, вот так иронияМожет быть это последнее фото ненайденного шедевра да Винчи и лишь часть произведения вас не утраивает (Мона Лиза без лица, тут я уже утрирую, да). Вариантов, однако - достаточно.
> Ну вы уже, отчасти, придираетесь по мелочам.Да нет, боюсь, что это именно ваш грех)) Впрочем, для полной объективности тут нужен сторонний арбитр.
А про тот же ИИ - вам не нужен весь код. Нет, если получится достать, то хорошо конечно. Но в целом - принцип работы конкретного экземпляра можно описать в условных двадцати предложениях. Это я про аппаратную часть. И столько же нужно на описание структуры базы данных, которой данный конкретный экземпляр пользуется. А дальше воссоздать его - дело техники. Причём, тот, кто знает в деталях, как оно всё внутри устроено (я имею ввиду на других аналогичных примерах), может обойтись и меньшим. Специалисту зачастую достаточно пронаблюдать, как ведёт себя изделие на тех или иных примерах, и он вам с достаточно высокой точностью обрисует, как оно всё там внутри устроено. Физика процесса то одна и та же везде. Меняются лишь алгоритмы перебора базы данных, да и то - не принципиально.
В целом же любое шифрование служит только одной цели - дать время минимизировать ущерб при случайной утечке данных. Потому что при целенаправленной утечке атакующий в большинстве случаев получает искомое. Ибо чётко знает, что конкретно ищет и как это можно получить. Да и методы прямой атаки редко используются. Если поискать статистику, то станет очевидным, что в большинстве случаев причина утечек - человеческий фактор. Причём вовсе без членовредительства, а лишь по банальной человеческой жадности. Небольшая сумма денег, и условная база клиентов банка уже у вас в кармане.
> В целом же любое шифрование служит только одной цели - дать время
> минимизировать ущерб при случайной утечке данных.Ну не, почему. Иногда помогает. Если некто нашел "холодный" диск/вырубленый ноут/комп и проч - и не можете поспрашивать в убедительном виде что и кто - крипто свое дело сделало.
А если начинается вон то, про физический доступ... как это на практике будут гасить, если оно кому-то надо? Не, никто не будет возиться с TPM, i2c шиной и какой там еще порнографией. Скорее закинут троянец через многочисленные дыры в браузере или чем там у вас. Эскалируют права через многочисленные CVE (вы их все точно патчили в темпе вальса и ребутались как зайцы?). Дальше... а что это у нас тут? А, диск? Уже смонтированый, со всеми ключами, по фэншую?! Во, видите, вы сами все ввели. И никакой академической гребли.
Если это обычный пользак, и не предпринял никаких мер - его наиболее ценные данные сделают фьють по сети в пользу атакующего. ЧСХ это до некторой степени полезно даже если эскалация не прокатила, ведь если интересный юзер имел доступ, то и левый код/скприпт под ним - тоже это все сможет!
Если атакующий эстет, он после эскалации может попытаться стырить бонусом из "физической" памяти ключ которым шифрованый диск реально шифруется, а не то что там в TPM. Чтобы шифровать и расшифровывать, ОС должна знать этот ключ. Значит он в памяти - есть. И его можно умыкнуть. И так можно вообще все оптом расшифровать и даже потом, если оно зачем-то кому-то надо.
Я примерно так себе аннулировал шифрование профайла Tox, когда пароль на него забыл. Крякать ЭТО? Ух не, там Argon, чтоли, считает долго, брутфорсить помрешь нахрен. Но если есть права бога (а у меня в отношении VM они конечно же есть вон оттуда) - дампануть RAM вполне опция. И вот он, забытый пароль. Не, вынести его из RAM нельзя. А как иначе шифровать тогда?!
Есть варианты алго шифрования, где ключи только в регистрах, на которые эта магия не работает - но оно медленно и специфично. И потому распостранения не получило. На физической железке можно включить режим ядра Lockdown - тогда даже рут не сможет копаться в физической оперативке по простому. Но сколько хомячков так делает? Правильно - немного. Поэтому отлично сработает после эскалации (для которой CVE - хватает).
Если кто не понял в чем проблема: атакующие используют самый простой вектор ведущий к достижению цели. Как гласит комикс XKCD, на практике - "вот тебе 5-баксовый разводной ключ, просто дубась им пока не скажет пароль". А вон то в случае если эта опция атакующему недоступна.
> Ну не, почему. Иногда помогает. Если некто нашелЭто и подразумевалось под случайной утечкой. Если вы потеряли флэшку/ноут/что_угодно_с_памятью, то шифрование даст вам некоторый запас времени, чтобы вывести из под удара то, что для вас критически важно. Поменять пароли там, предупредить людей и т.п. Если кому-то очень нужны данные с вашего утерянного устройства, то шифрование не спасёт, а лишь отсрочит их получение.
> А если начинается вон то, про физический доступ...
Если у атакующего есть физический доступ к железу, то как бы мера защиты тут может быть одна - просверлить жёсткий диск. И то не факт, что поможет - всегда будут те, кто сможет рассказать всё нужное и без всяких жёстких дисков.
> Если это обычный пользак, и не предпринял никаких мер - его наиболее
> ценные данные сделают фьють по сети в пользу атакующего.С "обычным пользаком" никто из "серьёзных" людей даже заморачиваться не будет. Потому что затраты многократно превысят ценность полученной информации. В крайнем случае, если уж очень надо - прессанут по быстрому. Причём совершенно не обязательно, что с помощью физического воздействия. Достаточно просто человека как следует напугать. А этого можно добиться и просто словами. Или вовсе договорятся за скромное вознаграждение.
С "обычными пользаками" заморачиваются обычно (пардон за каламбур) только в одном случае - когда бьют по площадям. В этом случае - да, "не качеством, так количеством доберём". Но тут опять же применяются банально простые методы, вроде звонка с заявлением: "Всё пропало, срочно переведи нам деньги". С ломом кого-то скорее всего будут морочиться, только если нашли дырень, которая есть у +/- 70% пользователей. Тут уж мало кто от искушения удержится. И то, с оговорками. Потому что проблем огрести можно массу, а вот прибыль совсем не гарантирована.
> Если кто не понял в чем проблема: атакующие используют самый простой вектор
> ведущий к достижению цели.О том и речь.
ну и сравните его с выполнением cp в терминале 1 раз
> ну и сравните его с выполнением cp в терминале 1 разАга, а потом ещё разбирать терабайты данных. Часть из которых может быть зашифрована независимо. Как и написал выше в другом комментарии - зачем? Я просто возьму того, кто знает, что мне нужно, и вежливо спрошу. Так будет гораздо быстрее и проще. Если вежливость не поможет, тогда к ней можно добавить демонстрацию чего-нибудь колюще-режущего. Далее по нарастающей, в зависимости от срочности и необходимости данной конкретной информации. Вам чисто для справки: чтобы получить от человека нужные сведения достаточно, чтобы у него были один глаз, одно работающее ухо и три пальца на рабочей руке. Но чаще всего до такого состояния не доходит. Поскольку либо человек расскажет всё гораздо раньше, либо информация получается каким-либо другим путём, без членовредительства.
госпади, хотите - спросите.
я лишь ткнула в то, что многие возможностями своей материнки пользуются не на полную, а некоторые вовсе живут в иллюзии, думая, что sb с ключами от мс - это гарантия защиты.
> госпади, хотите - спросите.
> я лишь ткнула в то, что многие возможностями своей материнки пользуются не
> на полную, а некоторые вовсе живут в иллюзии, думая, что sb
> с ключами от мс - это гарантия защиты.Так и я в общем-то о том же)) Просто я вам пытаюсь донести, что гарантий вообще не существует. Если кому-то ну о-очень нужна информация, то он её получит. И для этого вовсе необязательно сильно заморачиваться с высокотехнологичными способами. Что тысячу лет назад, что сегодня всё завязано на человека. Поэтому опять же что тысячу лет назад, что сегодня самый простой и быстрый способ получения информации - "тряхнуть" её владельца.
Правильный же подход к безопасности: 1) обеспечить своевременное обнаружение утечек данных 2) сосредоточиться больше не на методах защиты информации, а на разработке плана действий в случае, когда утечка уже произошла. И работа с людьми. Мотивировать правильно нужно сотрудников, тогда и утечек не будет. Но это уже совсем другая тема.
ну и, на последок почитайте, что такое evil maid, сильно удивитесь.
ps пользователь Вам сам пароль даст, ничего не подозревая и думая, что он в безопасности, раз у него секурбут.
откуда информация? т.е. ты сможешь расшифровать LUKS диск с KDF argon AES-XTS?можно больше подробностей?
К сожалению, не каждый производитель позволяет устанавливать свои ключи. Часто ограничивают до ключей MS.
эм.. кто? эти переменные, согласно спеке, нельзя помечать как ro.
intel boot guard и то смотрит только в {PK,KEK,db,dbx}-Default, не трогая PK, KEK, db и dbx.
если просто нет пункта в граф. интерфейсе, то, во-первых, есть keytool.efi, по-моему, он даже в одном пакете с shim в дебиане, во-вторых, возможно, плохо искали. я например первый раз делала через keytool, а потом, когда ключи запорола, узнала про комбинацию, включающую расширенный режим в uefi, где и было соответствующее меню.
Мне что-то подсказывает, что у это...их производителей (namely apple) НЕТ того левого ключа microsoft которым та (предсумотрительно) подписала shim.А винду корпорация-зла, не будь дура, ни разу не этим же ключом подписывает. Так что ваша дисяточка там загрузится без проблем.
у них и возможность грузить что то кроме macos без костылей нет
> у них и возможность грузить что то кроме macos без костылей нетинтеловские - прекрасно умеют грузить вендупоганую.
оно уже и не поддерживается эплом
с чего это вдруг? x86ые маки не сняты с поддержки, bootcamp где лежал там и лежит.А M1/M2 не поддерживаются..не эплом, в общем. Фиг знает за что корпорация на них так зла, что имея (почти) готовый код не хочет продать (с другой стороны - а что на нем запускать-то кроме калькулятора?)
А еще проще не полагаться на tpm модуль, который можно снять паяльным феном, и просто хранить загрузчик и необходимое на флешке, спасибо uefi, и заверять уже после загрузки системы. Флешку носим с собой и вынимаем когда заканчиваем работу. Все безопасное просто, а следить за ключами и всегда подписывать ядра на лицо оверинжинеринг и когда нибудь это выйдет боком, плюс неизвестно какие баги находят для обхода secure boot в проприетарных прошивках плат.
После загрузки у тебя уже загружен код который раздостно заверит тебе всё что угодно.
Также как и с tpm модулем, только в случае с флэшкой до неё труднее добраться. А tpm модули, кстати, некоторые можно прочитать не снимая с платы, просто подобравшись специальной прищепкой.
нет, товарищ, в случае с tpm модулем, если он зафиксирует изменение прошивки, или базы данных sb, он вас лесом пошлет.
надеюсь, Вы не тролль
Сразу видно человека, который про такие атаки только в интернете читал. На хабре можете почитать статьи как разревёрсить сигналв с модуля tpm и прочитать регистры. Знающие люди чтобы не усложнять и без того сложные схемы действительно ходят с флешкой со всем необходимым и максимально разграничивают незашифрованные и зашифрованные данные, и ничего не хранят в третьем компоненте системы. Благодаря этому всегда можно просто вытащить диск и бутнуться с другого компьютера, только идентификаторы от железа могут остаться в новой машинке, но это другая история. Если вы думаете что модуль tpm какой то магический и из него сложнее вытащить данные по сравнению с незашифрованным разделом на ссд, вы сильно заблуждаетесь. Просто не люблю дурачков, которые оправдывают схему с tpm, не зная поднаготной реальных атак.
Вы б, господин "знающий людь" поменьше языком работали и давали больше фактов! :)
Влибо факты давайте, либо не скатывайтесь в бросание сами знаетея, чем и "дурачков"
Вы, судя по всему, мой тезис про tpm в процессорах проигнорировали. что ж, ткну еще раз - это работает(или работало? углубляться даже лень, ибо меня не касается) только с отдельными чипами.
из процессора Вы, опять же, ничего не нанюхаете. ну и, да, забавно видеть "человека, который читал тотолько в интернете" и через пару слов - "посмотрите на хабре"
еще более потешно, что Ваш второй комментарий скрыл модератор.
Зы. почти все(если не все, но зарекаться сейчас не буду) косяки в процессорных tpm'ах фиксятся обновлением прошивки
По хабру кстати неплохая статья реально была, там чел не ломал секьюр бут вроде а просто пытался загрзузить систему лол, показательно куда эта схема с секьюр бутом и оправдывающими это адептами микрософта могут идти
ну, факты будут? ссылки? что-то?
если есть - давайте, почитаю.
из того, что знаю - перепрошивка платы, что фиксится iBG'ом и описанное в первоначальном сообщении. + проблемы, специфичные для некоторых производителей.
не представляю уж, что Вам там такого написали, но что точно знаю - это куда могут идти товарищи, кричащие про "адептов майкрософта" в контексте sb, особенно, под сообщением с призывом зашить свои ключи, лол.
раз - уже давно tpm встраивают в процессоры, так что, вероятно, замаятесь снимать. два - зачем? Вы из него ключи вытаскивать собрались? если так, то закалебетесь вытаскивать из чипа с актуальной прошивкой.
касаемо флешек.. ну, Вы серьезно? так часто слышала этот тезис, если его можно так назвать, и не понимала, верит ли вообще сам человек в собственные слова.
что до "оверинжениринга", мне не ясно, что Вы имеете в виду.
это ужа давно делает автоматика. я генератор uki трогаю только в том случае, когда мне надо параметры ядра, например, поменять. как может выйти боком исполнение пост-инсталл скрипта, поставляемого дистрибутивом, мне тоже не понятно.
ровно, как и про жуков. найдете - тогда поговорим.
так-то, и в алгоритмах шифрования находят уязвимости, это неизбежно.
сейчас есть все средства для верификации кода, исполняемого прошивкой и ограничения "изнутри", созданные именно для смягчения ситуаций с багами.
много Вы багом видали за последнее время, не связанных с сетевой загрузкой, или косяком конкретного производителя?
Переусложнённая система. Обязательно что-нибудь выйдет боком. Почитайте теории сложности и надёжности. В популярном изложении "законы Мерфи".
в случае с флешкой - она у Вас из кормана выпадет. а "что-нибудь" и, тем более, "почитайте", пожалуйста, оставьте себе.
я почему-то вместо того чтобы просто сказать "народ, учите матчасть", вам тут что-то обьяснить пытаюсь. придумаете хотя бы какой-то суенарий - тогда и напишите. а это скукота какая-то выходит и аргументация уровня кофейной гущи
Чел, что мешает мне с такими аргументами потерять ноутбук?
сказал человек с аргументом "что-то выйдет боком", лол?
Эээ.. Некоторым и самые прямые аргументы будут "совершенно бездоказательны" и "скучны".Свежий пример: плата от Asrock на чипсете от Intel.
EFI загрузчик на флешке увидела примерно попытки с 15-й.
Установленная Fedora запускалась нормально 2 недели.
Затем EFI на ровном месте потерял её запись, обнаружилось при тёплом рестарте.Если указатель на загрузчик просто "испарился",
где гарантии, что так же не "испарятся" ключи или пароли на сам EFI?
В какой-то момент понадобится что-то срочно сделать,
а человек вместо этого должен будет раскирпичивать устройство...С DOS-овым загрузчиком и GRUB2 вообще никаких проблем.
Потому что он "простой как 3 копейки".Да секур проблема есть, с EFI попытка зачтена, причём как неудачная.
Нужно идти дальше и рассматривать более другие решения.Посмотрите, не читайте, хотя бы по диагонали доку на Clover -
это одна из реализаций EFI от сообщества под MIT-подобной лицензией -
сколько там параметров в настройках, и коментарии к ним.
Да, проделана титаническая работа.
Однако, тем не менее, очень многие параметры вообще ни на что не влияют.И да, я пытался заменить глюченый закрытый EFI от Asrock открытым Clover.
Но последний так и не запустился ни в одном из описаных вариантов установки
(ну, кроме .exe инсталятора, который просто не на чем запускать).
Занавес.
во-первых, Вам стоит на на опеннете об этом писать, а производителю с требованием возврата средств.
во-вторых, я всех деталей не знаю, может вообще Вы сами себе что-то накрутили.
у меня, например, послы вытаскивания батарейки с платы, и пароль, и ключи остались на месте.
> во-первых, Вам стоит на на опеннете об этом писать, а производителю с
> требованием возврата средств.Тем не менее, железо иногда ломается. И если мамка/проц внезапно станут тыквой - у вас на этот случай был хитрый план как вообще данные с вашего веника вынимать? Или таки - пробурчать "не очень то и хотелось" и форматнуть заново?
> раз - уже давно tpm встраивают в процессоры, так что, вероятно, замаятесь
> снимать. два - зачем? Вы из него ключи вытаскивать собрались? если
> так, то закалебетесь вытаскивать из чипа с актуальной прошивкой.Идея встроить TPM в процессор одновременно прекрасна и ужасна. С одной стороны это и правда секурно, с другой стороны выстрелить себе в ногу и потерять ключики в TPM модули оказывается невероятно легко.
Обновление прошивки у некоторых производителей - сброс TPM, замена материнки - сброс TPM и так далее.
Образ диска украденный через мировой эфир и правда становится бесполезен, но может стоит хранить ключики на чем-то чуть менее встроенном?
иначе никак, собственно.
бэкапы ключей из tpm делаются в пару команд и никто не мешает залить их на флешку и хранить дома.
в конце концов, может и диск из строя выйти, это цена хранения данных в цифровом виде.
продукцию этих самых "некоторых производителей" можно и не покупать, лол. "некоторые производители" могут Вам и устройство бракованное дать, что с того-то?
> в конце концов, может и диск из строя выйти, это цена хранения данных в цифровом виде.Именно в силу возможности выхода из строя вторичного носителя приходится делать бекапы, что нивелирует сам смысл хранения ключей в TPM.
> иначе никак, собственно.
> бэкапы ключей из tpm делаются в пару команд и никто не мешает
> залить их на флешку и хранить дома.
> в конце концов, может и диск из строя выйти, это цена хранения
> данных в цифровом виде.
> продукцию этих самых "некоторых производителей" можно и не покупать, лол. "некоторые производители"
> могут Вам и устройство бракованное дать, что с того-то?Вот только бекапы ключей вам надо где-то хранить, причем секурно, а "флешка с файликом" по умолчанию уже не так секурно.
С условным LUKSом могут быть варианты, там все таки разные способы анлока есть, но тогда зачем возня с TPM?
диск с бэкапом я храню дома и пароль записан на бумажке такой, который я сама запомнить не в состоянии.
для ноута такой не поставишь, ибо часто включаю/выключаю, придется бумажку с собой носить, либо полагаться на память.
> диск с бэкапом я храню дома и пароль записан на бумажке такой,
> который я сама запомнить не в состоянии.
> для ноута такой не поставишь, ибо часто включаю/выключаю, придется бумажку с собой
> носить, либо полагаться на память.Вскрыть дверь, унести диск с бумажкой?
> диск с бэкапом я храню дома и пароль записан на бумажке такой,
> который я сама запомнить не в состоянии.Поэтому имеет смысл юзать пароли которые запомнить все же в состоянии. См пример про "correct battery staple horse" :)
> потому, для "обхода UEFI Secure Boot" достаточно поставить пакет shim-signed, или как
> он в репах вашего дистрибутива называется, перенести один файлик на флешку
> и преспокойно грузить все, что душе угодно на любом компьютере с
> включеным sb.и зачем такие сложности, если можно просто венду загрузить? secure boot защищает вовсе не от этого.
> хотите безопасности - убирайте дофлтные ключи, вместе с shim'ом, ставьте свои, и
это не совсем та безопасТность которой мы хотим.
> если кому интересно,
> про shim и нерабочий secure boot из каробки: https://habr.com/ru/post/446072/занятная статейка, но 2019го года. С тех пор вроде слуцилась что-то, и вполне возможно что ключи шпион-капитана касперского везде давно заблокированы, а где еще не - достаточно разок загрузить венду поновее любимой многими тут XP, и станет заблокировано, без всякого уведомления щасливых юзеров.
И заметим, оно не про неработающий, secure boot-то вполне работает. Оно про технологическое отверстие, заботливо оставленное фсбшным кротом международного масштаба. (интересно, кто ему подписал загрузчик уже после истории с кражей секретных документов, кто это такой добрый и небрезгливый)
Отдельно прекрасно что афтырь распространяет свой кот с троянцем через Zeronet, чтобы не спалиться раньше времени. (стоит ли запускать его, оттуда скачаный - это вот сами подумайте)
>защищает не от этогоименно от этого, от подмены загрузчика со стороны ОС, что можно прекрасно сделать, блягодаря shim.
рассказы про "злой мс" и "вендорлок", если Вы об этом, оставьте себе.
>что ключи шпион-капитана касперского везде давно заблокированыВы статью читали? ключи майкрософта и их все устраивает. софт касперского, как работал, так и работает.
> и станет заблокировано
галлюцинировать не надо. ключи майкрософта и ими они подписывают собственные драйвера.
>фсбшным кротом
ясненько. не стоило отвечать, вероятно.
>>защищает не от этого
> именно от этого, от подмены загрузчика со стороны ОС, что можно прекрасно
> сделать, блягодаря shim.нет. Вы статью на хабре нашли, прочитали, но так и не поняли? Понадобился не шим, а собственный аналогов не имеющий загрузчик касперского, плюс очень нетривиальный хак к нему, далеко не уровня васяна писавшего бутвирусы, потому что даже этот загрузчик просто так ничего тебе не загрузит.
>>что ключи шпион-капитана касперского везде давно заблокированы
> Вы статью читали? ключи майкрософта и их все устраивает. софт касперского, какСтатья устарела на восемь лет.
>> и станет заблокировано
> галлюцинировать не надо. ключи майкрософта и ими они подписывают собственные драйвера.квалификация эксперта (этогосайта).
Нет, ЭТИМИ ключами microsoft ничего не подписывает кроме васянских шимов.У винды другой ключ. Внезапно, у MS их больше одного. Вот подписали ли они касперскому шим тем же самым или все же пожертвовали отдельный, который и заблокировать недолго - требует выяснения.
А драйверы подписаны третьим (потому что его уже не secure boot а ядро винды проверяет)>>фсбшным кротом
> ясненько. не стоило отвечать, вероятно.не стоило.
Человек потерял огромный бизнес, даже не попытавшись отмазаться - но конечно не крот, никак не крот, это его враги подставили.
>нет.дат. кончайте троллить.
берете shim, берете shell.efi, кидаете в папку на esp, переименовываете в grubx64.efi и шим его загрузит.>устарела
поздравляю, теперь идите учитесь смотреть на что-то, кроме циферок.
шим как умел грузить левые файла, так и умеет.>квалификация экперта
прям с языка сняли.
МС ими драйвера сторонних разработчик подписывает.
не верите - гугл в зубы.
> берете shim, берете shell.efi, кидаете в папку на esp, переименовываете в grubx64.efi и шим его
> загрузит.дай угадаю - secure boot у тебя - выключен.
При попытке загрузить шимом что-то кроме единственноверного grub от rhel (при включеном secure boot а не просто наличии uefi) - внезапно, вылазит окошко и требует... а хрен поймешь на самом деле чего оно требует (не для юзверей там написано, да и вообще непонятно для кого - ашипка "Ашипка").
Если продраться через неюзерфрендли диалог - оно конечно загрузится (и в следующие разы на твоем локалхосте - и только на нем - ничего уже не переспросит). Но тебе двадцать раз придется ткнуть в "OK", лично, с консольки. И никак эту проверку не обойти - все три штуки правильных с точки зрения Secure boot загрузчика - внезапно, подписаны сертификатом, намертво вшитым в shim. shim подписан сертификатом ms, переподписать самому с сертификатом от васяна не получится.
А твои фантазии - просто от того что у тебя есть uefi (и следовательно - shim), но ты не пыталось включить secure boot примерно никогда.
Впрочем я понятия не имею что у тебя там за shell.efi - у меня вон в половину серверов такой встроен в uefi, и он, естественно, подписанный и загружается (и шим не нужен). Только им снова ничего нельзя загрузить кроме подписанных модулей, если он обнаруживает что secure boot включен.
Так, для особо умных, намекаю:
1) В grub было парочку фееричных багов, позволяющих кому попало грузить что угодно, чтоб такие как ты безопасТники не скучали.
2) Ключами майкрософт подписано столько всего интересного - что даже это нафиг не надо. Достаточно посмотреть какое-нибудь изучение чем пользуется малварь.
3) А когда профакапился макйрософт они объяснили что отзывать ключ не будут, это же винда грузииться перестанет! Как можно! И хрен с ними, с вирусами...
> Так, для особо умных, намекаю:
> 1) В grub было парочку фееричных багов,было (ms небось все локти искусала что повелась на вопли шва60дкофанов), но они, как ты правильно выражаешься - специфичны. Требовали несколько странных конфигов и физического доступа к хосту. А зачем нам тогда вообще вся возня, доступ-то уже есть.
Нет, васян с тремя классами образования - вообще ничего не сможет.Ты скорее всего тоже не осилишь, мало умения читать опеннет.
Кто-то конечно сможет, но неуловимые джо ему вряд ли нужны.
Т.е. минимальный уровень защиты технология даже в таком виде все еще обеспечивает.
Ключами microsoft действительно понаподписывали...всякого, драйвер от васянов загружающий через доступный апи любой исполняемый код например. Но опять же - не васян сможет этим воспользоваться, далеко не васян.
Т.е. количество могущих и умеющих действительно в десятки если не сотни раз поубавили. Это тебе не AWARD_SW
Истинно говорю вам: чем хуже, тем лучше. Ибо зло неизбежно пожрет самое себя.
Не в этом дело. Заметил первый раз, когда с Netware на Windows NT переходил. У эти ребят 30 лет делается все наоборот и вопреки здравому смыслу, но продать удалось же. Вот такой критерий - всё делать наоборот как доказательство, что продать можно всё.
А чем Netware лучше и что именно вы заметили? Это интересно...
Кто сказал, что она лучше? В ней (версия 3.12) управление пользователями и ресурсами организовано противоположно Windows NT. И представляется это менее удобным.
> В ней (версия 3.12) управление пользователями и ресурсами организовано противоположно Windows NTпростите, я нетварь не видел, но как подобные вещи вообще можно сделать по-разному?
В одной на ресурсы назначаются пользователи. Открываешь ресурс, и сразу видно, кто к нему имеет доступ. В иной пользователю назначаются ресурсы. Это один из интересующих примеров.
Вся эта фигня, UEFI Secure Boot - один сплошной маразм, палки в колеса для альтернативных ОС в угоду M$
Так UEFI сделали в Microsoft. Там из полезного разве что старт сразу в 64-битность.
Остальное так шум для маркетинга про безопастность
Ну вы что, это же SecureBoot! Вместо того чтобы при установке операционной системы добавить публичный ключ её автора как единственный доверенный, давайте все и сразу доверять нескольким ключам третьей доверенной стороны. И пускай эта сторона подписывает сертификаты любому желающему юридическому лицу, прошедшему через немного бюрократии и заплатившему символическую сумму. Затем каждое из этих лиц будет выпускать свои загрузчики, которым будет доверять все компьютеры с SecureBoot. А потом в некоторых (большинстве) из этих загрузчиков, в том числе выпускаемых той самой доверенной стороной будут находить уязвимости, позволяющие запускать произвольный код. А затем, давайте введем базу данных отозванных загрузчиков, которая будет обновляться через процесс, подобный обновлению UEFI, чтобы на каждом компьютере всегда была самая свежая версия. Всё это кратенько опишем в стандарте на 2800 страниц юридического текста и реализуем этот стандарт под щедрым слоем NDA и IP -- для облегчения аудита. В добавок обеспечим передачу ключей с TPM по незащищенной шине LPC -- чтобы злоумышленник с физическим доступом к компьютеру ни в коем случае не мог использовать микроконтроллер за 4$ в качестве логического анализатора для получения ключей от диска. А, и той самой доверенной третьей стороной конечно же сделаем Microsoft. Вот тогда точно все будет безопасно.
> слоем NDA и IP -- для облегчения аудита. В добавок обеспечим
> передачу ключей с TPM по незащищенной шине LPC --ТАм давно уже SPI и I2C в почете, если вы так то не заметили. И кстати шифрование шины для TPM таки сделали.
...но вообше, если злыдень вам МК на шину развешивает - у вас, таки, нефиговые проблемы в системе. И ниакой секурьут вас уже таки - не спасет.
> ТАм давно уже SPI и I2C в почете, если вы так то не заметили. И кстати шифрование шины для TPM таки сделали.На последнем железе он интегрирован прямо в процессор. Но сам факт что такие дырявые системы с незащищенной шиной продавались и продаются как "Secure"Boot, говорит многое об этом театре безопасности. Как они интересно до установки защишенного канала между процессором и TPM производят обмен ключами? Вряд ли конечно, но не удивлюсь если в плейнтексте при каждом включении.
> ...но вообше, если злыдень вам МК на шину развешивает - у вас, таки, нефиговые проблемы в системе. И ниакой секурьут вас уже таки - не спасет.
Так весь смысл SecureBoot в защите от физических атак. Он сам по себе должен защищать от незаметной для владельца подмены загрузчика. А в связке с TPM должны защищать от добычи данных с украденного устройства. Со вторым сценарием как раз таки и не справляется.
> Так весь смысл SecureBoot в защите от физических атак.нет смысла. против физических атак только физическая защита:
охранники, СКУДы, замки + ключи, железные двери,
бумажные журналы доступа. и видеонаблюдение разумеется.ps: есть такое суперзащищенное электронное голосование, на котором всегда выберут кого надо.
чем-то напоминает SecureBoot, не правда ли ?
>весь смысл SecureBoot в защите от физических атакта ты шо?
от физ. атак защищают технологии, вроде intel boot guard. а sb сбивается перепрошивкой платы.
> Так весь смысл SecureBoot в защите от физических атак.Не хочу вас расстраивать - но эта проблема не имеет эффеквтивного решения. Просто подумайте о том что например шина RAM доступна атакующему - и он может попытаться сбить чтение битика в нужный момент, радикально изменив смысл кода (например инвертнуть условие какой-нить проверки).
Постоянно верифицировать код в рантайме вы не сможете - постоянно хешировать код, сверяя с хешами, что он не изменился - слишком дорогая операция в рантайм. А даже если - есть окно возможностей, пока проверки еще не заметили подмену, потому что это не мгновенно.
И вот тут атакуюший всегда может взять свое. Это можно сделать относительно канительно, но полного решения эта проблема не имеет. Мелкие вещи типа МК и смарткарт в этом чуть лучше т.к. вся память внутри чипа и вот эти шины уже атакующему почти недоступны. Но даже так - варианты есть.
> Он сам по себе должен защищать от незаметной для владельца подмены загрузчика. А в
> связке с TPM должны защищать от добычи данных с украденного устройства.
> Со вторым сценарием как раз таки и не справляется.В основном оно защищает от "софтварных" атак когда софт попытался нахрапом заменить загрузчик через баг. Если это именно физический доступ к системе - оно не удержится при серьезном настрое атакующего. Потому что можно например пройти все проверки хешей но потом все равно сбить код в памяти на иной, делающий что надо - цепочка secureboot как бы пройдена, но как бы толку от этого немного.
господи, сколько же админов локалхостов в комментах не имеют ни малейшего понятия, что такое Secure Boot и как им пользоваться.
Вчера впервые увидел Windows 11.
Полчаса с помощью гугля убеждал ноутбук, что мне не уcpалось регистрироваться в Майкрософт.
В гробу я видал этим еще и пользоваться...
Полчаса? У меня для вас плохие новости. Возможно, лучше вам всё же зарегистрироваться да пользоваться.
Прошу прощения за оффтоп :)
На самом деле дел минут на 15-20. Первым делом в биос сетапе рубим сетевые интерфейсы (шланг с вафлей или только вафлю, по железу, у нормальных ноутов это есть). Вторым делом при запуске сего поделие монстрософта жмём SHIFT-F10 и пишем OOBE/BYPASSNRO (прям вот капсом без пробелов). апапарат ребутается и можно уже дальше в процессе создать админа локалхоста :).
Кстати, всех причастных - поздравлямс!!! :)
Ну естественно, я все это с бубном отплясал, поставил сотруднику на этот ноут рабочие программы, отдал и забыл, как страшный сон. Но кто-то же имеет этот зонд за свои же деньги...
> Ну естественно, я все это с бубном отплясал, поставил сотруднику на этот
> ноут рабочие программы, отдал и забыл, как страшный сон. Но кто-то
> же имеет этот зонд за свои же деньги...1. 95% не в курсе, что это зонд :)
2. Есть вероятность, что некоторые получают физическое удовольствие при использовании "сервисов Microsoft" :D.
Я мазохист, но даже как мазохистскую практику я бы предпочёл использовать это в виртуалке.
И не понятно где там стоп-слово.
alt+f4 же (;
> Вчера впервые увидел Windows 11.админы локалхоста в тредике, как и было сказано.
> господи, сколько же админов локалхостов в комментах не имеют ни малейшего понятия, что такое Secure Boot и как им пользоваться.А это говорит о secure boot, а не местной аудитории. Есть много вещей посложнее с которыми ни у кго проблем нет, а тут мутная дырявая технология - разбираться в ней уважающий себя администратор не обязан, такое можно полностью игнорировать.
>> господи, сколько же админов локалхостов в комментах не имеют ни малейшего понятия, что такое Secure Boot и как им пользоваться.
> А это говорит о secure boot, а не местной аудитории. Есть много
> вещей посложнее с которыми ни у кго проблем нет, а тут
> мутная дырявая технология - разбираться в ней уважающий себя администратор не
> обязан, такое можно полностью игнорировать.это как раз говорит об "уважающих себя" админах, не осиливших мануал по Secure Boot на 2 листа а4 крупным шрифтом или пол листа мелким
Ха-ха, а я всегда говорил, что Secure Boot это Тивоизация + иллюзия безопасности для интересующихся юзеров. Никакие спецслужбы он останавливать не должен, для них всегда есть отдельный вход.
Это было очевидно с самого начала. Помните, когда оно только появилось, пошли ноуты без возможности отключения сесуре бута? Все взвыли и опцию таки завезли.
> Это было очевидно с самого начала. Помните, когда оно только появилось, пошли
> ноуты без возможности отключения сесуре бута? Все взвыли и опцию таки
> завезли.Ну так не стоило Балмеру и компании так подозрительно хихикать и умиляться. Хитрый план сделать Виндовс единственной ОС которую можно запускать на ПК оказался слишком уж очевиден.
> Закрытая часть тестового ключа AMI, необходимая для создания цифровых подписей, оказалась доступна публично после утечки информации у одного из производителей оборудования, сотрудник которого по ошибке разместил в публичном репозитории на GitHub код, содержащий данный ключ. Закрытый ключ был размещён в зашифрованном файле, при шифровании которого использовался простой 4-символьный пароль, который удалось легко подобрать методом перебора.так где скачать-то? друг просил...
можешь скачать shim-signed из реп своего дистрибутива и, блягодаря поитике подписывания загрузчиков майкрософта, грузить им, шо угодно, на любых девайсах, т.к. на 99% машин в db есть ключ МС.
https://archive.org/details/aaeon-uefi-firmware-git-repos(Лучше скачать через Torrent, но можно и wget'ом)
wget https://archive.org/download/aaeon-uefi-firmware-git-repos/R...
mkdir Ryzen2000_4000
cd Ryzen2000_4000/
unzip ../Ryzen2000_4000.git.zip
mv Ryzen2000_4000.git .git
sed -i '/\bbare *= *true\b/d' .git/config
git reset -q -- .
git checkout -- .
cd Keys/FW/AmiTest/
openssl pkcs12 -in FW_priKey.pfx -nocerts -nodes -out FW_priKey.pem -passin pass:abcd
git statusКод выше можно целиком скопипастить прямо в терминал, убедившись, что ссылка на zip правильная (OpenNet может её неправильно отобразить).
На выходе получится Keys/FW/AmiTest/FW_priKey.pem , это и есть PK.key из текста новости.
Если будете ковыряться вручную, то пароль от FW_priKey.pfx – abcd . PFX (он же .p12) можно, например, открыть в xca.
Дальше по инструкции отсюда: https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
В ней надо пропустить только первую команду после создания GUID, то есть генерацию новых PK.crt и PK.key . Вместо них следует использовать Keys/FW/AmiTest/FW_pubKey.cer и свежесозданный Keys/FW/AmiTest/FW_priKey.pem .
Для проверки того, что всё сгенерировалось правильно, можно использовать sbkeysync с опцией --dry-run, как описано здесь: https://wiki.archlinux.org/title/Unified_Extensible_Firmware... . Каталог вместо /etc/secureboot/keys/ может быть любым.
Более простой вариант использования описан в тексте новости, но работать он будет только на тех компьютерах, где этот тестовый ключ считается доверенным с завода, либо если добавить этот тестовый ключ себе в UEFI, как описано по ссылке выше.
Удачи.
>не обратили внимание на предупреждениеСами, или их настоятельно попросили?
зачем просить "не замечать", когда можно попросить ключ..?
Кучно пошло. В Phoenix бэкдор в коде, у AMI бэкдор в корнях.
Вы что-то кроме заголовка читаете?
https://www.linux.org.ru/forum/security/17682542?cid=17685158Ещё раз напомню 3 базовых аксиомы Integrity:
1. Все перед запуском должно верифицироваться по цифровой подписи с использованием публичного ключа.
2. Использование чужих публичных ключей для верификации системы неприемлемо.
3. Наличие секретных ключей в рабочей системе недопустимо.
Теорема о ключах Integrity.
Систему Integrity возможно реализовать на компьютере конечного пользователя или в конечном административном домене только в случае создания всех ключей используемых для Integrity на компьютере конечного пользователя или в конечном административном домене.
То есть полная верификация системы в процессе загрузки возможна только в случае когда все ключи: Intel Boot Guard, Secure Boot, GRUB, Linux IMA/EVM - создаёт конечный пользователь (администратор) системы.
Доказательство:1. Ключи IMA/EVM. Пользователь (админ) установил GNU/Linux на свою машину. После установки ВСЕГДА необходимо настроить систему GNU/Linux иэизменив файлы настроек в /etc/. После из мнения файлов в /etc/ их необходимо заново переподписать, а значит конечному пользователю необходимо иметь приватные ключи IMA/EVM для создания новой подписи. Следовательно ключи IMA/EVM должны создаваться на компе конечного пользователя.
2. Ключи GRUB. Свои созданные ключи IMA/EVM пользователь вынужден добавить в ядро Linux и/или initrd в зависимости от конкретной реализации IMA/EVM в конечной системе. А значит ядро Linux и initrd будут ВСЕГДА изменены конечным пользователем в процессе установки. Также в процессе установки системы будет изменён конечным пользователем файл /boot/grub/grub.cfg. Изменённые ядра, initrd, файл настроек загрузчика необходимо подписать приватным ключом GRUB в процессе установки, а значит конечному пользователю необходимо иметь приватные ключи GRUB для создания новых подписей. Следовательно ключи GRUB должны создаваться на компе конечного пользователя.
3. Ключи Secure Boot. Свои созданные ключи GRUB пользователь вынужден добавить в начальный загрузчик GRUB - core.img. А значит core.img будет ВСЕГДА изменён конечным пользователем системы в процессе установки. Измененный core.img необходимо подписать приватным ключом Secure Boot в процессе установки, а значит конечному пользователю необходимо иметь приватные ключи Secure Boot для создания новой подписи. Следовательно ключи Secure Boot должны создаваться на компе конечного пользователя.
4. Ключ Intel Boot Guard. Свои созданные ключи Secure Boot пользователь вынужден добавить в UEFI. А значит общее содержание UEFI ВСЕГДА будет изменено конечным пользователем во время установки системы. Измененные части UEFI необходимо подписать приватным ключом Intel Boot Guard в процессе установки, а значит конечному пользователю необходимо иметь приватный ключ Intel Boot Guard для создания новых подписей. Следовательно ключ Intel Boot Guard должен создаваться на компе конечного пользователя.
Linux IMA/EVM.
https://sourceforge.net/p/linux-ima/wiki/Home/
https://ima-doc.readthedocs.io/en/latest/index.html
https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
https://wiki.gentoo.org/wiki/Extended_Verification_Module
Лично мне пришлось чуть править файл: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... По умолчанию реализована классическая политика TCB. Она для GNU/Linux не подходит. Много изменяемых файлов в TMP, LOG, … пишутся под пользователем root. Это надо разрешить правилами. А все что мапится в память для исполнения - проверять. В системах с initrd надо позаботится о XATTR атрибутах с подписями или подкорректировать для его запуска правила.
GRUB2.
https://www.gnu.org/software/grub/manual/grub/grub.html#Usin...
UEFI Secure Boot
Матплата должна поддерживать удаление всех чужих ключей Secure Boot и добавление своего публичного ключа Secure Boot. А ещё лучше поддерживать libreboot, coreboot.
https://habr.com/en/post/273497
Security Boot и подпись загрузчика Windows (комментарий)
Intel Boot Guard
Если матплату и проц покупать раздельно, то пользователь будет иметь возможность единожды прописать ключ Intel Boot Guard в спец область ROM где-то в IntelME. Отключить Intel Boot Guard или изменить его ключ физически будет невозможным. Это безоткатная операция. По этому терять ключ Intel Boot Guard нельзя. Информации о том как закрытый, проприетарный IntelME проверяет целостность UEFI и ключей Secure Boot почти нет.
https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard
Никаких технических проблем для поддержки по умолчанию Integrity в Linux IMA/EVM и GRUB2 - во всех дистрибутивах GNU/Linux не существует! Надо просто чуть подправить инсталлер каждого дистрибутива.
Поддержка Secure Boot и Boot Guard зависит от производителя железа. Возможна опциональная поддержка для конкретного железа.
на кой вообще в цепи гроб, в котором уязвимость, позволяющая обойти верификацию - "обычный понедельник" ?
что по ima, в линуксе по дефолту запрещен ввод кастомных политик в ранатйме, следовательно, остается 2 варианта из дефолтных:
верифицировать всю фс, включая временные файлы с логами или
верефицировать только исполняемые файлы. так что, мне не ясно, что там автор про верификацию /etc затирает.
3й ненужен, ибо он был добавлен еще до появления sb.
по поводу iBG... автор там какого чая напился? свои ключи зашить можно было в полтора устройства из "бракованных" партий. по дефолту там кореновй ключ интела в пзу.
1. У меня старый GRUB2 до "обновлений безопасности" верифицирует все при загрузке и ЭКСПЛУАТИРУЕМЫХ уязвимостей не имеет.2. Все зависит от настроек IMA. Есть возможность вводить политику IMA в рантайме единожды. При этом политика обязательно должна быть подписана ключом с ядерного кэйринга. Есть возможность вообще запретить изменения политики IMA в рантайме.
3. Изучите внимательно документацию по настройке политик IMA. Я сумел настроить IMA чтобы он верифицировал файлы пользователя root в /etc и не верифицировал изменяемые файлы пользователя root в /tmp, /var/log, ... это просто. Чуть сложнее обеспечить верификацию содержимого initrd в IMA, но если чуть помучатся это тоже реализуемо. Да я не использую дефолтную политику TCB поскольку она для дефолтного GNU/Linux не подходит. Надо всем в Linux чуть править политику IMA по умолчанию.
4. Использование GRUB2 в цепочке загрузки нужно в случае необходимости скрыть содержимое модулей GRUB, настроек, ядра и инитрд. Только GRUB2 умеет на сегодня проводить верифицированную загрузку с шифрованного раздела. Прошивки UEFI пока не умеют грузить ядра с шифрованных разделов. Кроме этого GRUB2 обеспечивает верификацию ядра и инитрд в системах без Secure Boot.
5. Ключ Intel Boot Guard можно добавить в область ROM в IntelME только когда процессор соеденен с материнской платой. Если купить материнку отдельно от процессора, то пользователь будет иметь возможность самостоятельно установить свой публичный ключ Intel Boot Guard в область ROM в IntelME. Это описано в документации Intel и надо знать всем.
1. поздравляю, завтра будет. не завтра - так послезавтра, или тогдач когда Ваше 6е чувство Вас подведет и Вы забудите о новой уязвимости.
>старыйтем более. значит уже есть.
зачем тебе этот пережиток прошлого, когда у ядра есть efi-stub, или вообще uki можно использовать?
2. ага. только вот не от "настроек", а от параметров сборки ядра. я это прочла именно из документации после того, как день убила на попытку это сделать.
в дебиане и альпайне оно запрещено. или вообще по дефолту в линуксе, ибо в дебиановскрм треккере патчей ничего о намеренном включении сей фишки нет.
3. ну, я-то поправила, даже подписала. а при попытке загрузить - ошибка в klog, говорящая "низя". и не из за несоответствия подписи.
зачем measured boot в нем в ключать - я без понятья. Вы ж сами про настройку sb выписывали.
4. зачем шифровать /boot, если у Вас sb включен, м? esp все так же расшифрован, это ничего не дает.
и да, у Вас __система с sb__, на кой черт конкретно в вашем случае гроб?
4. а, Вы об этом? тогда ладно, но никто так задуряться не будет, особенно, если ноутбук(а вне контекста ноутбуков, мне вообще не ясно, на кой вся эта котовасия)
1.
> > старый
> тем более. значит уже есть.Или наоборот, в старом не было, а в новых появились.
2. IMA включается при настройке ядра и ее ключи также. В дистрибутивах с бинарным ядром Linux поддержки IMA не бывает. В Gentoo пробовали ковырять IMA.
3. У меня в 2 этапа проходит установка и обновление. Сначала грузимся в режиме с отключенным apperise, в котором, IMA/EVM подписывает файлы, а потом перезагружаюсь в рабочий режим apperise в котором IMA/EVM блокирует изменения и проводит проверки. Очень важно понять что это два совершенно разных режима и вам надо для них написать ДВЕ РАЗНЫЕ политики IMA. Одна политика IMA для установки и обновления создающая подписи и совсем другая политика IMA защищающая подписи от изменений, проводящая проверки и блокировки. И мне пришлось править дефолтную политику IMA в ядре Linux чтобы это реализовать.
4. /boot шифрую для скрытия ядра и инитрд, настроек GRUB. Мне надо простое универсальное решение, работающее везде с верификацией загрузки. Не шифрованым в GRUB есть только core.img
3. прикольно. возможно, будет попытка номер 2, но не на десктопе.
ибо я как то решила, что оно мне не надо, т.к уже
iBG -> sb,tpm+пароль(не пин, а кусок пароля люкса) -> luks -> tomoyo linux(с политикой на всю систему) -> LKRG.
> по дефолту там кореновй ключ интела в пзу.1. Купив проц и мамку раздельно пользователь будет иметь возможность добавить СВОЙ ЛИЧНЫЙ публичный ключ Intel Boot Guard в ROM область в IntelME, для верификации UEFI (LibreBOOT, CoreBOOT) и СВОИХ ЛИЧНЫХ ключей Secure Boot. Включенный единожды Intel Boot Guard отключит физически невозможно.
2. Если купили готовый ноут, то ИМЕННО производитель ноута прописывает СВОЙ ЛИЧНЫЙ публичный ключ Intel Boot Guard в ROM область в IntelME, для верификации СВОЕЙ ноутбучной прошивки UEFI и ключа Микрософт для Secure Boot. Производитель ноутов при этом может безопасно обновлять свою прошивку UEFI, а компания Микрософт может безопасно обновлять неизменяемые в процессе работы бинари, библиотеки и структуры MS Windows. В этом случае в общем установка GNU/Linux возможна при отключённом Secure Boot. Возможность верификации загрузки системы с помощью GRUB и Linux IMA/EVM все равно необходимо использовать.
3. IntelME - закрытый бинарный блоб в котором теоретически могут находится ещё и ключи Intel, NSA, ... которые также могут использоваться для верификации инженерных прошивок и буткитов в UEFI. Здесь пользователь покупая проц Intel должен полностью доверять блобу IntelME.
1. Вы ж написали уже это
2. действительно. в памяти почему-то отложилось, что корень от интел
> 2. действительно. в памяти почему-то отложилось, что корень от интелНастоящий корень - ключ ME boot ROM - и правда от Intel. Он с самого начала с фабрики прописан в фьюзы, и индеец ни при каком раскладе не сможет свой, доверяемый софт в ME протолкать. И обречен жить с блобом в ME подписаным интелом.
А бутгад - это типа 9 фуфлоколец гномам, так, вторичные ключи и вспомогаловка. Можно раздать индейцам для иллюзии контроля. Ведь имея доступ в ME - остальное уже не важно! Это самый привилегированый компонент системы. Настолько что x86 вообще его кишки не видит - а вот наоборот очень даже.
> Настоящий корень - ключ ME boot ROM - и правда от Intel.Да скажем правду - секретный ключ от IntelME есть в майора с АНБ.
> А бутгад - это типа 9 фуфлоколец гномам, так, вторичные ключи и вспомогаловка.
Он ОЧЕНЬ много даёт пользователю компа:
1. Физически неизменяем, никакой Васян не сможет его изменить.
2. Проверка UEFI и Secure Boot с помощью вашего ключа становится не отключаемой. Никакой производитель не сможет сменить прошивки UEFI и добавить ключ Secure Boot от M$.
3. У нас нет выбора. В DNS за углом Эльбрусу без IntelME пока не продают.
>> Настоящий корень - ключ ME boot ROM - и правда от Intel.
> Да скажем правду - секретный ключ от IntelME есть в майора с АНБ.Как минимум он есть у "богов" из интеля. Кому и на каких условиях они это дают - и что еще им подписано - неизвестно. Это означает что сколь-нибудь доказуемой и ожидаемой безопасности с таким раскладом не видать.
То-есть можно сформировать себе ложные ожидания. И потом залететь на это при случае. А вот именно гарантий - в этой схеме по нулям. Утечет эта пакость или что-то ей подписаное у интеля или кого там - и упс, вся схема бита.
>> А бутгад - это типа 9 фуфлоколец гномам, так, вторичные ключи и вспомогаловка.
> Он ОЧЕНЬ много даёт пользователю компа:
> 1. Физически неизменяем, никакой Васян не сможет его изменить.У меча две стороны...
1) Легитимный пользователь его тоже не сможет потом перешить. Даже если про@#$л, или он оказался несекурный, или что там еще.
2) Если пользователь утратил приватную часть нужного ключа - он немного в з@днице.
3) Любые ошибки при программировании eFuse - фатальны.
4) Зачастую это уже прописано без пользователя, и вот совсем уж ой.> 2. Проверка UEFI и Secure Boot с помощью вашего ключа становится не
> отключаемой. Никакой производитель не сможет сменить прошивки UEFI и добавить ключ
> Secure Boot от M$.И это круто - потому что что? За вами бегала толпа производителей, пытаясь отжать самопальный комп и прописать в него свои ключи? Очень странная модель угроз, я бы сказал. С точки зрения пользователя это либо вестма рисковая в програмировании фича с 1 стороны (у вас же нет склада железа на убой для отладки/проверки?) - либо оно вообще уже прописано более массовыми, которые отладились, и оно против пользователя играет.
> 3. У нас нет выбора. В DNS за углом Эльбрусу без IntelME пока не продают.
1) Я могу купить ARM какойнить с ванильными фьюзами. И там по крайней мере это реально топовая ауторити. Но это смотреть надо кто как секурбут делает, варианты разные бывают.
2) Есть способ лучше. Загрузчик - коему прописан некий ключ владельца - кладется на read only media. Ну там SPI флеха с WP#, SD карта которую в загнали в readonly, или что там уместно в энной системе. Актуально для систем чей бутром умет с таких носителей стартить (ARM/RISCV). Это гугл придумал - хотя идея очевидная. Если ну вот очень приперло - readonly загрузчика вот там все же можно физическими манипуляциями оверрайднуть. Но софт это сделать сам по себе не сможет - в чем смысл и состоит.
Против вот именно физического доступа это фуфло не удержится. В здоровенном x86-64 более 9000 векторов атак. Включая весьма универсальные типа power/clock glitching или рантайм патчинга кода сбоем на шине например DRAM в нужный момент. Если уж доступ - физический.
>>> Настоящий корень - ключ ME boot ROM - и правда от Intel.
>> Да скажем правду - секретный ключ от IntelME есть в майора с АНБ.
> Как минимум он есть у "богов" из интеля. Кому и на каких условиях они это дают - и что еще им подписано - неизвестно. Это означает что сколь-нибудь доказуемой и ожидаемой безопасности с таким раскладом не видать.Интел при производстве чипов засовывает в них целого товарища майора с АНБ, причем живьём!
> То-есть можно сформировать себе ложные ожидания. И потом залететь на это при случае. А вот именно гарантий - в этой схеме по нулям. Утечет эта пакость или что-то ей подписаное у интеля или кого там - и упс, вся схема бита.
И если товарищ майор АНБ сбежит с чипа интела то может всем рассказать что в IntelME у вас на компе творится.
1. Публичный ключ Intel Boot Guard физически неизменяем. Он есть корнем вашего доверия.
Это значит, что прописывать его надо очень аккуратно и приватную часть хранить очень надёжно. Если потеряете приватную часть ключа то обновления UEFI будут невозможны.
2. Проверка UEFI и публичных ключей Secure Boot с помощью вашего ключа становится не отключаемой. Это безответная операция! Она даёт гарантию отсутствия бутктов в вашей UEFI. Да буткит в UEFI могут засунуть и производители прошивки, например ASUS. Буткит в ваш UEFI желают прописать многие, озаботился охраной UEFI стоит каждому пользователю.
3. У нас нет выбора. В DNS за углом Эльбрусы без IntelME пока не продают.
Стоит смотреть:
Secure Boot в сертифицированном FSF железе: https://www.raptorcs.com/
"Talos™ II drives the state of the art of secure computing forward. Talos™ II gives you — and only you — full control of your machine's security. Rest assured knowing that only your authorized software and firmware are running via POWER9's secure boot features. Don't trust us? Look at the secure boot sources yourself — and modify them as you wish. That's the power of Talos™ II"
> В здоровенном x86-64 более 9000 векторов атак.
Наличие других векторов атак не значит, что не надо настраивать Integrity.
> причем живьём!Накаркаете.
> И если товарищ майор АНБ сбежит с чипа интела то может всем
> рассказать что в IntelME у вас на компе творится.Название Management Engine намекает что оно создано МЕНЕДЖИТЬ КОМП. Умея все, от включения и заканчивая реинсталом оси, ремотно в полной версии задумки ;)
> 1. Публичный ключ Intel Boot Guard физически неизменяем. Он есть корнем вашего доверия.
Причин доверять такой системе - нет. Потому что интел и неопределенный кругом лиц и подписаного софта - могут обойти это сбоку, через ключ ME и софт на самом привилегированом проце системы. У ME привилегий больше чем у x86 ядер. Они вас - видят, а вы их - нет. Это надежный детектор. Когда кто-то косплеит бога, 1 из 1х вещей приходящих в голову - жить в отдельном измерении, где богов не видно смертным. В обратную сторону, конечно, влиять могут. Характерный паттерн, при первом намеке на это - вся схема как на ладони.
> Это значит, что прописывать его надо очень аккуратно и приватную часть хранить
> очень надёжно. Если потеряете приватную часть ключа то обновления UEFI будут невозможны.А еще это значит что с вот этим процом у вас 1 выстрел. И если что не так - ну, вы меняете проц. Примерно такая же проблема есть с ARM, но там такие эксперименты дешевле :)
> 2. Проверка UEFI и публичных ключей Secure Boot с помощью вашего ключа
> становится не отключаемой. Это безответная операция!Спасибо капитан очевидность. Но это бусы для индейцев. Формальная декларация. Ибо есть еще проц ME с отдельным ключом. Более мощный по правам. И индейцев туда вообще пускать не собираются. У вас нет контроля над платформой, вы - в гостях. Кольца - фуфло, типа того что гномам раздали.
> Она даёт гарантию отсутствия бутктов в вашей UEFI. Да буткит в UEFI могут
> засунуть и производители прошивки, например ASUS. Буткит в ваш UEFI желают
> прописать многие, озаботился охраной UEFI стоит каждому пользователю.Никаких реальных гарантий чего либо это не дает, ессно. Потому что настоящий root of trust зарезервирован Intel (и AMD) для себя. С самыми мощными привилегиями в платформе. Какая неожиданность. ФакЪ, вам даже нормальный дебаг - не дадут, и не скажут как реально врубить platform level debug. Но если индеец любопытный, найдет некоторые подробности у позитивов. Только это - индейцы-повстанцы, а никак и не официалы вовсе. Ну такая вот "доверяемая" платфрма вырисовывается. Где все на дуле пистолета, "доверяй, а нето грузиться не будем".
> 3. У нас нет выбора. В DNS за углом Эльбрусы без IntelME пока не продают.
Это, несомненно, забойный аргумент за безопасность платформы и доверие к ней.
> Стоит смотреть:
> Secure Boot в сертифицированном FSF железе: https://www.raptorcs.com/Ну как бы ваша платформа или нет - определяется прежде всего доступом к наивысшему уровню привилегий. Имея этот доступ - можно остальных своим софтом оттуда выпереть, сделав им достаточно неудобно как минимуму, особенно при ремотном/софтварном доступе. А если индейцу отдают на откуп менее привилегированый проц, совсем не пустив в более привилегированый... больно уж характерный паттерн. Ни в раз не уникальный для интела и амд.
>> В здоровенном x86-64 более 9000 векторов атак.
> Наличие других векторов атак не значит, что не надо настраивать Integrity.Если некто защищается от именно ФИЗИЧЕСКОГО ДОСТУПА, странно перекрыть 10 векторов из более 9000 а на остальные - забить. Если бы они сказали что - от софта пытающегося флешить в фирмвари левак, это другой вопрос уже был бы.
а, ну вот.
в любом случае, неплохая защита. ни Вам, ни мне явно дело с анб иметь не придется. максимум - участковый дядя Гриша и условный отдел к, которым силенок и не хватит. особенно, учитывая, что интел из рф ушел, да настолько, что даже доки почитать не дает.
> 1. Купив проц и мамку раздельно пользователь будет иметь возможность добавить СВОЙ
> ЛИЧНЫЙ публичный ключ Intel Boot Guard в ROM область в IntelME,Однако ему никогда не дадут прописать свой МАСТЕР ключ - который ME boot ROM использует для начальной верификации блоба ME. Поэтому вы будете жрать интеловский блоб. Без особой возможности его заменить. На side by side проце.
А если вы решите что умная клава и не дадите этот блоб, тогда через полчаса ME boot ROM выклбчит комп по таймауту. Ибо нехрен.
> для верификации UEFI (LibreBOOT, CoreBOOT) и СВОИХ ЛИЧНЫХ ключей Secure Boot.
> Включенный единожды Intel Boot Guard отключит физически невозможно.Видишь ли, дорогой индеец, верховные божества зарезервировали самый крутой ключ - себе. А ты в _ИХ_ системе сможешь не более чем они тебе милостиво позволят.
Как ты будешь верифицировать что там ME boot rom и его blob делает в конкретной железке и конкретной версии - это такой весьма отдельный вопрос.
> верификации СВОЕЙ ноутбучной прошивки UEFI и ключа Микрософт для Secure Boot.
СВОЕ оно - только для компании Intel. Ну или AMD. А вы там - в гостях. Ибо самый мощный ключ, внезапно, не ваш.
В этом смысле ARM бывают честнее - root ключ secureboot с фабы вообще не вписан бывает, кто пропишет - тот и system owner. Но в x86-64 owner уже прям с фабы жестко заколочен.
> GNU/Linux возможна при отключённом Secure Boot. Возможность верификации загрузки системы
> с помощью GRUB и Linux IMA/EVM все равно необходимо использовать.Чтобы выглядеть умным индейцем, правильно камлающим ритуалы?
> 3. IntelME - закрытый бинарный блоб в котором теоретически могут находится ещё
> и ключи Intel, NSA, ...Это закрытый бинарный блоб. Ему нафиг не упали ключи. Он крутится на отдельном процессорном ядре, side by side с вашей ОС, умеет DMA, и если вдруг захочет - может все отменеджить в хвост и в гриву. Сможет ли конкретная версия так, особенно после neutering - ну это такой интересный вопрос. Факт в том что совсем не запускать это - вы таки не сможете, под страхом вырубания компа через полчаса.
Есть еще флаги для анб которые якобы-совсем, якобы-отключают. Но самое интересное что вы таки не сможете проверить что именно бутром ME конрктетной ревизии делал так по простому. Потому что x86 он вообще недоступен. Боги дивут в отдельном измерении. Оттуда они могут управлять смертными, но вот смертным их не видно. Это привилегии богов :).
> А если вы решите что умная клава и не дадите этот блоб, тогда через полчаса ME boot ROM выклбчит комп по таймауту. Ибо нехрен.
> СВОЕ оно - только для компании Intel. Ну или AMD. А вы там - в гостях. Ибо самый мощный ключ, внезапно, не ваш.А что делать? Эльбрусу в DNS за углом пока не привезли.
> В этом смысле ARM бывают честнее - root ключ secureboot с фабы вообще не вписан бывает, кто пропишет - тот и system owner.
К ARM у меня другие вопросы по безопасности. Отсутствие инструкции NX. Как выделять память только для чтения в режиме исполнения и с запретом исполнения в режиме записи?
А что там ковбои с IBM наделали? Как у них Secure Boot в сертифицированном FSF железе: https://www.raptorcs.com/
"Talos™ II drives the state of the art of secure computing forward. Talos™ II gives you — and only you — full control of your machine's security. Rest assured knowing that only your authorized software and firmware are running via POWER9's secure boot features. Don't trust us? Look at the secure boot sources yourself — and modify them as you wish. That's the power of Talos™ II"
> > GNU/Linux возможна при отключённом Secure Boot. Возможность верификации загрузки системы с помощью GRUB и Linux IMA/EVM все равно необходимо использовать.
> Чтобы выглядеть умным индейцем, правильно камлающим ритуалы?С детства уважаю всех индейцев. Даже лук и стрелы себе был сделал. Но к индейцам никак не отношусь.
А верификацию в GRUB и Linux IMA/EVM необходимо делать чтобы всякий Васян не вставил буткит в модуль GRUB, или руткит в ядро, или всякую вирусную в бинари и либы.
> Сможет ли конкретная версия так, особенно после neutering - ну это такой интересный вопрос
У нас нет альтернатив. Максимум что можем это прописать свой ключ в Intel Boot Guard и аккуратно обрезать IntelME с опцией -s.
Позировали 5 шведов зелени на завод в свои времена. Сегодня могли бы RISC-V без блоков клепать.
/Позировали 5 шведов/пожидничали 5 лярдов/
> А что делать? Эльбрусу в DNS за углом пока не привезли.Это не является валидным аргументом в безопасности компьютерных систем. Да и даже если привезут - у них что, открытый системный уровень? Да там даже компилер проприетарный, поди проверь что он там нагенерил и почему.
> К ARM у меня другие вопросы по безопасности. Отсутствие инструкции NX.
А зачем для этого вообще какие-то инструкции? А, потому что у x86 урода изначально вообще не было запрета выполнения как категории? Ну так это его родовые костыли, странно другим в претензию это ставить :)
А у ARMов и прочих более новых дизайнов - MMU сразу с правами R, W и X на страницы. И вот тут - если X не разрешен, вы и пролетаете с выполнением кода оттуда.
> Как выделять память только для чтения в режиме исполнения и с запретом
> исполнения в режиме записи?Правами страниц через MMU, внезапно. А вы что подумали? Такой набор правил в целом даже характерное название "W^X" получил. Нормально такое через MMU ессно делается.
> А что там ковбои с IBM наделали?
Я никогда не имел дел с этим железом. Но имею неплохое представление как сделать относительно мелкие "апликушные" ARM вполне секурными. Кстати даже для TrustZone так то есть открытый ARM trusted firmware, в отличие от tianocore открытость менее фэйковая.
>> Чтобы выглядеть умным индейцем, правильно камлающим ритуалы?
> С детства уважаю всех индейцев. Даже лук и стрелы себе был сделал.
> Но к индейцам никак не отношусь.Ну тогда присоединяйтесь к раздаче одеял "нашару". Хотя не, шара не в моде - клевые одеяла от доброго человека еще и оплатить теперь придется :)
> А верификацию в GRUB и Linux IMA/EVM необходимо делать чтобы всякий Васян
> не вставил буткит в модуль GRUB, или руткит в ядро, или всякую вирусную в бинари и либы.Тут скорее актуально "чтобы самоходное ПО от Васяна это не сделало". При такой постановке вопроса это еще понимаемо.
А защита x86 гроба от физического доступа - ну, э, лол. От этого даже МК с всей памятью и системой в кристалле может не удержаться. И не то чтоб как-то сильно сложно ведь, примеры power или clock glitching можно найти у исследователей. Никакой ракетной науки.
> У нас нет альтернатив. Максимум что можем это прописать свой ключ в
> Intel Boot Guard и аккуратно обрезать IntelME с опцией -s.
> Позировали 5 шведов зелени на завод в свои времена. Сегодня могли бы
> RISC-V без блоков клепать.Не знаю что за шведы - а RISCV уже так то довольно много кто клепает. Да и ARM тоже. Вон там фороникс AWSовкие Graviton затестил - а они даже и EPYC местами делают. Ну а чего 128 ядерному монстру не? Правда, амазон вроде это только as service продает. Почти как Эльбрус :)) но есть нюансы. А в виде железок вроде не, "такая скотина нужна самому!"
>> К ARM у меня другие вопросы по безопасности. Отсутствие инструкции NX.
> А зачем для этого вообще какие-то инструкции? А, потому что у x86 урода изначально вообще не было запрета выполнения как категории? Ну так это его родовые костыли, странно другим в претензию это ставить :)
> А у ARMов и прочих более новых дизайнов - MMU сразу с правами R, W и X на страницы. И вот тут - если X не разрешен, вы и пролетаете с выполнением кода оттуда.
>> Как выделять память только для чтения в режиме исполнения и с запретом исполнения в режиме записи?
> Правами страниц через MMU, внезапно. А вы что подумали? Такой набор правил в целом даже характерное название "W^X" получил. Нормально такое через MMU ессно делается.Правда в том что ARM память не защищает. Или в Linux не реализована защита памяти на процессорах ARM из-за сложностей этой архитектуры.
Жду твоих тестов с ARM: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309
Инструкции NX или PAE нужны: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#250
>> А в виде железок вроде не, "такая скотина нужна самому!"
Завод в стране надо свой! Лучше два завода. РФ смогла бы сама сразу клепать свои Эльбрусы и SPARC, а со временем и RISC-V со своим SoC.
> Правда в том что ARM память не защищает. Или в Linux не
> реализована защита памяти на процессорах ARM из-за сложностей этой архитектуры.Это откуда такая "правда"? Тот же линух (ядро) прекрасно маркирует свои куски non exec, и соотв сегменты программ. Правами MMU ессно.
> Жду твоих тестов с ARM: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309
Ну найди мне 10 отличий amd64 от armhf - на одном и том же Debian 12?
На обоих paxtest kiddie ессно. И было это как-то так:
Debian 12/armhf (32 bit):
Test results:
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : VulnerableDebian 12/amd64:
Test results:
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
И они отличаются - например чем? (да, это не тот хeнтaй, извраты с mprotect не заткнуты). Но вон то намекает что права mmu работают.> Инструкции NX или PAE нужны: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#250
Это что, ссылка на сам себя как на авторитетный источник? Эти инструкции актуальны только лохматым 32 bit x86 какахам, не умевшим non-executable маркировку памяти по первости. Остальные выводы сделали, их MMU с самого начала умеют r/w/x права. По каким правилам ОС в конкретной инкарнации эти правила выставляет - вопрос номер два.
>>> А в виде железок вроде не, "такая скотина нужна самому!"
> Завод в стране надо свой! Лучше два завода. РФ смогла бы сама
> сразу клепать свои Эльбрусы и SPARC, а со временем и RISC-V
> со своим SoC.Да мало ли кому что надо. Вы представляете себе размер этого стека технологий? Ни 1 страна в мире ВСЕ комплектующие, расходники и проч для этого не производит самостоятельно. Что хотите с этим то и делайте.
В дебиане лучше бы реализовали mprotect для всей системы, ядра и приложений.Вот для ARM, RISC-V с реализацией mprotect будут проблемы из-за архитектуры этих процов.
> Видишь ли, дорогой индеец, верховные божества зарезервировали самый крутой ключ - себе. А ты в _ИХ_ системе сможешь не более чем они тебе милостиво позволят.Дорогой индеец здесь ты, потому что как индейцы предлагаешь сидеть и ничего не делать, под предлогом, что блоб IntelME выковырять полностью не удается.
В любом дистрибутиве GNU/Linux можно значительно повысить безопасность настроив верификацию процесса загрузки в GRUB и Linux IMA/EVM.
> на кой вообще в цепи гробРедхат скоро от груба избавится. Всё будет в efi-файле.
>> на кой вообще в цепи гроб
> Редхат скоро от груба избавится. Всё будет в efi-файле.А потом, когда у вас очередной кернель после апдейта не загрузится, Зоркий Глаз заметит что у сарая нет не только стены - но и подпорок для крыши, так что чего-то его немного этой крышей как раз и зашибло. Вот подстава то :)
> А потом, когда у вас очередной кернель после апдейта не загрузится...Значит загрузишься со старого. Что как маленький. :)
Я надеюсь, ты сейчас с грубом так делаешь, а не бежишь ось переставлять.
UEFI не поддерживает верификацию с шифрованного раздела как умеет GRUB.> Всё будет в efi-файле.
Все туда совать не надо. Это шаг назад в безопасности.
Ядро и инитрд желательно держать на шифрование разделе. А в efi-файл засунуть минимум: core.img от загрузчика GRUB.
Любителям секурности. Грузитесь с внешнего ключа(flash, tpc, etc), там же и ключь к ФС.
Загрузились, убрали ваш ключ куданибудь, бинго. Во времена финансовой свободы так обычно и делали те кому есть что прятать от аудиторов в погонах)
evil maid для uefi или Intel ME потенциально отсылают по сети что угодно. Но для бытовых случаев хватит.
Какой смысл после этого (и сотни других) примера про безопасность и тратить миллионы человеко-часов на переписывание кода?Вот это - и есть настоящее современное IT.
Так никто ничего и не переписывает все только языками чешут.
> Проблема получила кодовое имя PKfailПочему же сразу "проблема"?
Не проблема, а фича! )
Последняя мама Z790 AORUS. Прилично бабок цена. Вывод как на скрине. Блин за что я деньги платил ?
ты платил за понтыа что платили владельцы HP, Intel, Supermicro - вопрос
всякое дно уровня Dell и Acer вопросов нет, но серверные мамки
> Блин за что я деньги платил ?Не обижайся, просто "налог на тупость".
НЕЛЬЗЯ сейчас приобретать никакие мамки!! ЖДАТЬ. Пусть г____ноеды-мануфакчуреры едят собственное дерьмо.
Что мы хотим: мамки от $100 до $300. Полная секурность, включая полную блокировну Intel IME.
>Что мы хотим: мамки от $100 до $300. Полная секурность, включая полную блокировну Intel IMEДа ты я смотрю большой оптимист.
secure boot и так нигде не работает из каробки из за подписанного майкрософтом shim и того факта, что их ключ везде в db/KEK суют.
тебе ж вон там вадик на две страницы разжевал - что shim не позволяет без твоего явного участия исполнить что-то неподписанное. Во всяком случае - обычный, а не от ФСБ/AVP.
Ты купил плату от Gigabyte и ожидал, что у нее будет беспроблемный биос? Этот производитель всегда славился наплевательским подходом в разработке bios для своих продуктов.
> Этот производитель всегда славился наплевательским подходом в разработке bios для своих продуктов.А у какого прозводителя ненаплевательский подход?
"производители не обратили внимание" - читай "ФБР рекомендовало не обращать внимание на какой-то там тестовый ключ".
Ну вот согласен с теми, кто говорит, что оно нафиг никому не в$ралось.
Инженерные ключи, shim-загрузчики чего угодно, и т.п.
Не прижилось. Всем пофиг. Театр безопастности.
вообще-то оно РЕЗКО, на два порядка, усложнило написание примитивных бут-вирусов, доступных раньше каждому васяну.
Причем если раньше васяны хотя бы в бутсектор не всегда попадали или не помещались, надо было хоть ассемблер знать, то сейчас, когда uefi исполнит любой PEшник... хоть на хрусте пиши, хоть на gwbasic.И сфейлилось в общем-то не технически а на человеческом факторе - обезьянки с воплями "шва60дки лишаютъ!" добились таки от MS что та понаподписывала совсем невменяемой чертовщины.
Ну а нынешняя история - просто вишенкой на тортике.
> вообще-то оно РЕЗКО, на два порядка, усложнило написание примитивных бут-вирусов, доступных
> раньше каждому васяну.А что - Васян настолько ленивый и тупой что shim взять не может? На самом деле просто все вдарились в зарабатывание бабок и оно перешло в вымогатели-винлокеры и прочие шифровальщики еще до всех этих потуг. Ибо зачем возиться с этой гадостью если проще потребовать перевод коинов воооон туда, а нето фиг вам а не ваши данные?!
А какое-нибудь NSA с equation с этого цирка ржать будут аки кони, запатчив тебе какую-нить фирмвару накопителя, выдавать сектора с вырусом в четверг високосного года, и попробуй это отлови вообше. Жытаг адаптер ты себе уже купил? Не, менее радикально это вообще хрен заметишь, пожалуй :)
> А что - Васян настолько ленивый и тупой что shim взять не может?shim, внезапно, написан не настолько ленивыми и т-пыми как ты - и не загрузит автоматически неподписанную васянову поделку, вот так сюрприз.
В очередной раз - "квалификация"-c.
Да они и нафиг не нужны стали - юзеры ныне такие пошли, что сами сдают свои пароли и данные кредитки по первому "ваш почтовый ящик будет заблокирован, пришлите все свои деньги на счёт X".
ну нет, там надо уметь быть убедительным.А бутовые вирусы писали вовсе не ради минутного заработка, а просто развлечения ради.
И вот разглядываешь очередной трупик - а там легалайз мариванна, поверх (забыл уже, что там была за дрянь) и сверху near dark (в этом был таймер и он удалял таблицу разделов, поэтому и трупик, а то можно ж было еще кого-то четвертого и пятого намотать в этот же бутерброд)
Спасибо мариванне за заботливо сохраненную таблицу в седьмом секторе.Представь до какого п-ца оно бы щас докатилось, если бы любой BOOTX64.efi тут же бы загружался.
Ан, нет, тут попердолиться надо (отдельно интересно откуда у эсэсовца Вадика оказался тот касперский... впрочем он в целом небрезглив и внимателен - мне бы и в голову не пришло что там не самый обычный шим и grub - казалось бы, ну нафига?)
Секурбут для людей можно сделать одной восьминогой микросхемой и перемычкой, разрешающей писать на эту микросхему и грузиться с неё.А то, что у нас сейчас - это секурбут ОТ людей, когда на какие-то планшеты слаку поставить можно только выдрав загрузчик и ядра из убунты, а на некоторые - вообще никак.
останется переделать все операционные системы для загрузки с волшебной микросхемы.> А то, что у нас сейчас - это секурбут ОТ людей, когда на какие-то планшеты слаку поставить
вот ты действительно не понимаешь что как раз _людей_ - эти твои проблемы вот совершенно не интересуют?
И если ценой небольшого усложнения жизни кр@сн0гл@зикам (cp@ка на планшете, планшете, карл! - это б-жественно же ж!) доступно большое усложнение жизни вредителям - то безусловно именно так и надо было сделать.
Ну наконец-то у меня неподписанный syslinux-efi на hp elitebook g7 не будет вешать загрузку на десять минут.