path: root/russian/security/2020-GRUB-UEFI-SecureBoot/index.wml

#use wml::debian::template title="Уязвимость GRUB2 UEFI SecureBoot — 'BootHole'"
#use wml::debian::translation-check translation="9c47c948da90cea57112872aa23f03da3a967d7b" maintainer="Lev Lamberov"

<p>
Разработчики Debian и других дистрибутивов сообщества Linux недавно
узнали о серьёзной проблеме в загрузчике GRUB2, позволяющей
злоумышленнику полностью обойти UEFI Secure Boot. Подробности
касательно этой проблемы описаны в
in <a href="$(HOME)/security/2020/dsa-4735">рекомендации по безопасности Debian
4735</a>. Цель настоящего документа состоит в объяснении последствий
данной уязвимости, а также того, какие шаги следует предпринять для её
исправления.
</p>

<ul>
  <li><b><a href="#what_is_SB">Общая информация: что такое UEFI Secure Boot?</a></b></li>
  <li><b><a href="#grub_bugs">Обнаружение многочисленных ошибок GRUB2</a></b></li>
  <li><b><a href="#linux_bugs">Обнаружение ошибок Linux</a></b></li>
  <li><b><a href="#revocations">Необходимость отзыва ключей для исправления цепочки Secure Boot</a></b></li>
  <li><b><a href="#revocation_problem">Каковы последствия отзыва ключей?</a></b></li>
  <li><b><a href="#package_updates">Обновлённые пакеты</a></b>
  <ul>
    <li><b><a href="#grub_updates">1. GRUB2</a></b></li>
    <li><b><a href="#linux_updates">2. Linux</a></b></li>
    <li><b><a href="#shim_updates">3. Shim</a></b></li>
    <li><b><a href="#fwupdate_updates">4. Fwupdate</a></b></li>
    <li><b><a href="#fwupd_updates">5. Fwupd</a></b></li>
  </ul></li>
  <li><b><a href="#buster_point_release">Редакция Debian 10.5 (<q>buster</q>),
        обновлённые установочные носители и <q>живые</q>
        образы</a></b></li>
  <li><b><a href="#more_info">Дополнительная информация</a></b></li>
</ul>

<h1><a name="what_is_SB">Общая информация: что такое UEFI Secure Boot?</a></h1>

<p>
UEFI Secure Boot (SB) представляет собой механизм проверки, гарантирующий что
запускаемый UEFI-микропрограммой компьютера код является доверенным. Он разработан
для защиты системы от вредоносного кода, загружаемого и исполняемого
достаточно рано в процессе старта и до загрузки операционной
системы.
</p>

<p>
SB работает с использованием криптографических контрольных сумм и подписей. Каждая
программа, загружаемая микропрограммой, содержит подпись и контрольную сумму.
Перед тем, как разрешить исполнение, микропрограмма выполняет проверку того, что
запускаемая программа является доверенной. Это осуществляется путём проверки контрольной
суммы и подписи. Если SB включён в системе, то любая попытка выполнить
недоверенную программу будет запрещена. Это позволяет предотвратить
запуск непредусмотренного / неавторизованного кода в UEFI-окружении.
</p>

<p>
Большинство оборудования с архитектурой x86 поставляется с завода с предустановленными
ключами Microsoft. Это означает, что микропрограмма в такой системе доверяет двоичным
файлам, подписанным Microsoft. Большинство современных систем поставляются с включённым
механизмом SB, по умолчанию они не запускают какой-либо неподписанный код. Однако
можно изменить настройки микропрограммы и либо отключить SB, либо
зарегистрировать дополнительные ключи.
</p>

<p>
Debian, как и многие другие операционные системы на основе Linux, использует программу,
называемую shim, для расширения доверия от микропрограммы до других программ,
которые нам требуется обезопасить в ходе ранней загрузки &mdash; это загрузчик GRUB2,
ядро Linux и инструменты обновления микропрограмм (fwupd и
fwupdate).
</p>

<h1><a name="grub_bugs">Обнаружение многочисленных ошибок GRUB2</a></h1>

<p>
К сожалению, в коде загрузчика GRUB2 для чтения и грамматического разбора
файла настроек (grub.cfg) была обнаружена серьёзная ошибка, которая
ломает цепочку доверия. Используя эту ошибку можно выйти из защищённого
окружения и загрузить неподписанные программы в ходе ранней загрузки.
Эта уязвимость была обнаружены исследователями Eclypsium и получила
название <b><a href="https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/">BootHole</a></b>.
</p>

<p>
Вместо исправления одной этой ошибки разработчики решили провести
тщательный аудит исходного кода GRUB2. Было бы безответственно
исправить одну серьёзную уязвимость без поиска других ошибок!
Команда инженеров на протяжении нескольких недель работала над выявлением
и исправлением целого ряда проблем. Мы обнаружили несколько мест, где
выделенные буферы внутренней памяти могут быть переполнены при получении неожиданных
входных данных, несколько мест, где переполнение целых чисел в ходе математических
вычислений может приводить к проблемам, а также несколько мест, где память может
использоваться после её освобождения. Исправления всех этих ошибок были
распространены между участниками сообщества и протестированы.
</p>

