Эксплуатация подписанных загрузчиков для обхода защиты UEFI Secure Boot

    English version of this article.

    Введение

    Прошивки современных материнских плат компьютера работают по спецификации UEFI, и с 2013 года поддерживают технологию проверки подлинности загружаемых программ и драйверов Secure Boot, призванную защитить компьютер от буткитов. Secure Boot блокирует выполнение неподписанного или недоверенного программного кода: .efi-файлов программ и загрузчиков операционных систем, прошивок дополнительного оборудования (OPROM видеокарт, сетевых адаптеров).
    Secure Boot можно отключить на любой магазинной материнской плате, но обязательное требование для изменения его настроек — физическое присутствие за компьютером. Необходимо зайти в настройки UEFI при загрузке компьютера, и только тогда получится отключить технологию или изменить её настройки.

    Большинство материнских плат поставляется только с ключами Microsoft в качестве доверенных, из-за чего создатели загрузочного ПО вынуждены обращаться в Microsoft за подписью загрузчиков, проходить процедуру аудита, и обосновывать необходимость глобальной подписи их файла, если они хотят, чтобы диск или флешка запускались без необходимости отключения Secure Boot или добавления их ключа вручную на каждом компьютере.
    Подписывать загрузчики у Microsoft приходится разработчикам дистрибутивов Linux, гипервизоров, загрузочных дисков антивирусов и программ для восстановления компьютера.

    Мне хотелось сделать загрузочную флешку с различным ПО для восстановления компьютера, которая бы грузилась без отключения Secure Boot. Посмотрим, как это можно реализовать.

    Подписанные загрузчики загрузчиков

    Итак, чтобы загрузить Linux при включенном Secure Boot, нужен подписанный загрузчик. Microsoft запретила подписывать ПО, лицензированное под GPLv3, из-за запрета тивоизации правилами лицензии, поэтому GRUB подписать не получится.
    В ответ на это, Linux Foundation выпустили PreLoader, а Мэтью Гарретт написал shim — маленькие начальные загрузчики, проверяющие подпись или хеш следующего загружаемого файла. PreLoader и shim не используют сертификаты UEFI db, а содержат базу разрешенных хешей (PreLoader) или сертификатов (shim) внутри себя.
    Обе программы, помимо автоматической загрузки доверенных файлов, позволяют загружать и любые ранее недоверенные файлы в режиме Secure Boot, но требуют физического присутствия пользователя: при первом запуске необходимо выбрать добавляемый сертификат или файл для хеширования в графическом интерфейсе, после чего данные заносятся в специальную переменную NVRAM материнской платы, которая недоступна для изменения из загруженной операционной системы. Файлы становятся доверенными только для этих пред-загрузчиков, а не для Secure Boot вообще, и запустить их без PreLoader/shim всё равно не получится.

    Действия, необходимые для запуска недоверенной программы через shim.
    Действия, необходимые при первом запуске недоверенной программы через shim.

    Все современные популярные дистрибутивы Linux используют shim, из-за поддержки сертификатов, которая позволяет легко обновлять следующий загрузчик без необходимости взаимодействия с пользователем. Как правило, shim используется для запуска GRUB2 — наиболее популярного бутлоадера в Linux.

    GRUB2

    Чтобы злоумышленники втихую не наделали делов с помощью подписанного загрузчика какого-либо дистрибутива, Red Hat сделал патчи для GRUB2, блокирующие «опасные» функции при включенном Secure Boot: insmod/rmmod, appleloader, linux (заменён linuxefi), multiboot, xnu, memrw, iorw. К модулю chainloader, загружающему произвольные .efi-файлы, дописали собственный загрузчик .efi (PE), без использования команд UEFI LoadImage/StartImage, а также код валидации загружаемых файлов через shim, чтобы сохранялась возможность загрузки файлов, доверенных для shim, но не доверенных с точки зрения UEFI. Почему сделали именно так — непонятно; UEFI позволяет переопределять (хукать) функции проверки загружаемых образов, именно так работает PreLoader, да и в самом shim такая функция имеется, но по умолчанию отключена.

    Так или иначе, воспользоваться подписанным GRUB из какого-то дистрибутива Linux не получится. Для создания универсальной загрузочной флешки, которая бы не требовала добавление ключей каждого загружаемого файла в доверенные, есть два пути:

    • Использование модифицированного GRUB, загружающего EFI-файлы своими силами, без проверки цифровой подписи, и без блокирования модулей;
    • Использование собственного пред-загрузчика (второго), переопределяющего функции проверки цифровой подписи UEFI (EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState, EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication)

    Второй вариант предпочтительней — загруженные недоверенные программы тоже смогут загружать недоверенные программы (например, можно загружать файлы через UEFI Shell), а в первом варианте загружать всё может только сам GRUB. Модифицируем PreLoader, убрав из него лишний код и разрешив запуск любых файлов.

    Итого, архитектура флешки получилась следующая:
       ______            ______                ______
      ╱│     │          ╱│     │              ╱│     │
     /_│     │    →    /_│     │      →      /_│     │
     │       │    →    │       │      →      │       │
     │  EFI  │    →    │  EFI  │      →      │  EFI  │
     │_______│         │_______│             │_______│
    
    BOOTX64.efi        grubx64.efi        grubx64_real.efi
    
      (shim)      (FileAuthentication         (GRUB2)
                    override)
    
        ↓↓↓                ↑
                           ↑
       ______              ↑
      ╱│     │             ║
     /_│     │             ║
     │       │  ═══════════╝
     │  EFI  │
     │_______│
    
    MokManager.efi
    
    (Key enrolling
     tool)


    Так появился Super UEFIinSecureBoot Disk.
    Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.

    Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.

    Образ состоит из трех компонентов: предзагрузчика shim из Fedora (подписан ключом Microsoft, предустановленным в подавляющее большинство материнских плат и ноутбуков), модифицированного предзагрузчика PreLoader от Linux Foundation (для отключения проверки подписи при загрузке .efi-файлов), и модифицированного загрузчика GRUB2.

    Во время первой загрузки диска на компьютере с Secure Boot необходимо выбрать сертификат через меню MokManager (запускается автоматически), после чего загрузчик будет работать так, словно Secure Boot выключен: GRUB загружает любой неподписанный .efi-файл или Linux-ядро, загруженные EFI-программы могут запускать другие программы и драйверы с отсутствующей или недоверенной подписью.

    Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.

    Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.


    Подписанные загрузчики

    Мне было интересно, можно ли как-то обойти необходимость добавления ключа через shim при первом запуске. Может, есть какие-то подписанные загрузчики, которые позволяют делать больше, чем рассчитывали авторы?
    Как оказалось — такие загрузчики есть. Один из них используется в Kaspersky Rescue Disk 18 — загрузочном диске с антивирусным ПО. GRUB с диска позволяет загружать модули (команда insmod), а модули в GRUB — обычный исполняемый код. Пред-загрузчик у диска собственный.

    Разумеется, просто так GRUB из диска не загрузит недоверенный код. Необходимо модифицировать модуль chainloader, чтобы GRUB не использовал функции UEFI LoadImage/StartImage, а самостоятельно загружал .efi-файл в память, выполнял релокацию, находил точку входа и переходил по ней. К счастью, почти весь необходимый код есть в репозитории GRUB'а с поддержкой Secure Boot от Red Hat, единственная проблема: код парсинга заголовка PE отсутствует, заголовок парсит и возвращает shim, в ответ на вызов функции через специальный протокол. Это легко исправить, портировав соответствующий код из shim или PreLoader в GRUB.

    Так появился Silent UEFIinSecureBoot Disk. Получившаяся архитектура диска выглядит следующим образом:
       ______            ______                ______
      ╱│     │          ╱│     │              ╱│     │
     /_│     │         /_│     │      →      /_│     │
     │       │         │       │      →      │       │
     │  EFI  │         │  EFI  │      →      │  EFI  │
     │_______│         │_______│             │_______│
    
    BOOTX64.efi        grubx64.efi        grubx64_real.efi
    
    (Kaspersky     (FileAuthentication         (GRUB2)
      Loader)        override)
    
        ↓↓↓                ↑
                           ↑
       ______              ↑
      ╱│     │             ║
     /_│     │             ║
     │       │  ═══════════╝
     │  EFI  │
     │_______│
    
     fde_ld.efi + custom chain.mod
    
    (Kaspersky GRUB2)


    Заключение

    В этой статье мы выяснили, что существуют недостаточно надежные загрузчики, подписанные ключом Microsoft, разрешающим работу в режиме Secure Boot.
    С помощью подписанных файлов Kaspersky Rescue Disk мы добились «тихой» загрузки любых недоверенных .efi-файлов при включенном Secure Boot, без необходимости добавления сертификата в UEFI db или shim MOK.
    Эти файлы можно использовать как для добрых дел (для загрузки с USB-флешек), так и для злых (для установки буткитов без ведома владельца компьютера).
    Предполагаю, что сертификат Касперского долго не проживет, и его добавят в глобальный список отозванных сертификатов UEFI, который установят на компьютеры с Windows 10 через Windows Update, что нарушит загрузку Kaspersky Rescue Disk 18 и Silent UEFIinSecureBoot Disk. Посмотрим, как скоро это произойдет.

    Скачать Super UEFIinSecureBoot Disk: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
    Скачать Silent UEFIinSecureBoot Disk в сети ZeroNet Git Center: http://127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/

    Про ZeroNet
    ZeroNet — очень мощная система создания децентрализованных распределенных динамических веб-сайтов и сервисов. При посещении какого-либо ресурса, пользователь начинает его скачивать и раздавать, как в BitTorrent. При этом, возможно создание полноценных ресурсов: блогов с комментариями, форумов, видеохостингов, wiki-сайтов, чатов, email, git.
    ZeroNet разделяет понятия кода и данных сайта: пользовательские данные хранятся в .json-файлах, а при синхронизации импортируются в sqlite-базу данных сайта со стандартизированной схемой, что позволяет делать умопомрачительные вещи: локальный поиск текста по всем когда либо открытым сайтам за миллисекунды, автоматический real-time аналог RSS для всех сайтов разом.
    Стандартизированная система аутентификации и авторизации (похожа на OAuth), поддержка работы за NAT и через Tor.
    ZeroNet очень быстро работает, дружелюбен к пользователю, имеет современный интерфейс и мелкие, но очень удобные фишки, вроде глобального переключения дневной/ночной темы на сайтах.

    Я считаю ZeroNet очень недооцененной системой, и намеренно публикую Silent-версию только в ZeroNet Git, для привлечения новых пользователей.
    Поделиться публикацией

    Похожие публикации

    Комментарии 61

      –2
      Великолепно! Ещё раз доказывает странность такого вот хитровыделанного vendor lock-in.
        +5
        Это не Vendor Lock. Secure Boot — разумная технология, обеспечивающая первый бастион защиты операционной системы, которая может в том числе защищать и запущенную ОС, если ОС поддерживает Secure Boot, например, в Linux можно настроить загрузку только доверенных модулей ядра, ключ которых есть в UEFI db.
        Её можно отключить на всех магазинных платах, если она вам не нужна.
          0
          Под вендор локом я подразумевал прошивку ключей Microsoft по умолчанию. Почему они?
          Ладно ещё, когда компьютер поставляется в сборе с предустановленной Windows, но в других случаях…
          Я конечно понимаю, что хомя непродвинутым пользователям так проще, но можно же было придумать какой-то другой путь, например как в ssh: при попытке загрузки бинарника с неизвестным ключом UEFI бы спрашивал «а вы точно доверяете вот этому-этому?».
          У самого настроен «кошерный» secure boot с правильными ключами, без всяких шимов.
            0
            Ладно ещё, когда компьютер поставляется в сборе с предустановленной Windows, но в других случаях…
            Ответ простой: какая, по вашему система будет использоваться в 90% случаев? 10% щедро отдадим Linux, Hackintosh и прочей экзотике.

            Поэтому, подстраиваются под удобство подавляющего большинства (удобство = не докучать пользователю лишними, с его точки зрения вопросами после каждого обновления загрузчика + хоть как-то защиить его от вредоносного загрузчика), а пара процентов пользователей, которым требуются собственные ключи, явно способны удалить ключи по умолчанию.
              +4
              Ну поэтому я и предложил альтернативу: «Вы доверяете Microsoft Inc? Продолжаем устанавливать Windows?».
              Ну или хотя бы не так сильно палились и вшивали бы ключ абстрактной UEFI Signing Foundation, которая бы верифицировала все остальные загрузчики.

              А то получается «Каждому родившемуся на территории России сразу выдывать карточку Сбербанка, ну а что, в 90% случаев она ему нужна».
                0
                А UEFI Signing Foundation кто-то спросил, хочет ли она этим заниматься?

                Кстати, интересно, наличие сертификатов MS это частная инициатива вендоров или требование спецификации? Если первое, то c UEFI Forum взятки гладки.

                Ну поэтому я и предложил альтернативу: «Вы доверяете Microsoft Inc? Продолжаем устанавливать Windows?».
                Вы думаете, хомяпользователи будут читать? Они будут жать «Да» даже в том случае, когда там уже не загрузчик Microsoft, а загрузчик малвари. Именно поэтому и выбрано решение, которое от чайника не требует ничего, а продвинутому пользователю даёт возможность настройки по вкусу.
                  +5
                  Насколько знаю, как раз никто не захотел заниматься аудитом и подписью загрузчиков, и всё как-то само передалось Microsoft.
                  В UEFI требований по сертификатам нет как таковых, требование есть у Microsoft, для сертификации компьютера под Windows 10.
                  Некоторые материнские платы содержат ключи Canonical и Red Hat.
                    0
                    Насколько знаю, как раз никто не захотел заниматься аудитом и подписью загрузчиков, и всё как-то само передалось Microsoft.
                    Причём Microsoft'у это тоже очень быстро надоело, и теперь проверка шима у них отдана на откуп тем же RedHat'у и Canonical, а сами MS только подпись лепят, когда получат от них добро. Да и то, даже в этом косячить умудряются.
            –1
            И виртуализация есть и jit и minux установлен и ещё куча всего. А платформо-независимых драйверов нет, что бы из коробки всё что впаяно в плату гарантировано работало под любой OS.

            А разумным бастионом защиты операционной системы должна была быть флешка на материнке и перемычка на плате, которая апартно запрещает изменять любые данные на ней.
              +1
              А разумным бастионом защиты операционной системы должна была быть флешка на материнке и перемычка на плате, которая апартно запрещает изменять любые данные на ней.
              Это удорожает конечный продукт. То есть, вы получаете несколько процентов аудитории, которая понимает, что это такое и готова за это переплатить, но теряете гораздо большую часть, которой эта безопасность до лампочки.

              Экономия уже дошла до того, что практически все вендоры начали просто распаивать микросхему на материнке (с выводом гребёнки для программатора) вместо гораздо более удобного варианта «микросхема в кроватке». Видимо, так на несколько центов дешевле.
                0
                Добавлю, что это не только удорожает продукт, но и делает автоматические обновления невозможными в принципе, потому что от пользователя требуется нетривиальное (т.е. не «нажмите Ввод») физическое присутствие, которое невозможно обеспечить либо по причине «у пользователя лапки», либо потому, что система установлена в дата-центре в закрытый шкаф.
                  0
                  А с чего вы решили что автоматические обновления это хорошо?
                  (asus live update неплохой пример заботы о пользователях)
                  Вы в биос в дата центре тоже удаленно заходите?
                    +4
                    Удивительный вопрос, я даже несколько теряюсь. Ручные обновления = отсутствие обновлений = известные и эксплуатируемые уязвимости, которые значительно хуже, чем новые, еще не известные и не эксплуатируемые. Если вы готовы сами следить за обновлениями и нести ответственность за безопасность системы — я только за, но вас таких снова три с половиной, а защитить хоть как-нибудь и закрыть хотя бы известные дыры стараются для всех. UEFI Forum разработал и внедрил общих механизм для обновления всех компонентов прошивки — ESRT, которым пользуются клиенты вроде Windows Update и Linux Vendor Firmware Service. Очень жаль, что поддерживаются эти сервисы пока далеко не всеми, потому что нужны они еще вчера.

                    В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
                    –1
                    Автоматическое обновление _загрузчика_ будет невозможно.
                    Почему-то обновление ядра линукса не требует переустановки груба — достаточно поправить в текстовом конфиге, что грузить дальше.
                    Да и обновление всего остального тоже без проблем.
                    Система вполне сможет обновлять автоматически, если нет обновлений grub/другого загрузчика (на моей памяти — примерно раз в два года в debian/stable).
            +1
            Один из них используется в Kaspersky Rescue Disk 18

            Можно засекать через сколько времени будет отозвана подпись загрузчика Касперского?
            Как часто вообще вендоры обновляют список отозванных сертификатов в UEFI? Это только с обновлением прошивки материнской платы происходит?
              0
              Предполагаю, что сертификат Касперского долго не проживет, и его добавят в глобальный список отозванных сертификатов UEFI, который установят на компьютеры с Windows 10 через Windows Update, что нарушит загрузку Kaspersky Rescue Disk 18 и Silent UEFIinSecureBoot Disk. Посмотрим, как скоро это произойдет.

              Microsoft распространяет этот лист через Windows Update, на компьютеры с Windows 10. Windows Update вшивает их в материнскую плату.
                0
                обязательное требование для изменения его настроек — физическое присутствие за компьютером. Необходимо зайти в настройки UEFI при загрузке компьютера, и только тогда получится отключить технологию или изменить её настройки.

                Получается, что не сильно то и обязательное?
                  0
                  Ну одно дело revocation list, а другое дело добавление нового trusted сертификата. Одно ограничивает, другое разрешает.
                +3
                Чтобы подпись отозвали, проблему надо зарепортить UEFI Security Response Tem.
                Как только проблему подтвердят, хеш начального загрузчика Касперского (который компрометирует UEFI CA) будет добавлен в UEFI Revocation List File, который затем MS постарается распространить на все машины с ключом MS KEK (на другие он просто не установится) через Windows Update.
                  0
                  Мне теперь стало интересно как происходит перезапись этих обновлений. Скачал и обновил ОСь, обновились записи в UEFI Revocation List File, снес ОСь… Качаю новые обновления и что там дальше происходит? А если обновления уже интегрированы в образ? Оно перезаписывается или записи просто дублируются?
                    0
                    У gRT->SetVariable, функции, которую ОС вызывает для того, чтобы в NVRAM писать, есть флаг APPEND_WRITE, который позволяет к уже имеющимся revocation list'ам дописать новых записей. Т.к. записи эти хранятся в NVRAM, который в свою очередь хранится на SPI-чипе материнской платы, переустановка ОС не меняет их значений. Если значения там уже есть, SetVariable вернет EFI_SUCCESS, но менять ничего не будет, так что и не перезаписываются, и не дублируются, на самом деле.

                    Если хотите подробностей, все это описано подробно в спецификации UEFI 2.3.1C+ в разделе Runtime Services: SetVariable.
                      0
                      Большое спасибо, пойду почитаю
                0

                Интересно, долго ли (и как?) пришлось искать дырявое подписанное комбо preloader-grub :)

                  +4
                  Где-то неделя. Качал всё подряд, что загружается, и смотрел состав.
                  0
                  Я считаю ZeroNet очень недооцененной системой, и намеренно публикую Silent-версию только в ZeroNet Git, для привлечения новых пользователей.

                  Нам и в Одноклассниках неплохо.
                    +1
                    Кому это нам? С этой конторой лучше дело не иметь, чтоб не сесть за лайки и репосты.
                    +1
                    Большое спасибо за статью, прочитал с интересом. Как раз недавно хотел разобраться что из себя представляет PreLoader.efi, который я обнаружил ковыряясь в ArchLinux'овском iso.
                    Хотя при чтении было ощущение что где-то подвох (смотрим на календарь :).
                      +1
                      Спасибо за статью, особенно за этот замечательный загрузчик Касперского, который теперь надо бы забанить по хорошему, потому что цепочка эта фактически уничтожает последние остатки доверия к подписям с корнем на UEFI CA.

                      Проблема эта известная, радикальное решение — не доверять UEFI CA совсем (Apple и Microsoft на своих машинах поступают именно так). При этом начнутся сложности с работой OptionROM'ов внешних видеокарт и рейд-контролеров, которые в UEFI 2.4+ можно обойти при помощи SecureBoot Deployment Mode, либо подписыванием ОРОМов своими ключами и загрузкой их с диска или SPI-флеша, а не из устройства.

                      В общем, теоретически решения есть, и все можно сделать, если очень хотеть. Практически же, за исключением трех с половиной анонимов, UEFI SecureBoot отключен на всех ПК, потому что любая технология, которая одновременно опциональна, досаждает пользователю, и легко отключаема — будет отключена навсегда при первом же досадном случае, что и происходит.
                        0
                        Ну да, к сожалению. Вообще получается что хотелка ValdikSS (грузить что угодно) противоречит всей изначальной задумке Secure Boot (т. е. не дать загрузить что угодно). А кто этого хочет, тот чаще всего отключает secure boot вместо настройки своих ключей. Например я =( Знаю, что надо по хорошему всё сделать, и статьи про это у меня в закладках давно, но руки так и не дошли пока.

                        CodeRush А можно тебе как знатоку UEFI задать оффтопный вопрос:
                        1) Я вот никогда не видел ноутбука с поддержкой мыши в uefi setup. Все что я видел мимикрируют под интерфейс legacy bios. А на десктопах всё наоборот. Почему так?
                        2) Если не ошибаюсь, ты где-то говорил что uefi позволяет существенно сократить время загрузки системы при использовании raid контроллеров. Это как-то связано с выбором типа OpROM (Legacy/Uefi) в uefi setup?
                          0
                          Тем не менее, по пункту 1 у меня ноутбук с поддержкой мыши в UEFI Setup.
                            0
                            1) Полно таких ноутбуков, а под старый текстовый интерфейс мимикрируют потому, что IBV так захотели. На десктопах давно уже AMI правит бал, и потому там давно уже вакханалия с OpenGL в Setup и GIFами анимированными, а на ноутбуках еще используют Phoenix и Insyde, которые по умолчанию выглядят «как встарья», и которые надо переделывать под мышь самому. Dell, к примеру, переделывает, а другие не парятся.
                            Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.

                            2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.
                              0
                              1) Ясно. Я как раз видел ноуты с прошивками от Phoenix и Insyde, и Dell'овские не попадались, потому спросил. А кто определяет что нравится людям? Отдел маркетинга? Мне эти блёстки не нужны, просто любопытно было. Меня поразило однажды: увидел на одном десктопе в uefi интерфейсе Веб браузер (!) и Skype (!!!). Нахрена??? Предполагалось что по нему будет звонить те, кому лень поставить OS? Это риторический вопрос конечно.
                              А ещё AMI я вижу на серверах (supermicro), но там нет этого всего с OpenGL. Я вообще CSM давно бы отключил везде, но сейчас его актуальность обусловлена только необходимостью обновления «bios» из dos'а. Почему-то производитель предлагает инструкции под DOS. Хотя я в интернете видел прошивальщик AMI, работающий через uefi shell. Я его не пробовал ещё (как-то стрёмно :)), но хотел более внимательно изучить. Как считаешь, можно ли просто так взять его, и прописав такие же параметры как прописаны в батниках с досовским прошивальщиком обновить uefi?

                              2) Ну я могу провести бенчмарки. Я просто хотел узнать, правильно ли что я переключал эту опцию или могло что-то ещё влиять. Ты говоришь что это зависит от количества подключенных к контроллеру дисков? Я просто переключать уже пробовал, но разницы особо не почувствовал — что так, что так раздражающе долго платформа перезапускается. Хотя опять же, у supermicro на некоторых материнках как-то криво сделано в настройках что не поймёшь, какой OROM в итоге загрузился.
                                0
                                По первому пункту у асрока в их интерфейсе висит аж настройка VPN-а, ну а в пример серверных частей, если 3d со стразами и пукающими единорогами не вымораживает, то можно посмотреть на HP, графики в setup там добавили по минимуму, но вот прошивка управления это линукс, в котором крутятся иксы, в которых крутится фаерфокс(вроде как он), плюс всякое «прикручу везде jsonчик, оберну я всё в ajax». Ну и (спорно весьма)приятная фишка — опятьже через эту утиль HPE предлагает накатывать операционную систему (при этом оно из прошивки вытаскивает туда драйвера).
                            0
                            особенно за этот замечательный загрузчик Касперского, который теперь надо бы забанить по хорошему, потому что цепочка эта фактически уничтожает последние остатки доверия к подписям с корнем на UEFI CA.
                            А он не единственный такой ;)
                              0
                              Никто другого и не ждал, за 7 лет с запуска UEFI CA им успели подписать такое количество всякой дырявой фигни, что доверять ему теперь — то еще решение. При этом не будешь доверять — OROMы перестанут запускаться, т.е. технология сразу переходит из разряда «включил и работает» в «требует постоянного внимания администратора», и потому отключать ее начнут теперь еще более яростно.
                                +1
                                Как и говорилось, что хочешь безопасности — удаляй дефолтные ключи и переподписывай всё (и опромы) на своём.
                            0
                            С одной стороны спасибо конечно, но с другой стороны как-то действительно можно скачать с ZeroNet?
                            Просто в описании все ссылки ведут на github, а в разделе релизов
                            http://127.0.0.1:43110/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/repo/releases/?1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv
                            пусто?
                              0
                              Репозиторий silent, файлы в папке filesystem_kaspersky.
                                0
                                так в первую очередь попробовал, но кнопка Download не работает в папках, а попытка взять zip по аналогии с гитхабом не удалась…
                                  0
                                  Вверху есть кнопка clone, которая показывает команду для выполнения git clone.
                                  git clone $path_to_zeronet_data_folder/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/silent-uefiinsecureboot-disk.git -b silent
                                    0
                                    Аж пришлось зарегаться, чтобы спросить, потому что не помогают ни гугл, ни инструкция на офсайте. Всё равно непонятно, как сделать git clone. Что ИМЕННО надо подставить вместо $path_to_zeronet_data_folder? Я уж все варианты перепробовал, которые придумал
                                      0
                                      Путь до папки «data» в папке zeronet.
                                      Пример для Windows:
                                      git clone C:\ZeroNet\data\1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv\silent-uefiinsecureboot-disk.git -b silent
                                        +1
                                        Семён Семёныч!!! (С) Бриллиантовая Рука

                                        Получилось, огромное спасибо. Я-то думал, 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-ом пользовался
                              0
                              Responsible Disclosure прямо налицо.
                                0
                                По моему мнению, проблема не настолько значительная, чтобы придерживаться ответственного подхода к её сообщению. Она нишевая, способна приченить урон в ограниченных случаях и особых условиях.
                                Со стороны Касперского устранить проблему нельзя, только писать в UEFI, с просьбой о добавлении хеша или сертификата в список отзыва.
                                Прежде всего интересно, сколько времени займет обновление списка отзыва в случае публичного сообщения о проблеме.
                                  0
                                  Напиши им про это сам, пожалуйста, потому что дойти до них может с заметным опозданием (если хочешь, чтобы починили, конечно).
                                    0
                                    Касперскому в твиттер напишите.
                                    0
                                    Подумайте ещё раз.
                                    Прежде всего интересно, сколько времени займет обновление списка отзыва в случае публичного сообщения о проблеме.

                                    Конечно интересно! Ретроспективный отзыв сертификата, который инвалидирует подписанные файлы за последние 3 года- это же так весело, что может пойти не так? Ведь вы же учли все возможные сценарии использования!
                                      0
                                      В UEFI dbx можно добавлять не только сертификаты, но и хеши конкретных запускаемых через StartImage файлов. Именно так было сделано с загрузчиками Windows в 2016.
                                      Можно отозвать только GRUB (fde_ld.efi), разрешающий загрузку модулей, но не сам пред-загрузчик Касперского (BOOTX64.efi).
                                        0
                                        Где-то выше, коллега по цеху упоминал что на практике все выродилось в то, что ШИМ все делали не безопасно. Справедливо и обратное утверждение. UEFI реализован чуть лучше чем плохо. Гарантии даете что этот механизм будет работать надежно? И что никто не пострадает?
                                          0
                                          Любой отзыв это серьёзный риск. У меня был случай когда ошибочно отозвали сертификат не с указанной даты а ретроспективно. Просто CA пропустило мимо мозга дату отзыва. Пока они исправили ошибку было не очень приятно. А здесь, где процедуры выпуска апдейтов третьими лицами ещё задействованы…
                                          +2
                                          Вы работаете в Касперском?
                                          Правильно ли я понимаю, судя по названию файла fde_ld.efi, этот загрузчик был создан для Kaspersky Endpoint Business, и был переиспользован для Kaspersky Rescue Disk?
                                          Отзыв этого файла сломает загрузку с шифрованного диска в Kaspersky Endpoint Business?
                                          0
                                          По моему мнению, проблема не настолько значительная, чтобы придерживаться ответственного подхода к её сообщению.
                                          Зачем тогда надо было статью об этом писать?

                                          И да, проблема значительная. Я за два года до публикации о баге в NTFS отрапортовал в Microsoft и дважды спросил разрешения на публикаю. Я конечно не люблю порой корпорации за их поведение, и не редко бывают причины так действовать, но простые пользователи тут не причем. Видимо плюсики дороже.

                                          Ждем Petya2.
                                            +1
                                            Зачем тогда надо было статью об этом писать?
                                            Чтобы обратить внимание на существование подписанных загрузчиков, позволяющих загружать что угодно. Механизм подписей пред-загрузчиков для Secure Boot, с теми требованиями, какие выдвигались к ним, несостоятельны. Всё основывается на доверии подписывающей стороны (Microsoft) к компании, и Microsoft не проверяет, что вы будете загружать в качестве второго загрузчика. Технически удостовериться, что компания не начнет подписывать всё что угодно ключом, включенным в пред-загрузчик, невозможно до обнаружения такого загрузчика.
                                            В SSL-сертификатами в вебе было то же самое, пока не сделали Certificate Transparency и различные системы обнаружения аномалий с сертификатами в браузерах.

                                            Как видно, Kaspersky подписал обычный GRUB, вероятно, даже не задумываясь, что делает что-то неправильно. И загрузчик от Касперского — не единственный такой.

                                            Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.

                                            Я за два года до публикации о баге в NTFS отрапортовал в Microsoft и дважды спросил разрешения на публикацию. Я конечно не люблю порой корпорации за их поведение, и не редко бывают причины так действовать, но простые пользователи тут не причем.
                                            Вашу ошибку в NTFS можно использовать без прав администратора, и, возможно, даже удалённо, через какой-то софт.
                                            На подмену EFI-загрузчика требуются права администратора в ОС (как в Windows, так и в Linux), злоумышленник должен написать свой буткит+руткит, и должен его ещё как-то использовать из ОС. Такая сложная процедура бессмысленна для атак на обычных пользователей — если у злоумышленника и так есть администраторский доступ в ОС, он просто выполнит необходимые действия в ОС, а не через загрузчик.
                                            Это имеет смысл только при узконаправленных целевых атаках с дополнительным сокрытием (APT), которые не применяются массово, и не направленых на обычных пользователей.
                                              0
                                              Чтобы обратить внимание на существование подписанных загрузчиков, позволяющих загружать что угодно.
                                              Чье внимание? Разработчики и комитет UEFI и так все это знают. Вы нам нового ничего не рассказали. А простым пользователям эта информация никакой ценности не несет.

                                              Механизм подписей пред-загрузчиков для Secure Boot, с теми требованиями, какие выдвигались к ним, несостоятельны.
                                              Ну так и UEFI не состоялся. С ним намного больше проблем чем с BIOS. Все в практику уперлось. А стандарт разумный.

                                              Всё основывается на доверии подписывающей стороны (Microsoft) к компании, и Microsoft не проверяет, что вы будете загружать в качестве второго загрузчика.
                                              Отвечать должна Microsoft(по совести). Т.к. на себя замкнула подпись. Но только это к ним вопросы должны быть. Направленные.

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

                                              даже не задумываясь, что делает что-то неправильно
                                              А вы когда делаете что-то не так всегда это сознаете?

                                              Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.
                                              Никак вообще. Деньги только в большем объеме брать будут.

                                              Вашу ошибку в NTFS можно использовать без прав администратора, и, возможно, даже удалённо, через какой-то софт.
                                              Нет, нужен физический доступ к ПК. Она не критичная. А популярной она стала только потому что собрались любители покритиковать. Ну и любители пополнения контентов своих сайтов. Раздули из мухи слона. Всем нужна истерика.

                                              На подмену EFI-загрузчика требуются права администратора в ОС (как в Windows, так и в Linux), злоумышленник должен написать свой буткит+руткит, и должен его ещё как-то использовать из ОС.
                                              Видимо Petya как-то иначе работал. Пойду изучать.
                                                0
                                                Чье внимание? Разработчики и комитет 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
                                                0
                                                >Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.
                                                Для EFI-модулей всегда было требование на EV сертификаты. Там ещё и процесс нетривиальный.
                                            0
                                            Корректнее сказать «на лицо».
                                            0
                                            Скачать Silent UEFIinSecureBoot Disk в сети ZeroNet Git Center: 127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/

                                            Я извиняюсь, а Silent в ZeroNet был залит по каким-то соображениям безопасности?
                                              0
                                              См. текст в самом низу статьи, в спойлере.
                                              +1
                                              В новых версиях Kaspersky Rescue Disk теперь используется обычный, не подписанный GRUB2, который не загружается в Secure Boot.

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое