Комментарии 96
Великолепно! Ещё раз доказывает странность такого вот хитровыделанного vendor lock-in.
Это не Vendor Lock. Secure Boot — разумная технология, обеспечивающая первый бастион защиты операционной системы, которая может в том числе защищать и запущенную ОС, если ОС поддерживает Secure Boot, например, в Linux можно настроить загрузку только доверенных модулей ядра, ключ которых есть в UEFI db.
Её можно отключить на всех магазинных платах, если она вам не нужна.
Её можно отключить на всех магазинных платах, если она вам не нужна.
Под вендор локом я подразумевал прошивку ключей Microsoft по умолчанию. Почему они?
Ладно ещё, когда компьютер поставляется в сборе с предустановленной Windows, но в других случаях…
Я конечно понимаю, чтохомя непродвинутым пользователям так проще, но можно же было придумать какой-то другой путь, например как в ssh: при попытке загрузки бинарника с неизвестным ключом UEFI бы спрашивал «а вы точно доверяете вот этому-этому?».
У самого настроен «кошерный» secure boot с правильными ключами, без всяких шимов.
Ладно ещё, когда компьютер поставляется в сборе с предустановленной Windows, но в других случаях…
Я конечно понимаю, что
У самого настроен «кошерный» secure boot с правильными ключами, без всяких шимов.
Ладно ещё, когда компьютер поставляется в сборе с предустановленной Windows, но в других случаях…Ответ простой: какая, по вашему система будет использоваться в 90% случаев? 10% щедро отдадим Linux, Hackintosh и прочей экзотике.
Поэтому, подстраиваются под удобство подавляющего большинства (удобство = не докучать пользователю лишними, с его точки зрения вопросами после каждого обновления загрузчика + хоть как-то защиить его от вредоносного загрузчика), а пара процентов пользователей, которым требуются собственные ключи, явно способны удалить ключи по умолчанию.
Ну поэтому я и предложил альтернативу: «Вы доверяете Microsoft Inc? Продолжаем устанавливать Windows?».
Ну или хотя бы не так сильно палились и вшивали бы ключ абстрактной UEFI Signing Foundation, которая бы верифицировала все остальные загрузчики.
А то получается «Каждому родившемуся на территории России сразу выдывать карточку Сбербанка, ну а что, в 90% случаев она ему нужна».
Ну или хотя бы не так сильно палились и вшивали бы ключ абстрактной UEFI Signing Foundation, которая бы верифицировала все остальные загрузчики.
А то получается «Каждому родившемуся на территории России сразу выдывать карточку Сбербанка, ну а что, в 90% случаев она ему нужна».
А UEFI Signing Foundation кто-то спросил, хочет ли она этим заниматься?
Кстати, интересно, наличие сертификатов MS это частная инициатива вендоров или требование спецификации? Если первое, то c UEFI Forum взятки гладки.
хомяпользователи будут читать? Они будут жать «Да» даже в том случае, когда там уже не загрузчик Microsoft, а загрузчик малвари. Именно поэтому и выбрано решение, которое от чайника не требует ничего, а продвинутому пользователю даёт возможность настройки по вкусу.
Кстати, интересно, наличие сертификатов MS это частная инициатива вендоров или требование спецификации? Если первое, то c UEFI Forum взятки гладки.
Ну поэтому я и предложил альтернативу: «Вы доверяете Microsoft Inc? Продолжаем устанавливать Windows?».Вы думаете,
Насколько знаю, как раз никто не захотел заниматься аудитом и подписью загрузчиков, и всё как-то само передалось Microsoft.
В UEFI требований по сертификатам нет как таковых, требование есть у Microsoft, для сертификации компьютера под Windows 10.
Некоторые материнские платы содержат ключи Canonical и Red Hat.
В UEFI требований по сертификатам нет как таковых, требование есть у Microsoft, для сертификации компьютера под Windows 10.
Некоторые материнские платы содержат ключи Canonical и Red Hat.
Насколько знаю, как раз никто не захотел заниматься аудитом и подписью загрузчиков, и всё как-то само передалось Microsoft.Причём Microsoft'у это тоже очень быстро надоело, и теперь проверка шима у них отдана на откуп тем же RedHat'у и Canonical, а сами MS только подпись лепят, когда получат от них добро. Да и то, даже в этом косячить умудряются.
И виртуализация есть и jit и minux установлен и ещё куча всего. А платформо-независимых драйверов нет, что бы из коробки всё что впаяно в плату гарантировано работало под любой OS.
А разумным бастионом защиты операционной системы должна была быть флешка на материнке и перемычка на плате, которая апартно запрещает изменять любые данные на ней.
А разумным бастионом защиты операционной системы должна была быть флешка на материнке и перемычка на плате, которая апартно запрещает изменять любые данные на ней.
А разумным бастионом защиты операционной системы должна была быть флешка на материнке и перемычка на плате, которая апартно запрещает изменять любые данные на ней.Это удорожает конечный продукт. То есть, вы получаете несколько процентов аудитории, которая понимает, что это такое и готова за это переплатить, но теряете гораздо большую часть, которой эта безопасность до лампочки.
Экономия уже дошла до того, что практически все вендоры начали просто распаивать микросхему на материнке (с выводом гребёнки для программатора) вместо гораздо более удобного варианта «микросхема в кроватке». Видимо, так на несколько центов дешевле.
Добавлю, что это не только удорожает продукт, но и делает автоматические обновления невозможными в принципе, потому что от пользователя требуется нетривиальное (т.е. не «нажмите Ввод») физическое присутствие, которое невозможно обеспечить либо по причине «у пользователя лапки», либо потому, что система установлена в дата-центре в закрытый шкаф.
А с чего вы решили что автоматические обновления это хорошо?
(asus live update неплохой пример заботы о пользователях)
Вы в биос в дата центре тоже удаленно заходите?
(asus live update неплохой пример заботы о пользователях)
Вы в биос в дата центре тоже удаленно заходите?
Удивительный вопрос, я даже несколько теряюсь. Ручные обновления = отсутствие обновлений = известные и эксплуатируемые уязвимости, которые значительно хуже, чем новые, еще не известные и не эксплуатируемые. Если вы готовы сами следить за обновлениями и нести ответственность за безопасность системы — я только за, но вас таких снова три с половиной, а защитить хоть как-нибудь и закрыть хотя бы известные дыры стараются для всех. UEFI Forum разработал и внедрил общих механизм для обновления всех компонентов прошивки — ESRT, которым пользуются клиенты вроде Windows Update и Linux Vendor Firmware Service. Очень жаль, что поддерживаются эти сервисы пока далеко не всеми, потому что нужны они еще вчера.
В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
Автоматическое обновление _загрузчика_ будет невозможно.
Почему-то обновление ядра линукса не требует переустановки груба — достаточно поправить в текстовом конфиге, что грузить дальше.
Да и обновление всего остального тоже без проблем.
Система вполне сможет обновлять автоматически, если нет обновлений grub/другого загрузчика (на моей памяти — примерно раз в два года в debian/stable).
Почему-то обновление ядра линукса не требует переустановки груба — достаточно поправить в текстовом конфиге, что грузить дальше.
Да и обновление всего остального тоже без проблем.
Система вполне сможет обновлять автоматически, если нет обновлений grub/другого загрузчика (на моей памяти — примерно раз в два года в debian/stable).
Новые компьютеры с системой Windows поставляются с прошивкой UEFI и с включенной загрузкой Secure Boot. Режим Secure Boot предотвращает загрузку операционных систем, если они не подписаны ключом, загруженным в UEFI; сразу «из коробки» можно загрузить только программное обеспечение, подписанное фирмой Microsoft.
То есть без танцев с бубнами ничего, кроме винды, поставить не получится.
"Это не Vendor Lock", говорите? Да это же явное навязывание своих продуктов и нарушение антимонопольного законодательства.
Secure Boot возможно отключить на всех материнских платах x86
Ключей Microsoft, присутствующих в материнских платах по умолчанию, два:
Microsoft Windows Production PCA 2011иMicrosoft Corporation UEFI CA 2011. Первым подписываются загрузчики Windows, вторым — остальное ПО (в т.ч. Linux'ы)Во многих материнских платах по умолчанию есть и другие ключи, например, Red Hat'а
В Secure Boot можно добавить свои ключи во внутреннюю ключницу, без ограничений. Можно также удалить ключи Microsoft.
Один из них используется в Kaspersky Rescue Disk 18
Можно засекать через сколько времени будет отозвана подпись загрузчика Касперского?
Как часто вообще вендоры обновляют список отозванных сертификатов в UEFI? Это только с обновлением прошивки материнской платы происходит?
Предполагаю, что сертификат Касперского долго не проживет, и его добавят в глобальный список отозванных сертификатов UEFI, который установят на компьютеры с Windows 10 через Windows Update, что нарушит загрузку Kaspersky Rescue Disk 18 и Silent UEFIinSecureBoot Disk. Посмотрим, как скоро это произойдет.
Microsoft распространяет этот лист через Windows Update, на компьютеры с Windows 10. Windows Update вшивает их в материнскую плату.
Чтобы подпись отозвали, проблему надо зарепортить UEFI Security Response Tem.
Как только проблему подтвердят, хеш начального загрузчика Касперского (который компрометирует UEFI CA) будет добавлен в UEFI Revocation List File, который затем MS постарается распространить на все машины с ключом MS KEK (на другие он просто не установится) через Windows Update.
Как только проблему подтвердят, хеш начального загрузчика Касперского (который компрометирует UEFI CA) будет добавлен в UEFI Revocation List File, который затем MS постарается распространить на все машины с ключом MS KEK (на другие он просто не установится) через Windows Update.
Мне теперь стало интересно как происходит перезапись этих обновлений. Скачал и обновил ОСь, обновились записи в UEFI Revocation List File, снес ОСь… Качаю новые обновления и что там дальше происходит? А если обновления уже интегрированы в образ? Оно перезаписывается или записи просто дублируются?
У gRT->SetVariable, функции, которую ОС вызывает для того, чтобы в NVRAM писать, есть флаг APPEND_WRITE, который позволяет к уже имеющимся revocation list'ам дописать новых записей. Т.к. записи эти хранятся в NVRAM, который в свою очередь хранится на SPI-чипе материнской платы, переустановка ОС не меняет их значений. Если значения там уже есть, SetVariable вернет EFI_SUCCESS, но менять ничего не будет, так что и не перезаписываются, и не дублируются, на самом деле.
Если хотите подробностей, все это описано подробно в спецификации UEFI 2.3.1C+ в разделе Runtime Services: SetVariable.
Если хотите подробностей, все это описано подробно в спецификации UEFI 2.3.1C+ в разделе Runtime Services: SetVariable.
Интересно, долго ли (и как?) пришлось искать дырявое подписанное комбо preloader-grub :)
Я считаю ZeroNet очень недооцененной системой, и намеренно публикую Silent-версию только в ZeroNet Git, для привлечения новых пользователей.
Нам и в Одноклассниках неплохо.
Большое спасибо за статью, прочитал с интересом. Как раз недавно хотел разобраться что из себя представляет PreLoader.efi, который я обнаружил ковыряясь в ArchLinux'овском iso.
Хотя при чтении было ощущение что где-то подвох (смотрим на календарь :).
Хотя при чтении было ощущение что где-то подвох (смотрим на календарь :).
Спасибо за статью, особенно за этот замечательный загрузчик Касперского, который теперь надо бы забанить по хорошему, потому что цепочка эта фактически уничтожает последние остатки доверия к подписям с корнем на UEFI CA.
Проблема эта известная, радикальное решение — не доверять UEFI CA совсем (Apple и Microsoft на своих машинах поступают именно так). При этом начнутся сложности с работой OptionROM'ов внешних видеокарт и рейд-контролеров, которые в UEFI 2.4+ можно обойти при помощи SecureBoot Deployment Mode, либо подписыванием ОРОМов своими ключами и загрузкой их с диска или SPI-флеша, а не из устройства.
В общем, теоретически решения есть, и все можно сделать, если очень хотеть. Практически же, за исключением трех с половиной анонимов, UEFI SecureBoot отключен на всех ПК, потому что любая технология, которая одновременно опциональна, досаждает пользователю, и легко отключаема — будет отключена навсегда при первом же досадном случае, что и происходит.
Проблема эта известная, радикальное решение — не доверять UEFI CA совсем (Apple и Microsoft на своих машинах поступают именно так). При этом начнутся сложности с работой OptionROM'ов внешних видеокарт и рейд-контролеров, которые в UEFI 2.4+ можно обойти при помощи SecureBoot Deployment Mode, либо подписыванием ОРОМов своими ключами и загрузкой их с диска или SPI-флеша, а не из устройства.
В общем, теоретически решения есть, и все можно сделать, если очень хотеть. Практически же, за исключением трех с половиной анонимов, UEFI SecureBoot отключен на всех ПК, потому что любая технология, которая одновременно опциональна, досаждает пользователю, и легко отключаема — будет отключена навсегда при первом же досадном случае, что и происходит.
Ну да, к сожалению. Вообще получается что хотелка ValdikSS (грузить что угодно) противоречит всей изначальной задумке Secure Boot (т. е. не дать загрузить что угодно). А кто этого хочет, тот чаще всего отключает secure boot вместо настройки своих ключей. Например я =( Знаю, что надо по хорошему всё сделать, и статьи про это у меня в закладках давно, но руки так и не дошли пока.
CodeRush А можно тебе как знатоку UEFI задать оффтопный вопрос:
1) Я вот никогда не видел ноутбука с поддержкой мыши в uefi setup. Все что я видел мимикрируют под интерфейс legacy bios. А на десктопах всё наоборот. Почему так?
2) Если не ошибаюсь, ты где-то говорил что uefi позволяет существенно сократить время загрузки системы при использовании raid контроллеров. Это как-то связано с выбором типа OpROM (Legacy/Uefi) в uefi setup?
CodeRush А можно тебе как знатоку UEFI задать оффтопный вопрос:
1) Я вот никогда не видел ноутбука с поддержкой мыши в uefi setup. Все что я видел мимикрируют под интерфейс legacy bios. А на десктопах всё наоборот. Почему так?
2) Если не ошибаюсь, ты где-то говорил что uefi позволяет существенно сократить время загрузки системы при использовании raid контроллеров. Это как-то связано с выбором типа OpROM (Legacy/Uefi) в uefi setup?
Тем не менее, по пункту 1 у меня ноутбук с поддержкой мыши в UEFI Setup.
1) Полно таких ноутбуков, а под старый текстовый интерфейс мимикрируют потому, что IBV так захотели. На десктопах давно уже AMI правит бал, и потому там давно уже вакханалия с OpenGL в Setup и GIFами анимированными, а на ноутбуках еще используют Phoenix и Insyde, которые по умолчанию выглядят «как встарья», и которые надо переделывать под мышь самому. Dell, к примеру, переделывает, а другие не парятся.
Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.
2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.
Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.
2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.
1) Ясно. Я как раз видел ноуты с прошивками от Phoenix и Insyde, и Dell'овские не попадались, потому спросил. А кто определяет что нравится людям? Отдел маркетинга? Мне эти блёстки не нужны, просто любопытно было. Меня поразило однажды: увидел на одном десктопе в uefi интерфейсе Веб браузер (!) и Skype (!!!). Нахрена??? Предполагалось что по нему будет звонить те, кому лень поставить OS? Это риторический вопрос конечно.
А ещё AMI я вижу на серверах (supermicro), но там нет этого всего с OpenGL. Я вообще CSM давно бы отключил везде, но сейчас его актуальность обусловлена только необходимостью обновления «bios» из dos'а. Почему-то производитель предлагает инструкции под DOS. Хотя я в интернете видел прошивальщик AMI, работающий через uefi shell. Я его не пробовал ещё (как-то стрёмно :)), но хотел более внимательно изучить. Как считаешь, можно ли просто так взять его, и прописав такие же параметры как прописаны в батниках с досовским прошивальщиком обновить uefi?
2) Ну я могу провести бенчмарки. Я просто хотел узнать, правильно ли что я переключал эту опцию или могло что-то ещё влиять. Ты говоришь что это зависит от количества подключенных к контроллеру дисков? Я просто переключать уже пробовал, но разницы особо не почувствовал — что так, что так раздражающе долго платформа перезапускается. Хотя опять же, у supermicro на некоторых материнках как-то криво сделано в настройках что не поймёшь, какой OROM в итоге загрузился.
А ещё AMI я вижу на серверах (supermicro), но там нет этого всего с OpenGL. Я вообще CSM давно бы отключил везде, но сейчас его актуальность обусловлена только необходимостью обновления «bios» из dos'а. Почему-то производитель предлагает инструкции под DOS. Хотя я в интернете видел прошивальщик AMI, работающий через uefi shell. Я его не пробовал ещё (как-то стрёмно :)), но хотел более внимательно изучить. Как считаешь, можно ли просто так взять его, и прописав такие же параметры как прописаны в батниках с досовским прошивальщиком обновить uefi?
2) Ну я могу провести бенчмарки. Я просто хотел узнать, правильно ли что я переключал эту опцию или могло что-то ещё влиять. Ты говоришь что это зависит от количества подключенных к контроллеру дисков? Я просто переключать уже пробовал, но разницы особо не почувствовал — что так, что так раздражающе долго платформа перезапускается. Хотя опять же, у supermicro на некоторых материнках как-то криво сделано в настройках что не поймёшь, какой OROM в итоге загрузился.
По первому пункту у асрока в их интерфейсе висит аж настройка VPN-а, ну а в пример серверных частей, если 3d со стразами и пукающими единорогами не вымораживает, то можно посмотреть на HP, графики в setup там добавили по минимуму, но вот прошивка управления это линукс, в котором крутятся иксы, в которых крутится фаерфокс(вроде как он), плюс всякое «прикручу везде jsonчик, оберну я всё в ajax». Ну и (спорно весьма)приятная фишка — опятьже через эту утиль HPE предлагает накатывать операционную систему (при этом оно из прошивки вытаскивает туда драйвера).
Ну это же была весьма популярная лет 10 назад идея Instant OS'ей: howtokill.ru/review/splashtop-os-instant-on-os
Типа, не обязательно грузить тяжелую полноценную ОСь, просто чтобы выйти по-быстрому в инет. Если бы не взрывное развитие рынка смартфонов — могла бы и взлететь.
Типа, не обязательно грузить тяжелую полноценную ОСь, просто чтобы выйти по-быстрому в инет. Если бы не взрывное развитие рынка смартфонов — могла бы и взлететь.
особенно за этот замечательный загрузчик Касперского, который теперь надо бы забанить по хорошему, потому что цепочка эта фактически уничтожает последние остатки доверия к подписям с корнем на UEFI CA.А он не единственный такой ;)
Никто другого и не ждал, за 7 лет с запуска UEFI CA им успели подписать такое количество всякой дырявой фигни, что доверять ему теперь — то еще решение. При этом не будешь доверять — OROMы перестанут запускаться, т.е. технология сразу переходит из разряда «включил и работает» в «требует постоянного внимания администратора», и потому отключать ее начнут теперь еще более яростно.
Как и говорилось, что хочешь безопасности — удаляй дефолтные ключи и переподписывай всё (и опромы) на своём.
А как опромы подписать? Есть какой-то generic way?
sbsigntool
Я имею ввиду другое: разве подписи опромов не храняться в ПЗУ железки, с которой этот опром идет?
Хранятся, но там это ПЗУ обычно доступно через SMBUS, и потому достаточно найти утилиту для обновления прошивки. Более того, более новую версию ОПРОМа можно положить прямо в основную прошивку, и загружать их оттуда.
А, вы про полный алгоритм? Тут есть два варианта(не очень универсальных):
1) Железка умеет давать скачать и обновить свой OpROM без особых проблем — используем утилиту, которая умеет читать/писать оный OpRROM (для некоторого железа пойдет flashrom), считываем, возможно раздракониваем (если там склейка из Legacy+UEFI), подписываем UEFI часть signtool-ом, собираем обратно (если надо), зашиваем, радуемся.
2) Железка не умеет/не даёт/убили предыдущим вариантом — берём клипсы/паяльник и внешний программатор, ищем флешку с прошивкой на железке цепляем клипсу/отпаиваем, вешаем на программатор, считываем и повторяем пункт 1.
Полностью универсального решения нет, разве что встроить отпромы от нужных железок прямо в образ UEFI, но тут вам могут дать прикурить всякие Boot Guardы и компания.
1) Железка умеет давать скачать и обновить свой OpROM без особых проблем — используем утилиту, которая умеет читать/писать оный OpRROM (для некоторого железа пойдет flashrom), считываем, возможно раздракониваем (если там склейка из Legacy+UEFI), подписываем UEFI часть signtool-ом, собираем обратно (если надо), зашиваем, радуемся.
2) Железка не умеет/не даёт/убили предыдущим вариантом — берём клипсы/паяльник и внешний программатор, ищем флешку с прошивкой на железке цепляем клипсу/отпаиваем, вешаем на программатор, считываем и повторяем пункт 1.
Полностью универсального решения нет, разве что встроить отпромы от нужных железок прямо в образ UEFI, но тут вам могут дать прикурить всякие Boot Guardы и компания.
С одной стороны спасибо конечно, но с другой стороны как-то действительно можно скачать с ZeroNet?
Просто в описании все ссылки ведут на github, а в разделе релизов
http://127.0.0.1:43110/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/repo/releases/?1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv
пусто?
Просто в описании все ссылки ведут на github, а в разделе релизов
http://127.0.0.1:43110/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/repo/releases/?1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv
пусто?
Репозиторий silent, файлы в папке filesystem_kaspersky.
так в первую очередь попробовал, но кнопка Download не работает в папках, а попытка взять zip по аналогии с гитхабом не удалась…
Вверху есть кнопка clone, которая показывает команду для выполнения
git clone.git clone $path_to_zeronet_data_folder/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/silent-uefiinsecureboot-disk.git -b silent
Аж пришлось зарегаться, чтобы спросить, потому что не помогают ни гугл, ни инструкция на офсайте. Всё равно непонятно, как сделать git clone. Что ИМЕННО надо подставить вместо $path_to_zeronet_data_folder? Я уж все варианты перепробовал, которые придумал
Путь до папки «data» в папке zeronet.
Пример для Windows:
Пример для Windows:
git clone C:\ZeroNet\data\1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv\silent-uefiinsecureboot-disk.git -b silentСемён Семёныч!!! (С) Бриллиантовая Рука
Получилось, огромное спасибо. Я-то думал, data folder — это URL prefix. Что-нибудь эдакое хитровыстраданное (вольная цитата из beginner's guide-а):
Но нет худа без добра. И на хабре, наконец, зарегался, и про зиронет, наконец, узнал
P.S. Да чего уж там… Я и сам git только недели две (наконец) расковырял. До этого всё svn-ом пользовался
Получилось, огромное спасибо. Я-то думал, data folder — это URL prefix. Что-нибудь эдакое хитровыстраданное (вольная цитата из beginner's guide-а):
(Remember to give others http: //127.0.0.1/ your_repo_address instead of http: // 127.0.0.1/ бла-бла-бла/repo/?your_repo_address because that adds more flexibility and makes changing Git Center source code easier.)
Но нет худа без добра. И на хабре, наконец, зарегался, и про зиронет, наконец, узнал
P.S. Да чего уж там… Я и сам git только недели две (наконец) расковырял. До этого всё svn-ом пользовался
Responsible Disclosure прямо налицо.
По моему мнению, проблема не настолько значительная, чтобы придерживаться ответственного подхода к её сообщению. Она нишевая, способна приченить урон в ограниченных случаях и особых условиях.
Со стороны Касперского устранить проблему нельзя, только писать в UEFI, с просьбой о добавлении хеша или сертификата в список отзыва.
Прежде всего интересно, сколько времени займет обновление списка отзыва в случае публичного сообщения о проблеме.
Со стороны Касперского устранить проблему нельзя, только писать в UEFI, с просьбой о добавлении хеша или сертификата в список отзыва.
Прежде всего интересно, сколько времени займет обновление списка отзыва в случае публичного сообщения о проблеме.
Напиши им про это сам, пожалуйста, потому что дойти до них может с заметным опозданием (если хочешь, чтобы починили, конечно).
Касперскому в твиттер напишите.
По состоянию на 3 июня, загрузчик не отозвали, UEFI Forum на мои письма сначала отвечал, что передал информацию отделу безопасности UEFI (я отправил всю информацию и минимальный собранный образ в качестве примера), но после 7 мая — никаких ответов.
Вот вам и Secure Boot.
Вот вам и Secure Boot.
Валдик, если бы вы пошли по процедуре ответственного раскрытия, вы бы не только могли претендовать на вознаграждение по программе bugbounty ЛК, но и были бы в курсе предпринимаемых действий. Сейчас не очень понятно почему вы хотите особого информирования.
Я смотрел программу Касперского на HackerOne перед публикацией этой статьи, в которой не было Kaspersky Rescue Disk (на тот момент я не знал, что файл используется в корпоративном ПО), а также прочёл правила, в которых говорилось, что нельзя выкладывать PoC даже после устранения проблемы.
Решил, что меня такие правила не устраивают, написал статью и обратился в UEFI Forum. Собственно, причем здесь Касперский, если я пишу в UEFI Forum, а не вам?
Решил, что меня такие правила не устраивают, написал статью и обратился в UEFI Forum. Собственно, причем здесь Касперский, если я пишу в UEFI Forum, а не вам?
The UEFI Forum greatly appreciates ethical disclosures of vulnerabilities by security researchers.
https://hackerone.com/uefi_forum
There are no known guidelines for reporting potential security vulnerabilities to this organization.
Ссылка на uefi.org/security, откуда цитата, висит на главной странице. Видимо проблема не в том, что её сложно найти.
Вы, пожалуйста, определитесь. Автор мог претендовать на бонус по программе bugbounty ЛК, или на что-то от UEFI Forum? На что-то конкретно от последних? Где-то об этом написано?.. Потом, из чего вы делаете вывод что автор не воспользовался программой по уязвимостям от UEFI Forum?.. Судя по статье и комментариям ссылку на ту страницу, откуда вы приводите цитату, автор нашел и именно по этим адресам написал. Именно с этих адресов ему не отвечают.
Вообще же проблема не стоит выеденного яйца, достаточно добавить хеша или сертификата в список отзыва в очередном обновлении, и всё. Да, это неприятно, но выход тут только один.
Я собственно с того и начал. Независимо даже от того, мог ли автор претендовать на вознаграждение, многие считают неэтичным вываливать эксплойты в интернет сразу после обнаружения, не поставив в известность вендоров и не согласовав сроков раскрытия. Это неэтично и помогает злоумышленникам и ставит под угрозу пользователей. Сделав так, автор добровольно отказался от репутации ответственного white-hat исследователя, видимо у UEFI форум соответственное к нему отношение.
Это, конечно не так, как я уже писал выше, списки отзыва — не игрушка, особенно если они могут превратить компы клиентов в кирпичи. Это не значит что ничего не делается, это значит что делается осторожно.
Вообще же проблема не стоит выеденного яйца,
Это, конечно не так, как я уже писал выше, списки отзыва — не игрушка, особенно если они могут превратить компы клиентов в кирпичи. Это не значит что ничего не делается, это значит что делается осторожно.
Этика у каждого своя. Я считаю неэтичным отношение Лаборатории Касперского к подписи загрузчиков. Лаборатория халатно отнеслась к проверке кода того, что она подписывает своим доверенным ключом, и отношение к ней должно быть соответствующее.
Знаете, бывает так, что дырки — это следствие не внимательности автора кода, ошибки или друго неумышленного действтия. И в этом случае можно говорить про этику.
Но как можно неумышлено написать загрузчик, который грузит всё подряд, обнуляя весь SecureBoot, а потом ещё вещать про этику? Если это ошибка в ПО, его можно хотя бы запатчить. А утекший в сеть подписанный код запатчить нельзя — только отзыв ключей.
Но как можно неумышлено написать загрузчик, который грузит всё подряд, обнуляя весь SecureBoot, а потом ещё вещать про этику? Если это ошибка в ПО, его можно хотя бы запатчить. А утекший в сеть подписанный код запатчить нельзя — только отзыв ключей.
Или бан 200+ вариантов подписанных загрузчиков, как получилось с BootHole. Отзывать ключи для х86 SecureBoot — это такой кошмар будет, что представить сложно.
Такими банами можно будет всю NVRAM забить и поиметь проблем, благо у некоторых IBV уже был схожий печальный опыт с мусором в его переменных. =)
Подумайте ещё раз.
Конечно интересно! Ретроспективный отзыв сертификата, который инвалидирует подписанные файлы за последние 3 года- это же так весело, что может пойти не так? Ведь вы же учли все возможные сценарии использования!
Прежде всего интересно, сколько времени займет обновление списка отзыва в случае публичного сообщения о проблеме.
Конечно интересно! Ретроспективный отзыв сертификата, который инвалидирует подписанные файлы за последние 3 года- это же так весело, что может пойти не так? Ведь вы же учли все возможные сценарии использования!
В UEFI dbx можно добавлять не только сертификаты, но и хеши конкретных запускаемых через StartImage файлов. Именно так было сделано с загрузчиками Windows в 2016.
Можно отозвать только GRUB (fde_ld.efi), разрешающий загрузку модулей, но не сам пред-загрузчик Касперского (BOOTX64.efi).
Можно отозвать только GRUB (fde_ld.efi), разрешающий загрузку модулей, но не сам пред-загрузчик Касперского (BOOTX64.efi).
Где-то выше, коллега по цеху упоминал что на практике все выродилось в то, что ШИМ все делали не безопасно. Справедливо и обратное утверждение. UEFI реализован чуть лучше чем плохо. Гарантии даете что этот механизм будет работать надежно? И что никто не пострадает?
Любой отзыв это серьёзный риск. У меня был случай когда ошибочно отозвали сертификат не с указанной даты а ретроспективно. Просто CA пропустило мимо мозга дату отзыва. Пока они исправили ошибку было не очень приятно. А здесь, где процедуры выпуска апдейтов третьими лицами ещё задействованы…
Вы работаете в Касперском?
Правильно ли я понимаю, судя по названию файла fde_ld.efi, этот загрузчик был создан для Kaspersky Endpoint Business, и был переиспользован для Kaspersky Rescue Disk?
Отзыв этого файла сломает загрузку с шифрованного диска в Kaspersky Endpoint Business?
Правильно ли я понимаю, судя по названию файла fde_ld.efi, этот загрузчик был создан для Kaspersky Endpoint Business, и был переиспользован для Kaspersky Rescue Disk?
Отзыв этого файла сломает загрузку с шифрованного диска в Kaspersky Endpoint Business?
По моему мнению, проблема не настолько значительная, чтобы придерживаться ответственного подхода к её сообщению.Зачем тогда надо было статью об этом писать?
И да, проблема значительная. Я за два года до публикации о баге в NTFS отрапортовал в Microsoft и дважды спросил разрешения на публикаю. Я конечно не люблю порой корпорации за их поведение, и не редко бывают причины так действовать, но простые пользователи тут не причем. Видимо плюсики дороже.
Ждем Petya2.
Зачем тогда надо было статью об этом писать?Чтобы обратить внимание на существование подписанных загрузчиков, позволяющих загружать что угодно. Механизм подписей пред-загрузчиков для Secure Boot, с теми требованиями, какие выдвигались к ним, несостоятельны. Всё основывается на доверии подписывающей стороны (Microsoft) к компании, и Microsoft не проверяет, что вы будете загружать в качестве второго загрузчика. Технически удостовериться, что компания не начнет подписывать всё что угодно ключом, включенным в пред-загрузчик, невозможно до обнаружения такого загрузчика.
В SSL-сертификатами в вебе было то же самое, пока не сделали Certificate Transparency и различные системы обнаружения аномалий с сертификатами в браузерах.
Как видно, Kaspersky подписал обычный GRUB, вероятно, даже не задумываясь, что делает что-то неправильно. И загрузчик от Касперского — не единственный такой.
Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.
Я за два года до публикации о баге в NTFS отрапортовал в Microsoft и дважды спросил разрешения на публикацию. Я конечно не люблю порой корпорации за их поведение, и не редко бывают причины так действовать, но простые пользователи тут не причем.Вашу ошибку в NTFS можно использовать без прав администратора, и, возможно, даже удалённо, через какой-то софт.
На подмену EFI-загрузчика требуются права администратора в ОС (как в Windows, так и в Linux), злоумышленник должен написать свой буткит+руткит, и должен его ещё как-то использовать из ОС. Такая сложная процедура бессмысленна для атак на обычных пользователей — если у злоумышленника и так есть администраторский доступ в ОС, он просто выполнит необходимые действия в ОС, а не через загрузчик.
Это имеет смысл только при узконаправленных целевых атаках с дополнительным сокрытием (APT), которые не применяются массово, и не направленых на обычных пользователей.
Чтобы обратить внимание на существование подписанных загрузчиков, позволяющих загружать что угодно.Чье внимание? Разработчики и комитет UEFI и так все это знают. Вы нам нового ничего не рассказали. А простым пользователям эта информация никакой ценности не несет.
Механизм подписей пред-загрузчиков для Secure Boot, с теми требованиями, какие выдвигались к ним, несостоятельны.Ну так и UEFI не состоялся. С ним намного больше проблем чем с BIOS. Все в практику уперлось. А стандарт разумный.
Всё основывается на доверии подписывающей стороны (Microsoft) к компании, и Microsoft не проверяет, что вы будете загружать в качестве второго загрузчика.Отвечать должна Microsoft(по совести). Т.к. на себя замкнула подпись. Но только это к ним вопросы должны быть. Направленные.
Технически удостовериться, что компания не начнет подписывать всё что угодно ключом, включенным в пред-загрузчик, невозможно до обнаружения такого загрузчика.Это не так. Было бы желание. Большинство тонкостей можно выяснить, работая с модулем как с черным ящиком.
даже не задумываясь, что делает что-то неправильноА вы когда делаете что-то не так всегда это сознаете?
Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.Никак вообще. Деньги только в большем объеме брать будут.
Вашу ошибку в NTFS можно использовать без прав администратора, и, возможно, даже удалённо, через какой-то софт.Нет, нужен физический доступ к ПК. Она не критичная. А популярной она стала только потому что собрались любители покритиковать. Ну и любители пополнения контентов своих сайтов. Раздули из мухи слона. Всем нужна истерика.
На подмену EFI-загрузчика требуются права администратора в ОС (как в Windows, так и в Linux), злоумышленник должен написать свой буткит+руткит, и должен его ещё как-то использовать из ОС.Видимо Petya как-то иначе работал. Пойду изучать.
Чье внимание? Разработчики и комитет UEFI и так все это знают. Вы нам нового ничего не рассказали.Для меня это новая информация. Раз комитет UEFI знает и не отзывает, то и этот не отзовут? В чем тогда смысл прохождения аудита для получения подписи Secure Boot?
Ну так и UEFI не состоялся. С ним намного больше проблем чем с BIOS. Все в практику уперлось. А стандарт разумный.Не согласен с вами. Каких-то серьезных проблем с точки зрения использования не наблюдал, что на десктопах и ноутбуках, что на VPS (некоторые хостеры используют UEFI).
Это не так. Было бы желание. Большинство тонкостей можно выяснить, работая с модулем как с черным ящиком.Не понял, о чем вы. Я о том, что Microsoft, по-видимому, интересует только пред-загрузчик (тот, который они будут подписывать), а payload, который он загружает, не проверяется.
А вы когда делаете что-то не так всегда это сознаете?Если это что-то настолько серьезного уровня, как глобальная подпись файла, которая может повлиять на всю технологию в целом, то я либо попрошу всё сделать компетентных людей, либо трижды удостоверюсь, что все сделал правильно, и попрошу компетентных людей перепроверить, чтобы не добавлять проблем ни себе, ни остальным.
Вероятно, некоторые думают иначе, и им важно только то, чтобы их ПО запускалось с включенным Secure Boot.
Нет, нужен физический доступ к ПК.Речь о той уязвимости, которая описана в вашей статье «Баг в NTFS, или как подвесить всю систему»? Для чего там нужен физический доступ?
Видимо Petya как-то иначе работал. Пойду изучать.Либо происходила перезапись MBR с администраторскими правами, либо просто шифровались документы пользователя из ОС. NotPetya ещё применял эксплоит EternalBlue, для получения прав администратора.
https://en.wikipedia.org/wiki/Petya_(malware)#Operation
Чье внимание? Разработчики и комитет UEFI и так все это знают. Вы нам нового ничего не рассказали. А простым пользователям эта информация никакой ценности не несет.
А кто вы собственно такой, чтобы опредлять что несет, а что не несет простым пользователям эта информация? Уж не переели ли вы ухи с такими замашками?
А кто вы собственно такой, чтобы опредлять что несет, а что не несет простым пользователям эта информация?Разработчик BIOS и UEFI загрузчиков. Одно из. Этим не ограничено. И далеко от всего списка.
Что до информации в статье, публикация такой новости Microsoft только на руку, чтобы использовать это как повод не подписывать загрузчики. Microsoft работает в сторону полной монополизации. Вопрос сугубо политический. Спасибо подобным авторам…
Так и вот, вы то собственно кто? (вопрос риторический, ответ я знаю)
Разработчик BIOS и UEFI загрузчиков. Одно из. Этим не ограничено. И далеко от всего списка.
Ну дык и разрабатываете! И желательно без таких вот косяков. Я что-то не припоминаю, чтобы цензура входила в сферу компетенции разработчиков.
> Что до информации в статье, публикация такой новости Microsoft только на руку, чтобы использовать это как повод не подписывать загрузчики.
Информация в статье — это скорее повод выпилить ключи Microsoft и использовать свои. А не стоять с протянутой рукой, втянув языки в задницы.
>Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.
Для EFI-модулей всегда было требование на EV сертификаты. Там ещё и процесс нетривиальный.
Для EFI-модулей всегда было требование на EV сертификаты. Там ещё и процесс нетривиальный.
Корректнее сказать «на лицо».
Скачать Silent UEFIinSecureBoot Disk в сети ZeroNet Git Center: 127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/
Я извиняюсь, а Silent в ZeroNet был залит по каким-то соображениям безопасности?
В новых версиях Kaspersky Rescue Disk теперь используется обычный, не подписанный GRUB2, который не загружается в Secure Boot.
Microsoft выпустила обновление KB4524244 для Windows 10, от 11.02.2020, блокирующее загрузчик с диска Kaspersky Rescue Disk (обновление добавляет хеш загрузчика в UEFI dbx), но отозвала обновление 15.02.2020, из-за проблем с некоторыми материнскими платами HP:
thewincentral.com/windows-10-updates-kb4532693-kb4524244-causing-many-issues-report-users
h30434.www3.hp.com/t5/Business-Notebooks/KB4524244-cause-certain-HP-computers-to-hang-and-even-brick/td-p/7471459
Подробности об обновлении на сайте Microsoft:
docs.microsoft.com/en-us/windows/release-information/status-windows-10-1909#392msgdesc
В этом обновлении были отозваны следующие файлы:
Один из хешей — уязвимый загрузчик с Kaspersky Rescue Disk (bootx64.efi).
BOOTX64.EFI 81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86
Какие файлы стоят за другими хешами — неизвестно, но это не другие подобные уязвимые загрузчики, о которых я не рассказывал.
thewincentral.com/windows-10-updates-kb4532693-kb4524244-causing-many-issues-report-users
h30434.www3.hp.com/t5/Business-Notebooks/KB4524244-cause-certain-HP-computers-to-hang-and-even-brick/td-p/7471459
Подробности об обновлении на сайте Microsoft:
docs.microsoft.com/en-us/windows/release-information/status-windows-10-1909#392msgdesc
Next steps: We are working on an improved version of this update in coordination with our partners and will release it in a future update.
В этом обновлении были отозваны следующие файлы:
{microsoft} {sha256} 81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86
{microsoft} {sha256} b92af298dc08049b78c77492d6551b710cd72aada3d77be54609e43278ef6e4d
{microsoft} {sha256} e19dae83c02e6f281358d4ebd11d7723b4f5ea0e357907d5443decc5f93c1e9d
{microsoft} {sha256} 39dbc2288ef44b5f95332cb777e31103e840dba680634aa806f5c9b100061802
{microsoft} {sha256} 32f5940ca29dd812a2c145e6fc89646628ffcc7c7a42cae512337d8d29c40bbd
{microsoft} {sha256} 10d45fcba396aef3153ee8f6ecae58afe8476a280a2026fc71f6217dcf49ba2fОдин из хешей — уязвимый загрузчик с Kaspersky Rescue Disk (bootx64.efi).
BOOTX64.EFI 81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86
Какие файлы стоят за другими хешами — неизвестно, но это не другие подобные уязвимые загрузчики, о которых я не рассказывал.
Там еще одна проблема, и за которой обновление отложили: ребята из MS не стали проверять, что оно вообще может быть установлено (т.е. что ключ МС присутствует в KEK), и пытаются писать в dbx даже тогда, когда права на это не имеют, и при этом воспринимают EFI_SECURITY_VIOLATION как критическую ошибку, и пугают пользователей сообщениями о ней. Надеюсь, в следующей итерации это исправят.
По поводу проблем с ноутбуками HP — там сработала система защиты переменных SecureBoot от несанкционированной записи, включенная по умолчанию. Система эта почему-то не удаляет ключ МС из КЕК при работе (это баг, потому что как еще сообщить коду ОС, что писать в db* нельзя?).
В общем, все как всегда: люди придумывают механизм обновления, которым никто никогда не пользовался, и потому он вообще не тестировался, а когда наконец им решили воспользоваться, оказалось, что детали работы этого механизма неизвестны ни тем, кто им решил воспользоваться, ни тем, кто его реализовывал. Бизнес как обычно.
По поводу проблем с ноутбуками HP — там сработала система защиты переменных SecureBoot от несанкционированной записи, включенная по умолчанию. Система эта почему-то не удаляет ключ МС из КЕК при работе (это баг, потому что как еще сообщить коду ОС, что писать в db* нельзя?).
В общем, все как всегда: люди придумывают механизм обновления, которым никто никогда не пользовался, и потому он вообще не тестировался, а когда наконец им решили воспользоваться, оказалось, что детали работы этого механизма неизвестны ни тем, кто им решил воспользоваться, ни тем, кто его реализовывал. Бизнес как обычно.
Есть вопрос, а может ли злоумышленник записать в revocation list материнской платы свой хеш, чтобы сделать загрузку Windows невозможной?
UEFI Forum обновил лист отозванных файлов на сайте. Загрузчик Касперского BOOTX64.EFI внесён под номером 30.
30: {microsoft} {sha256} 81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86не прошло и пол года )
Ждали починки BootHole, чтобы 2 раза на всем подряд dbx не обновлять.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эксплуатация подписанных загрузчиков для обхода защиты UEFI Secure Boot