<p>
Полный список проблем можно найти в <a href="$(HOME)/security/2020/dsa-4735">рекомендации
по безопасности Debian 4735</a>.
</p>


<h1><a name="linux_bugs">Обнаружение ошибок Linux</a></h1>

<p>
В ходе обсуждения уязвимостей в GRUB2, разработчики говорили и о двух возможностях
обхода защиты, которые недавно были обнаружены и исправлены Джейсоном Донефельдом (zx2c4)
(<a href="https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language.sh">1</a>,
<a href="https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh">2</a>),
когда ядро Linux может позволить обойти Secure Boot. Обе уязвимости позволяют суперпользователю
заменить таблицы ACPI в заблокированной системе, когда это не должно быть разрешено. Исправления
этих проблем уже выпущены.
</p>

<h1><a name="revocations">Необходимость отзыва ключей для исправления цепочки Secure Boot</a></h1>

<p>
Очевидно, Debian и другие поставщики операционных систем <a
href="#package_updates">выпустят исправленные версии</a> GRUB2 и
Linux. Тем не менее на этом исправление проблем не завершается.
Злоумышленники всё ещё могут быть способны использовать предыдущие уязвимые
версии загрузчика и ядра, чтобы обойти Secure Boot.
</p>

<p>
Для предотвращения этого следующим шагом будет внесение сотрудниками Microsoft небезопасных
двоичных файлов в список блокировки, чтобы они не могли быть запущены при включённом SB.
Это достигается с помощью списка <b>DBX</b>, который является частью UEFI Secure Boot.
Все дистрибутивы Linux, поставляющие подписанные Microsoft копии shim,
должны предоставить подробную информацию о двоичных файлах или используемых ключах,
чтобы указанные действия были выполнены. Будет обновлён <a
href="https://uefi.org/revocationlistfile">UEFI-файл со списком отозванных ключей</a>,
обновление будет содержать предоставленную информацию. Позднее, <b>некоторый</b>
момент времени, системы начнут использовать этот обновлённый список и перестанут
запускать уязвимые двоичные файлы при использовании Secure Boot.
</p>

<p>
<i>Точный</i> срок развёртывания этого изменения пока не ясен.
В какой-то момент поставщики BIOS/UEFI добавят новый список отозванных ключей в новые сборки
микропрограмм для нового оборудования. Microsoft <b>может</b>
выпустить обновления для существующих систем через Windows Update. Некоторые
дистрибутивы Linux также могут выпустить обновления через свои собственные
системы обновления безопасности. Debian <b>пока</b> этого не сделал, но мы
собираемся сделать это в будущем.
</p>

<h1><a name="revocation_problem">Каковы последствия отзыва ключей?</a></h1>

<p>
Большинство поставщиков с недоверием относятся к автоматическому применению
обновлений, которые отзывают ключи, используемые для Secure Boot. Существующие
наборы ПО могут неожиданно перестать загружаться при включённом SB, если
пользователь также не установил требуемые обновления ПО. Двойная
загрузка систем Windows/Linux тоже может неожиданно прекратить загрузку
Linux. Конечно же, старые установочные образы и <q>живые</q> тоже перестанут
загружаться, что потенциально усложнит восстановление систем.
</p>

<p>
Имеются два очевидных способа исправления незагружающейся системы:
</p>

<ul>
  <li>Перезагрузиться в режиме <q>восстановления</q>,
    используя <a href="#buster_point_release">более новые установочные носители</a>,
    и применить необходимые обновления; или</li>
  <li>Временно отключить Secure Boot для получения доступа к системе,
    применить обновления, а затем заново включить SB.</li>
</ul>

<p>
Оба пути могут вначале показаться простыми, однако каждый из них потребует
некоторого количества времени, особенно от пользователей нескольких систем.
Кроме того, помните, что для включения или отключения
Secure Boot требуется непосредственный доступ к машине. Обычно
<b>нельзя</b> изменить эту настройку извне системы настройки микропрограммы
компьютера. Удалённые серверные машины могут потребовать специального
обращения по этой самой причине.
</p>

<p>
По этим причинам настоятельно рекомендуется, чтобы <b>все</b> пользователи
Debian установили все <a href="#package_updates">рекомендованные обновления</a> для
своих систем как можно скорее. Это позволит снизить вероятность возникновения
проблем в будущем.
</p>

<h1><a name="package_updates">Обновлённые пакеты</a></h1>

<p>
<b>ВНИМАНИЕ:</b> системы, использующие Debian 9 (<q>stretch</q>) и более ранние
выпуски <b>необязательно</b> получат соответствующие обновления, поскольку Debian 10
(<q>buster</q>) является первым выпуском Debian, включающим поддержку UEFI
Secure Boot.
</p>

