[LCFC] wml://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/index.wml
Obrigado pela revisão, Charles.
Todas fizeram sentido, foram modificadas.
Segue o arquivo para últimas considerações.
Abraços,
Thiago Pezzo (Tico)
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 5, 2020 2:52 AM, <charlesmelara@outlook.com> wrote:
> Boa noite, Thiago.
>
> On Mon, Aug 03, 2020 at 12:04:34PM -0300, charlesmelara@outlook.com wrote:
>
> > Olá,
> > farei a revisão. Mas durante a semana é um pouco mais complicado, então
> > pode demorar uns dias.
>
> Consegui terminar a revisão até que rapidamente.
>
> Fiz algumas sugestões de alteração, as mais notáveis são em relação ao
> "bootloader do GRUB2" e sobre as mídias atualizadas.
>
> Como o GRUB2 é o bootloader, retirei o "do". E quando ele fala das
> mídias atualizadas, tanto a de instalção, quanto a live(-CD) foram
> atualizadas.
>
> Também há um detalhe no patch, na segunda sugestão em @@ -83,14 +83,14@@
> eu deixei com mais de 80 colunas porque, se eu fosse quebrar corretamente,
> teria que alterar até o fim do parágrafo e geraria um diff gigante pra
> você procurar qual alteração fiz. Então se você aceitar a sugestão,
> peço que faça essa quebra.
>
> No mais, são só detalhes.
>
> Obrigado pela tradução,
> Charles
#use wml::debian::template title="Vulnerabilidade de SecureBoot do GRUB2 UEFI - 'BootHole'"
<p>
Os(As) desenvolvedores(as) no Debian e em outras comunidades Linux ficaram
cientes recentemente de um problema severo no bootloader GRUB2 que
permite que um interveniente nocivo contorne o boot seguro UEFI (UEFI Secure
Boot). Os detalhes completos do problema estão descritos no
<a href="$(HOME)/security/2020/dsa-4735">alerta de segurança Debian
4735</a>. O objetivo deste documento é explicar as consequências desta
vulnerabilidade de segurança e apresentar os passos que foram tomados
para remediá-la.
</p>
<ul>
<li><b><a href="#what_is_SB">Contexto: o que é o boot seguro UEFI?</a></b></li>
<li><b><a href="#grub_bugs">Múltiplos bugs do GRUB2 encontrados</a></b></li>
<li><b><a href="#linux_bugs">Bugs do Linux também encontrados</a></b></li>
<li><b><a href="#revocations">Revogações de chave necessárias para corrigir a cadeia de boot seguro</a></b></li>
<li><b><a href="#revocation_problem">Quais são os efeitos de revogação de chave?</a></b></li>
<li><b><a href="#package_updates">Pacotes atualizados</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">Lançamento pontual
Debian 10.5 (<q>buster</q>), mÃdias de instalação e live
atualizadas</a></b></li>
<li><b><a href="#more_info">Mais informações</a></b></li>
</ul>
<h1><a name="what_is_SB">Contexto: o que é o boot seguro UEFI?</a></h1>
<p>
O boot seguro UEFI (UEFI Secure Boot - SB) é um mecanismo de verificação
para garantir que o código executado por um firmware do UEFI do computador
é confiável. � projetado para proteger um sistema contra código malicioso
sendo carregado e executado cedo no processo de boot, antes do sistema
operacional ter sido carregado.
</p>
<p>
O SB funciona usando um checksum (soma de verificação) criptográfico e
assinaturas. Cada programa que é carregado pelo firmware inclui uma assinatura e
um checksum, e antes de permitir a execução, o firmware verificará se o
programa é confiável pela validação do checksum e da assinatura.
Quando o SB está habilitado em um sistema, qualquer tentativa de executar
um programa não confiável não será permitida. Isto bloqueia códigos
não esperados / não autorizados de rodarem no ambiente UEFI.
</p>
<p>
A maior parte do hardware X86 vem de fábrica com as chaves da Microsoft
pré-carregadas. Isto significa que o firmware desses sistemas confiarão
nos binários que foram assinados pela Microsoft. A maioria dos sistemas
será enviada com o SB habilitado - eles não executarão qualquer código
não assinado por padrão, mas é possÃvel alterar a configuração do firmware
para, ou desabilitar o SB, ou adicionar chaves de assinatura extras.
</p>
<p>
O Debian, como muitos outros sistemas operacionais baseados em Linux, usa um
programa chamado shim para estender essa confiança do firmware para outros
programas que nós precisamos que estejam seguros durante o boot inicial: o
carregador de boot (bootloader) GRUB2, o kernel do Linux e ferramentas de
atualização de firmware (fwupd e fwupdate).
</p>
<h1><a name="grub_bugs">Múltiplos bugs do GRUB2 encontrados</a></h1>
<p>
Infelizmente, um bug sério foi encontrado no código do bootloader
GRUB2 que lê e analisa o arquivo de configuração dele (grub.cfg). Este bug
quebra a cadeia de confiança; ao explorar esse bug, é possÃvel
romper com o ambiente seguro e carregar programas não assinados
durante o boot inicial. Esta vulnerabilidade foi descoberta por
pesquisadores(as) do Eclypsium e dado o nome de
<b><a href="https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/";>BootHole</a></b>.
</p>
<p>
Em vez de somente corrigir este bug, os(as) desenvolvedores(as) foram
demandados(as) a fazer uma auditoria em profundidade do código-fonte do GRUB2.
Seria irresponsável corrigir uma grande falha sem também procurar outras!
Um time de engenheiros(as) trabalhou por várias semanas para identificar e
reparar uma gama de problemas adicionais. Nós encontramos alguns lugares nos
quais alocações internas de memória poderiam estourar com entradas não
esperadas, muitos outros lugares onde um estouro de inteiro em cálculos
matemáticos poderia causar problemas, e alguns poucos lugares onde a memória
poderia ser usada após ser liberada. Correções para tudo isso foram
compartilhadas e testadas entre a comunidade.
</p>
<p>
Novamente, veja o <a href="$(HOME)/security/2020/dsa-4735">alerta de segurança
Debian 4735</a> para uma lista completa de problemas encontrados.
</p>
<h1><a name="linux_bugs">Bugs do Linux também encontrados</a></h1>
<p>
Enquanto discutia-se as falhas do GRUB2, os(as) desenvolvedores(as) também
falaram sobre dois desvios recentemente encontrados e corrigidos por Jason A.
Donenfeld (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>)
nos quais o Linux também poderia permitir a evasão do boot seguro. Esses dois
desvios permitem ao root que substitua tabelas ACPI em um sistema bloqueado
quando isto não deveria ser permitido. Correções já foram lançadas para esses
problemas.
</p>
<h1><a name="revocations">Revogações de chave necessárias para corrigir a cadeia de boot seguro</a></h1>
<p>
O Debian e outros(as) fornecedores(as) de sistemas operacionais obviamente <a
href="#package_updates">lançarão versões corrigidas</a> do GRUB2 e do
Linux. Entretanto, isto pode não ser uma correção completa para os problemas
vistos aqui. Intervenientes maliciosos ainda serão capazes de usar versões mais
antigas e vulneráveis para contornar o boot seguro.
</p>
<p>
Para impedir isso, o próximo passo será a Microsoft colocar na lista de
bloqueio aqueles binários inseguros para que sejam barrados na execução sob o
SB. Isto é alcançado usando a lista <b>DBX</b>, uma funcionalidade do projeto
do boot seguro UEFI. Todas as distribuições Linux enviadas com cópias do shim
assinadas pela Microsoft foram demandadas a fornecer detalhes dos binários ou
chaves envolvidas para facilitar este processo. O <a
href="https://uefi.org/revocationlistfile";>arquivo da lista de revogação
UEFI</a> será atualizado para incluir esta informação. Em <b>algum</b>
ponto no futuro, os sistemas começarão a usar aquela lista atualizada e
recusarão a executar os binários vulneráveis sob o boot seguro.
</p>
<p>
A linha do tempo <i>exata</i> para que esta mudança seja implementada não está
clara ainda. Os(As) fornecedores(as) de BIOS/UEFI incluirão a nova lista de
revogação nas novas construções de firmware para novos hardwares em algum
momento. Também a Microsoft <b>talvez possa</b> enviar atualizações para
sistemas existentes via atualizações do Windows. Algumas distribuições Linux
podem enviar atualizações através de seus próprios processos de atualizações
de segurança. O Debian <b>ainda</b> não fez isso, mas nós estamos examinando
a situação para o futuro.
</p>
<h1><a name="revocation_problem">Quais são os efeitos de revogação de chave?</a></h1>
<p>
A maior parte dos(as) fornecedores(as) são cautelosos(as) sobre aplicações
automáticas de atualizações que revoguem as chaves usadas no boot seguro.
Instalações existentes de software com SB habilitado podem, repentinamente,
recusar o boot completamente, a menos que o(a) usuário(a) seja cuidadoso(a)
em também instalar todas as necessárias atualizações de software. Sistemas
Windows/Linux em dual boot podem repentinamente parar o boot do Linux.
MÃdias de instalação e live antigas também, é claro, falharão no boot,
potencialmente fazendo com que seja mais difÃcil a recuperação de sistemas.
</p>
<p>
Existem duas maneiras óbvias de consertar um sistema como este que não
inicializa:
</p>
<ul>
<li>Novo boot no modo de <q>recuperação</q>
usando <a href="#buster_point_release">mÃdias mais novas de instalação</a> e
aplicando as atualizações necessárias; ou</li>
<li>Desabilitando temporariamente o boot seguro para retomar o acesso ao
sistema, aplicar as atualizações e reabilitá-lo.</li>
</ul>
<p>
Ambas podem parecer opções simples, mas cada uma pode consumir muito
tempo para usuários(as) com múltiplos sistemas. Também esteja ciente de que, por
projeto, habilitar e desabilitar o boot seguro são ações que necessitam de
acesso direto à máquina. Normalmente, <b>não</b> é possÃvel alterar essa
configuração fora da configuração de firmware do computador. Máquinas de
servidores remotos podem precisar de cuidado extra aqui, por essa mesma razão.
</p>
<p>
Devido a esses motivos, é altamente recomendado que <b>todos(as)</b>
usuários(as) Debian sejam cautelosos(as) e instalem todas
as <a href="#package_updates">atualizações recomendadas</a> para seus
sistemas tão logo quanto possÃvel, para reduzir as chances de problemas
no futuro.
</p>
<h1><a name="package_updates">Pacotes atualizados</a></h1>
<p>
<b>Nota:</b> sistemas executando o Debian 9 (<q>stretch</q>) e mais antigos
<b>não</b> necessariamente receberão atualizações aqui, já que o Debian 10
(<q>buster</q>) foi o primeiro lançamento do Debian a incluir suporte para boot
seguro UEFI.
</p>
<p>
Aqui, as versões assinadas de todos os pacotes foram atualizadas, mesmo que
nenhuma outra alteração tenha sido necessária. O Debian teve que gerar uma nova
chave/certificado de assinatura para seus próprios pacotes de boot seguro. O
certificado antigo foi rotulado de <q>Debian Secure Boot Signer</q> (fingerprint
<code>f156d24f5d4e775da0e6a9111f074cfce701939d688c64dba093f97753434f2c</code>);
o novo certificado é o <q>Debian Secure Boot Signer 2020</q>
(<code>3a91a54f9f46a720fe5bbd2390538ba557da0c2ed5286f5351fe04fff254ec31</code>).
</p>
<p>
Há cinco pacotes-fonte no Debian que serão atualizados devido
às alterações do boot seguro UEFI descritas aqui:
</p>
<h2><a name="grub_updates">1. GRUB2</a></h2>
<p>
As versões atualizadas do pacote GRUB2 do Debian estão disponÃveis agora
através do repositório debian-security para o lançamento do Debian 10 estável
(<q>buster</q>). Versões corrigidas logo estarão no repositório normal do Debian
para as versões de desenvolvimento do Debian (instável e teste).
</p>
<h2><a name="linux_updates">2. Linux</a></h2>
<p>
As versões atualizadas dos pacotes linux do Debian estão disponÃveis agora
através do repositório buster-proposed-updates para o lançamento do Debian 10
estável (<q>buster</q>) e serão incluÃdas na versão pontual 10.5 que está por
vir. Novos pacotes também estão no repositório do Debian para versões de
desenvolvimento do Debian (instável e teste). Nós também esperamos que pacotes
corrigidos sejam enviados em breve para buster-backports.
</p>
<h2><a name="shim_updates">3. Shim</a></h2>
<p>
Devido ao funcionamento especÃfico da administração de chaves do boot seguro do
Debian, o Debian <b>não</b> precisa revogar seus pacotes existentes do shim
assinados pela Microsoft. Contudo, as versões assinadas dos pacotes shim-helper
precisaram de reconstrução para usar a nova chave de assinatura.
</p>
<p>
As versões atualizadas dos pacotes shim do Debian estão disponÃveis agora
através do repositório buster-proposed-updates para o lançamento do Debian 10
estável (<q>buster</q>) e serão incluÃdas na versão pontual 10.5 que está por
vir. Novos pacotes também estão no repositório do Debian para versões de
desenvolvimento do Debian (instável e teste).
<h2><a name="fwupdate_updates">4. Fwupdate</a></h2>
<p>
As versões atualizadas dos pacotes fwupdate do Debian estão disponÃveis agora
através do repositório buster-proposed-updates para o lançamento do Debian 10
estável (<q>buster</q>) e serão incluÃdas na versão pontual 10.5 que está por
vir. O fwupdate já tinha sido removido da instável e da teste um tempo atrás,
substituÃdo por fwupd.
</p>
<h2><a name="fwupd_updates">5. Fwupd</a></h2>
<p>
As versões atualizadas dos pacotes fwupd do Debian estão disponÃveis agora
através do repositório buster-proposed-updates para o lançamento do Debian 10
estável (<q>buster</q>) e serão incluÃdas na versão pontual 10.5 que está por
vir. Novos pacotes também estão no repositório do Debian para versões de
desenvolvimento do Debian (instável e teste).
</p>
<h1><a name="buster_point_release">Lançamento pontual
Debian 10.5 (<q>buster</q>), mÃdias de instalação e live
atualizadas</a></h1>
<p>
Todas as correções descritas aqui estão marcadas para inclusão na
versão pontual Debian 10.5 (<q>buster</q>), pronta para lançamento em
1 de agosto de 2020. A 10.5 seria, portanto, uma boa escolha para os(as)
usuários(as) que procuram mÃdia do Debian para instalação e live. Imagens
anteriores talvez não funcionem com boot seguro no futuro, assim que as
revogações forem lançadas.
</p>
<h1><a name="more_info">Mais informações</a></h1>
<p>
Muitas outras informações sobre a configuração do boot seguro do Debian estão no
wiki do Debian - veja
<a href="https://wiki.debian.org/SecureBoot";>https://wiki.debian.org/SecureBoot</a>.</p>
<p>
Outras fontes (em inglês) sobre este tópico incluem:
</p>
<ul>
<li><a href="https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/";>artigo
<q>BootHole</q> da Eclypsium</a> descrevendo a vulnerabilidade encontrada</li>
<li><a href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011";>orientação
da Microsoft para abordar o desvio da funcionalidade de segurança no GRUB</a></li>
<li><a href="https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass";>artigo
da KnowledgeBase do Ubuntu</a></li>
<li><a href="https://access.redhat.com/security/vulnerabilities/grub2bootloader";>artigo
da vulnerabilidade do Red Hat</a></li>
<li><a href="https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/";>artigo
da vulnerabilidade do SUSE</a></li>
</ul>
Reply to: