Recentemente, no GoTo Chicago, dei uma palestra sobre esse assunto e pensei que seria bom escrever um artigo com conclusões. Este post é sobre por que o firmware de código aberto é importante para a segurança.
Níveis de privilégio
Em uma pilha típica, você tem diferentes níveis de privilégio.
- Anel 3. Aplicações: privilégios mínimos, com exceção da sandbox no espaço do usuário, que é ainda mais limitado.
- Anel 0. Kernel: o kernel do sistema operacional, no caso de um SO de código aberto, você vê seu código.
- Anel -1. Hypervisor: Virtual Machine Monitoring (VMM), cria e executa máquinas virtuais. Em hipervisores de código aberto, como Xen, KVM, bhyve e outros, você vê o código.
- Anel -2. SMM (System Management Mode), núcleo UEFI: código proprietário, mais sobre isso abaixo.
- Anel -3. Mecanismo de controle: código proprietário, mais sobre isso abaixo.
Anéis negativos indicam níveis com privilégios maiores que zero.
Pelo exposto, fica claro que nos anéis de 1 a 3, temos a oportunidade de usar software de código aberto, em grande parte ver e controlá-lo. Para níveis abaixo do anel -1, temos menos controle, mas a situação está melhorando graças ao desenvolvimento de firmware de código aberto e à comunidade.
Esta é uma situação contraditória: o código mais fechado tem mais privilégios em nosso sistema. Esse paradoxo deve corrigir o firmware de código aberto.Anel -2. SMM, núcleo UEFI
Este anel controla todos os recursos da CPU.
O Modo de Gerenciamento do Sistema (SMM) é invisível para o restante da pilha em cima dele. Tem metade do núcleo. Originalmente usado para gerenciamento de energia e controle de hardware do sistema. Ele contém muitos códigos proprietários e é o local em que os fornecedores adicionam novos recursos proprietários. Ele lida com eventos do sistema, como erros de memória ou chipset, além de várias outras lógicas.
O núcleo UEFI é extremamente complexo, com milhões de linhas de código. Os aplicativos UEFI estão ativos após o download. O núcleo foi desenvolvido com o princípio de "segurança através da obscuridade".
A especificação é absolutamente insana se você quiser vasculhar.
Anel -3. Mecanismo de controle
O anel mais privilegiado. No caso da Intel (x86), esse é o Intel Management Engine. Este sistema pode ativar silenciosamente os nós e substituir discos, o kernel inicia o
Minix 3 , além de um servidor da Web e toda a pilha de rede. Acontece que, graças a isso, o Minix é o sistema operacional de desktop mais popular. O mecanismo de controle tem muitas funções. Provavelmente levarei um dia inteiro para listá-los. Se você quiser, existem
muitos recursos para um estudo mais detalhado.
Entre o anel -2 e o anel -3 em nossa pilha, existem pelo menos dois outros kernels e meio, além de um monte de complexidade proprietária e desnecessária. Cada um desses núcleos possui suas próprias pilhas de rede e servidores da web. O código pode mudar sozinho, persistindo após desligar a energia e reinstalar.
Temos muito pouca informação sobre o que o código realmente faz nesses anéis, o que é terrível, uma vez que esses anéis têm mais privilégios.Todos eles têm façanhas
Não deve surpreender ninguém que haja vulnerabilidades nos anéis -2 e -3. Quando eles são encontrados, é realmente terrível. Apenas como exemplo, embora você possa procurar outros exemplos, houve
um erro no servidor web do Intel Management Engine que o desenvolvedor não conhecia há sete anos .
Como a situação pode ser melhorada?
NERF: Firmware Reduzido Não Extensível
NERF é o que a comunidade está trabalhando. O objetivo é tornar o firmware menos capaz de causar danos e tornar suas ações mais visíveis. Eles se esforçam para remover todos os componentes do tempo de execução, mas isso ainda é difícil de fazer no Intel Management Engine. Mas você pode remover o servidor da Web e a pilha de IP de lá. Os desenvolvedores também desejam remover a pilha IP UEFI, outros drivers e remover o recurso de auto-firmware Intel Management / UEFI.
me_cleaner
Projeto para limpar o Intel Management Engine com a funcionalidade mínima exigida (
no GitHub ).
u-boot e coreboot
u-boot e
coreboot são firmware de código aberto. Eles lidam com inicialização de chip e DRAM. Os Chromebooks usam ambos, coreboot no x86 e u-boot no restante. Esta é uma das etapas que eles
verificam quanto ao carregamento .
A filosofia de design do Coreboot é
“tornar o mínimo necessário para usar o hardware e depois transferir o controle para outro programa chamado carga útil ” . Nesse caso, é linuxboot.
linuxboot
O Linuxboot lida com drivers de dispositivo, a pilha de rede e fornece um ambiente multi-tarefa para múltiplos usuários. Ele é construído no Linux, para que um único núcleo possa ser executado em várias placas. O Linux já foi suficientemente testado e muitas pessoas seguem o código, pois é amplamente utilizado. É melhor usar um núcleo aberto com um grande número de "controladores" do que dois outros kernels e meio, diferentes e fechados. Isso significa que reduzimos a superfície de ataque devido a menos variantes de código e dependemos do código-fonte aberto. O Linux melhora a confiabilidade da inicialização, substituindo drivers de firmware mal testados por drivers Linux aprimorados.
Usando o kernel, já temos ferramentas de firmware: os desenvolvedores podem usar ferramentas familiares quando precisam escrever lógica para verificar assinaturas, criptografar um disco e assim por diante. Tudo isso em uma linguagem moderna, testada, suportada e fácil de ler.
u-root
u-root é o kit de ferramentas e o gerenciador de inicialização golang userspace. É usado como initramfs para o kernel Linux no linuxboot.
Eles dizem que a pilha NERF reduziu o tempo de inicialização em 20 vezes. Mas este é um artigo de segurança, então vamos voltar à segurança ...
A pilha NERF melhora a visibilidade de muitos componentes que eram anteriormente completamente proprietários. No entanto, os dispositivos ainda possuem muitos outros firmware.
E quanto a outro firmware?
Precisamos de um firmware aberto para o Network Interface Controller (NIC), Solid State Drives (SSD) e Basic Management Controller (BMC).
O projeto Open Compute está fazendo algum trabalho no firmware da
NIC 3.0 . Será interessante ver o que eles fazem.
Existem o
OpenBMC e o
u-bmc para o BMC . Eu escrevi um pouco sobre eles em um
artigo anterior .
Precisamos ter todo o firmware de código aberto para garantir visibilidade total na pilha e verificar o status do software na máquina.
Raízes de confiança
O objetivo da raiz da confiança é verificar se o software apropriado está instalado em cada componente do equipamento. Você pode garantir que o equipamento não seja invadido. Como agora temos muito código fonte fechado em muitas áreas do equipamento, isso é difícil de fazer. Como realmente saber que não há vulnerabilidades ou backdoors no firmware do componente? De jeito nenhum. Código aberto é outra coisa.
Parece que cada nuvem e cada fornecedor oferece sua própria raiz de confiança. A Microsoft tem
Cerberus , o Google tem
Titan , a Amazon tem
Nitro . Eles parecem implicar confiança explícita no código proprietário (código que não vemos). Isso deixa uma sensação estranha.
Não seria melhor usar código-fonte totalmente aberto? Em seguida, podemos verificar sem dúvida que o código compilado a partir do código fonte é o mesmo que funciona no equipamento onde quer que o firmware esteja instalado. Depois, podemos verificar se a máquina está no estado correto, sem duvidar de que esteja vulnerável ou com uma porta dos fundos.Isso faz você pensar que pequenos fornecedores de nuvem, como DigitalOcean ou Packet, usam como raiz da confiança. Perguntei sobre isso no Twitter, mas não recebi uma resposta decente ...
Há uma ótima palestra de
Paul McMillan e Matt King
sobre segurança do equipamento ao dimensionar . Os autores descrevem em detalhes como proteger o hardware e, ao mesmo tempo, fornecem aos clientes acesso a ele. Quando recebem equipamentos de volta dos clientes, eles precisam garantir de forma consistente e confiável que tudo permaneça inalterado e que nenhuma surpresa oculta nenhum componente.
Todos os provedores de nuvem devem garantir que o equipamento não seja comprometido após o cliente fazer cálculos.
Tolerância a falhas de firmware da plataforma
No entanto, os fabricantes de chips parecem ter uma aparência especial. A Intel possui
resiliência de firmware de plataforma e Lattice tem
resiliência de firmware de plataforma . Eles parecem estar mais focados nas diretrizes do NIST para
tolerância a falhas do firmware da plataforma .
Tentei perguntar na Internet quem o usou, mas recebi poucas respostas; portanto, se você usar dispositivos com a tecnologia de resiliência de firmware de plataforma, informe-me!
A partir da
palestra do
OCP sobre inovações no firmware da Intel, parece que a Platform Firmware Resilience (PFR) da Intel e Cerberus andam de mãos dadas. A Intel usa PFR para implementar os Princípios de Certificação Cerberus. Obrigado
@msw pelo esclarecimento.
Seria bom reduzir a variedade de ferramentas manchadas para fazer esse trabalho. Eu também gostaria de ver o código fonte para ver por si mesmo que é seguro.
Como ajudar
Espero que você tenha uma idéia de quais projetos existem para o desenvolvimento de firmware de código aberto e de quão importante é! Se você quer ajudar, por favor, conte aos outros. Tente usar plataformas de código aberto. Os Chromebooks são um ótimo exemplo, assim como os computadores
Purism . Você pode perguntar aos seus fornecedores o que eles fazem para liberar o firmware de código aberto e garantir a segurança do equipamento com uma raiz de confiança. Feliz nerd! :)