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 que contêm software que opera hardware. Geralmente, ela inclui arquivos compactados, arquivos executáveis e arquivos do 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 dela, mas também pode incluir outros sistemas de arquivos compactados, como um arquivo SquashFS. Você pode visualizar isso da seguinte maneira:

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 (arquivos) 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 poderão representar sistemas de arquivos individuais dentro dessa imagem de firmware. Os círculos podem até representar executáveis com sistemas de arquivos inseridos dentro deles.

Devido à complexa estrutura de imagens de firmware – qualquer camada específica pode ser um executável ou um sistema de arquivos com outro sistema de arquivos ou executável inserido – 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 o Extrator funciona

O extrator de análise de firmware identifica e descompacta os dados encontrados nas imagens de firmware. Há vários tipos de extratores, um para cada tipo de arquivo. Para ver uma lista completa de formatos de arquivo compatíveis com a análise de firmware, consulte Perguntas frequentes sobre a análise de firmware.

Por exemplo, um extrator ZipArchive extrairia um arquivo ZipArchive. O extrator extrai a imagem conforme ela está no disco em seu sistema e você precisará correlacionar o caminho do arquivo à estrutura de arquivos em seu ambiente de build. Quando você carrega suas imagens de firmware no serviço de análise de firmware, o extrator extrai recursivamente a imagem até que ela não possa mais ser extraída. Isso significa que a imagem de firmware original é descompactada em arquivos individuais e cada arquivo individual é enviado novamente ao extrator para ver se ele pode ser descompactado ainda mais. Isso se repete até que o extrator não possa descompactar ainda mais.

Às vezes, pode haver vários arquivos concatenados em um único arquivo. O extrator identificará que há vários arquivos nesse arquivo e usará o extrator apropriado para extrair cada arquivo e, em seguida, colocará cada arquivo em seu próprio diretório. Isso significa que, se houver quatro arquivos compilados com GZip e concatenados em um único arquivo, o extrator identificará que há quatro arquivos GZip nesse nível de extração. O extrator colocará o primeiro arquivo GZip 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, o modo de exibição SBOM dos resultados da análise contém os caminhos de arquivo:

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 do sistema de arquivos:

A estrutura do sistema de arquivos a seguir é uma representação visual do caminho de arquivo SBOM:

Neste caminho de arquivo de exemplo, um ZipArchiveExtractor extraiu um ZipArchive, e ele coloca o conteúdo em um diretório chamado ZipArchiveExtractor/1. Novamente, o "1" significa que este foi o primeiro – e possivelmente, o único – arquivo ZipArchive neste nível de extração. O extrator atribui um nome padrão chamado zip-root ao arquivo ZipArchive.

Observação

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

Dentro de zip-root está o arquivo adhoc:

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

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

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

Localizar o caminho no seu ambiente

Como o primeiro extrator usado foi um ZipArchiveExtractor, isso significa que tudo existe em um arquivo Zip. Localize o arquivo Zip 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 você só possa ver o primeiro nível de extração – o arquivo .elf. Para ver mais, você precisaria do seu próprio extrator para extrair além da primeira camada. Isso significa que, tangivelmente, o caminho do arquivo para o qual ir seria: /adhoc/lede-17.01.4-arc770-generic-nsim-initramfs.elf.

Vários Caminhos do Extrator

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

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

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

Como os recursos de análise UEFI afetam os caminhos do extrator

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

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

Como resultado, os resultados da análise de firmware e os caminhos do extrator mostrados na visualização SBOM podem incluir uma combinação de tipos executáveis na mesma análise.

Para o firmware UEFI, no momento, os aprimoramentos no caminho do extrator são fornecidos como um recurso em versão preliminar. Quando disponível, os caminhos do extrator podem incluir:

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

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

Observação

Como os aprimoramentos do caminho do extrator da UEFI estão em Versão Preliminar, a cobertura pode estar incompleta. Nomes ou caminhos de módulo ausentes 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 do extrator

Os recursos de análise uefi variam de acordo com a maturidade do recurso:

• A detecção de certificados criptográficos e chaves inseridos no firmware UEFI está com Disponibilidade Geral (GA)
• No momento, a extração de SBOM, detecção de pontos fracos, atributos de proteção de binários e aprimoramentos no caminho do extrator para o firmware UEFI estão em Versão Preliminar

Como os dados de SBOM e de fraqueza para firmware UEFI são derivados de componentes detectados:

• Os CVEs podem aparecer apenas para componentes cujas versões podem ser identificadas com confiança
• Algumas linhas SBOM podem ter dados ausentes ou parciais
• Alguns caminhos do extrator podem ser aplicados somente a executáveis não UEFI inseridos no firmware

Valores ausentes ou vazios em linhas relacionadas à UEFI devem ser interpretados como desconhecidos, não como confirmação de que um recurso de segurança está ausente ou uma vulnerabilidade não existe.