Visão geral de como as imagens de firmware são estruturadas

Uma imagem de firmware é uma coleção de arquivos e sistemas de arquivos contendo software que opera hardware. Muitas vezes, inclui ficheiros comprimidos, executáveis e ficheiros de sistema. Esses sistemas de arquivos podem ou não incluir outros sistemas de arquivos em cada arquivo. Por exemplo, uma imagem de firmware que é um arquivo .zip pode incluir arquivos individuais, como executáveis dentro dele, mas também pode incluir outros sistemas de arquivos compactados, como um arquivo SquashFS. Você pode visualizá-lo da seguinte forma:

Captura de ecrã do aspeto do sistema de ficheiros de uma imagem de firmware.

Cada círculo representa um arquivo que pode ou não ter mais sistemas de arquivos dentro dele. O extrator extrai repetidamente cada círculo até que não haja mais círculos (ficheiros) dentro dele para serem extraídos.

Se o oval grande e abrangente representar a imagem de firmware, os três círculos dentro do oval grande podem representar sistemas de arquivos individuais dentro desta imagem de firmware. Os círculos podem até representar executáveis com sistemas de arquivos incorporados dentro deles.

Devido à estrutura complexa das imagens de firmware – qualquer camada pode ser um executável ou um sistema de arquivos com outro executável ou sistema de arquivos incorporado – precisamos de uma maneira abrangente de apresentar os resultados da extração para refletir com precisão a estrutura de uma imagem de firmware.

Como funciona o extrator

O extrator de análise de firmware identifica e descomprime os dados encontrados nas imagens de firmware. Existem vários tipos de extratores, um para cada tipo de arquivo. Para obter uma lista completa dos formatos de ficheiro suportados pela análise de firmware, consulte Perguntas mais frequentes sobre a análise de firmware.

Por exemplo, um ZipArchive extrator extrairia um ZipArchive ficheiro. O extrator extrai a imagem à medida que ela fica no disco do seu sistema, e você precisará correlacionar o caminho do arquivo com a estrutura dos arquivos em seu ambiente de compilação. Quando carrega as imagens de firmware para o serviço de análise de firmware, o extrator extrai recursivamente a imagem até que não possa extrair mais. Isso significa que a imagem do firmware original é descompactada em arquivos individuais, e cada arquivo individual é enviado novamente para o extrator para ver se eles podem ser descompactados ainda mais. Isto repete-se até que o extrator não consiga descomprimir mais.

Às vezes, pode haver vários arquivos concatenados em um. Extrator irá identificar que existem vários arquivos nesse arquivo, e usar o extrator apropriado para extrair cada arquivo, em seguida, colocar cada arquivo em seu próprio diretório respetivo. Isso significa que, se houver quatro arquivos que foram compilados com GZip, e eles foram concatenados em um arquivo, o extrator identificará que há quatro GZip arquivos nesse nível de extração. O Extrator colocará o primeiro GZip arquivo em um diretório chamado GZipExtractor/1, o segundo em um diretório chamado GZipExtractor/2, e assim por diante.

Interpretar caminhos de arquivo criados pelo extrator

No serviço de análise de firmware, a visualização SBOM dos resultados da análise contém os caminhos do arquivo:

Captura de ecrã da vista SBOM nos resultados da análise de firmware.

Aqui está um exemplo de um caminho de arquivo que pode ser visto nos resultados da análise e como visualizar o caminho em uma estrutura de sistema de arquivos:

Captura de tela de um caminho de arquivo de exemplo pelo extrator.

A seguinte estrutura do sistema de arquivos é uma representação visual do caminho do arquivo SBO:

Captura de tela de uma estrutura de sistema de arquivos de exemplo.

Neste caminho de arquivo de exemplo, uma ZipArchiveExtractor extraída ZipArchive, e coloca o conteúdo em um diretório chamado ZipArchiveExtractor/1. Mais uma vez, o «1» significa que este foi o primeiro – e, possivelmente, o único – ZipArchive ficheiro a este nível de extração. O extrator atribui um nome padrão chamado zip-root para o ZipArchive arquivo.

Captura de tela do zip-root no sistema de arquivos.

Nota

Normalmente, você pode assumir que um subdiretório com o sufixo -root é criado pelo Extrator e não existe realmente em seu ambiente. É apenas um subdiretório criado pelo Extrator para armazenar o conteúdo desse tipo de arquivo.

Dentro zip-root está o adhoc ficheiro:

Captura de tela dos arquivos zip-root e adhoc no sistema de arquivos.

Dentro do adhoc arquivo está o lede-17.01.4-arc770-generic-nsim-initramfs.elf arquivo:

Captura de tela dos arquivos adhoc e lede no sistema de arquivos.

Como o lede… arquivo termina com .extracted, isso significa que há algo dentro desse .elf arquivo que precisa ser extraído ainda mais. O próximo extrator usado foi um CPIOArchiveExtractor, o que significa que havia um CPIOArchive sistema de arquivos incorporado no .elf arquivo. O conteúdo do CPIOArchive arquivo foi colocado em um cpio-root subdiretório:

Captura de tela do arquivo cpio-root no sistema de arquivos.

e dentro do CPIOArchive arquivo, havia um bin arquivo, e esse bin arquivo tinha um arquivo nomeado busybox dentro dele:

Captura de tela dos arquivos cpio-root, bin e busybox no sistema de arquivos.

Localize o caminho em seu ambiente

Como o primeiro extrator que foi usado foi um ZipArchiveExtractor, isso significa que tudo existe em um Zip arquivo. Localize o Zip arquivo e, dentro dele, o caminho completo em seu ambiente seria /adhoc/lede-17.01.4-arc770-generic-nsim-initramfs.elf.extracted/bin/busybox. No entanto, suponha que apenas consegue ver o primeiro nível de extração - o ficheiro .elf. Para ver mais longe, você precisaria de seu próprio extrator para extrair além da primeira camada. Isso significa que, de forma tangível, o caminho do arquivo para ir seria: /adhoc/lede-17.01.4-arc770-generic-nsim-initramfs.elf.

Vários caminhos extratores

Em alguns casos, você pode notar um (+1) ou (+2) ao lado do caminho do arquivo:

Captura de tela de um SBOM com vários caminhos.

Ao passar o mouse sobre o número, você verá um pop-up semelhante a este:

Captura de tela dos vários caminhos de um SBOM.

Isso significa que o SBOM pode ser encontrado nesses dois caminhos executáveis.

Como as capacidades de análise UEFI afetam os caminhos dos extratores

O firmware UEFI (Unified Extensible Firmware Interface) difere de outros tipos de firmware na estrutura e conteúdo. Uma única imagem de firmware UEFI pode conter:

  • Módulos específicos do UEFI
  • Outros formatos executáveis embutidos no firmware (por exemplo, binários ELF do Linux)

Como resultado, os resultados da análise de firmware — e os caminhos dos extratores mostrados na vista SBOM — podem incluir uma mistura de tipos executáveis dentro da mesma análise.

Para o firmware UEFI, as melhorias do caminho do extrator são atualmente fornecidas como uma capacidade de Pré-visualização . Quando disponíveis, os caminhos extratores podem incluir:

  • O nome do módulo UEFI
  • Identificadores baseados em GUID usados internamente pelo firmware UEFI

Estas melhorias destinam-se a melhorar a clareza ao correlacionar entradas SBOM com módulos UEFI. No entanto, podem não aparecer em todas as imagens de firmware ou em todos os módulos.

Nota

Como as melhorias no caminho do extrator UEFI estão em Prévia, a cobertura pode estar incompleta. Nomes ou caminhos de módulos em falta devem ser interpretados como desconhecidos, não como evidência de que um componente está ausente.

Relação entre a cobertura da análise UEFI e os caminhos dos extratores

As capacidades de análise UEFI variam consoante a maturidade das características:

  • A deteção de certificados e chaves criptográficas embutidas no firmware UEFI está Geralmente Disponível (GA)
  • Extração de SBOM, deteção de fraquezas, atributos de hardening binário e melhorias no caminho dos extratores para o firmware UEFI estão atualmente em Prévia

Como os dados SBOM e de fraqueza do firmware UEFI são derivados de componentes detetados:

  • Os CVEs podem aparecer apenas para componentes cujas versões possam ser identificadas com confiança
  • Algumas linhas SBOM podem ter dados em falta ou parciais
  • Alguns caminhos extratores podem aplicar-se apenas a executáveis não UEFI embutidos no firmware

Valores em falta ou vazios em linhas relacionadas com UEFI devem ser interpretados como desconhecidos, e não como confirmação de que uma funcionalidade de segurança está ausente ou que uma vulnerabilidade não existe.