<p>Были обновлены подписанные версии всех пакетов, даже если никакие
другие изменения не требовались. Debian пришлось создать новый ключ/сертификат
для подписывания собственных пакетов, поддерживающих Secure Boot. Старый сертификат
был помечен как <q>Debian Secure Boot Signer</q> (отпечаток ключа
<code>f156d24f5d4e775da0e6a9111f074cfce701939d688c64dba093f97753434f2c</code>);
новый сертификат помечен как <q>Debian Secure Boot Signer 2020</q>
(<code>3a91a54f9f46a720fe5bbd2390538ba557da0c2ed5286f5351fe04fff254ec31</code>). </p>

<p>
В Debian имеются пять пакетов с исходным кодом, которые будут обновлены
в связи с изменениями UEFI Secure Boot:
</p>

<h2><a name="grub_updates">1. GRUB2</a></h2>

<p>
Обновлённые версии Debian-пакетов GRUB2 доступны уже сейчас в архиве
debian-security для стабильного выпуска Debian 10
(<q>buster</q>). Исправленные версии очень скоро появятся в обычном архиве Debian
для разрабатываемых версий Debian (нестабильного и тестируемого).
</p>

<h2><a name="linux_updates">2. Linux</a></h2>

<p>
Обновлённые версии Debian-пакетов linux доступны уже сейчас через
buster-proposed-updates для стабильного выпуска Debian 10 (<q>buster</q>)
и будут включены в готовящуюся редакцию 10.5. Новые пакеты
также находятся в архиве Debian для разрабатываемых версий
Debian (нестабильного и тестируемого). Мы надеемся, что исправленные пакеты
будут вскоре загружены в buster-backports.
</p>

<h2><a name="shim_updates">3. Shim</a></h2>

<p>
Учитывая механизм управления ключами Secure Boot в Debian, Debian
<b>не</b> требуется отзывать существующие и подписанные Microsoft
пакеты shim. Тем не менее подписанные версии пакетов shim-helper
необходимо собрать заново с использованием нового ключа.
</p>

<p>
Обновлённые версии Debian-пакетов shim доступны уже сейчас через
buster-proposed-updates для стабильного выпуска Debian 10 (<q>buster</q>)
и будут включены в готовящуюся редакцию 10.5. Новые пакеты
также находятся в архиве Debian для разрабатываемых версий
Debian (нестабильного и тестируемого).
</p>

<h2><a name="fwupdate_updates">4. Fwupdate</a></h2>

<p>
Обновлённые версии Debian-пакетов fwupdate доступны уже сейчас через
buster-proposed-updates для стабильного выпуска Debian 10 (<q>buster</q>)
и будут включены в готовящуюся редакцию 10.5. Пакет fwupdate уже был
удалён из нестабильного и тестируемого выпусков в связи с его заменой
на пакет fwupd.
</p>

<h2><a name="fwupd_updates">5. Fwupd</a></h2>

<p>
Обновлённые версии Debian-пакетов fwupd доступны уже сейчас через
buster-proposed-updates для стабильного выпуска Debian 10 (<q>buster</q>)
и будут включены в готовящуюся редакцию 10.5. Новые пакеты
также находятся в архиве Debian для разрабатываемых версий
Debian (нестабильного и тестируемого).
</p>

<h1><a name="buster_point_release">Редакция Debian 10.5 (<q>buster</q>),
обновлённые установочные носители и <q>живые</q> образы</a></h1>

<p>
Все описанные здесь обновления планируется включить в редакцию
Debian 10.5 (<q>buster</q>), который будет выпущен 1 августа 2020 года.
Таким образом, пользователям, которым нужны установочные и <q>живые</q>
образы Debian следует выбирать 10.5. В будущем более ранние образы могут
не работать с Secure Boot, так как будет выполнен отзыв ключей.
</p>

<h1><a name="more_info">Дополнительная информация</a></h1>

<p>
Дополнительную информацию о настройке UEFI Secure Boot в Debian
можно найти в вики Debian по адресу <a href="https://wiki.debian.org/SecureBoot">\
https://wiki.debian.org/SecureBoot</a>.</p>

<p>
Другие ресурсы по данной теме:
</p>

<ul>
  <li><a href="https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/">Статья Eclypsium
      <q>BootHole</q></a>, описывающая обнаруженные уязвимости</li>
  <li><a href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011">Руководство
      Microsoft по решению пробем обхода безопасности в GRUB</a></li>
  <li><a href="https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass">Статья
      в базе знаний Ubuntu</a></li>
  <li><a href="https://access.redhat.com/security/vulnerabilities/grub2bootloader">Статья
      об уязвимости от Red Hat</a></li>
  <li><a href="https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/">Статья
      об уязвимости от SUSE</a></li>
</ul>