Vulnerabilidade no firmware do controlador BMC afetando servidores de vários fabricantes

Empresa Eclypsium revelado duas vulnerabilidades no firmware do controlador BMC fornecido nos servidores Lenovo ThinkServer, permitindo que um usuário local altere o firmware ou execute código arbitrário no lado do chip BMC.

Análises mais aprofundadas mostraram que esses problemas também afetam o firmware dos controladores BMC usados ​​nas plataformas de servidores Gigabyte Enterprise Servers, que também são usados ​​em servidores de empresas como Acer, AMAX, Bigtera, Ciara, Penguin Computing e sysGen. Os controladores BMC problemáticos usavam firmware MergePoint EMS vulnerável desenvolvido pelo fornecedor terceirizado Avocent (agora uma divisão da Vertiv).

A primeira vulnerabilidade é causada pela falta de verificação criptográfica das atualizações de firmware baixadas (apenas a verificação de checksum CRC32 é usada, ao contrário recomendações NIST usa assinaturas digitais), o que permite que um invasor com acesso local ao sistema falsifique o firmware do BMC. O problema, por exemplo, pode ser usado para integrar profundamente um rootkit que permanece ativo após a reinstalação do sistema operacional e bloqueia futuras atualizações de firmware (para eliminar o rootkit, você precisará usar um programador para reescrever o flash SPI).

A segunda vulnerabilidade está presente no código de atualização do firmware e permite substituir seus próprios comandos, que serão executados no BMC com maior nível de privilégios. Para atacar, basta alterar o valor do parâmetro RemoteFirmwareImageFilePath no arquivo de configuração bmcfwu.cfg, por meio do qual é determinado o caminho para a imagem do firmware atualizado. Durante a próxima atualização, que pode ser iniciada por um comando no IPMI, este parâmetro será processado pelo BMC e usado como parte da chamada popen() como parte da linha para /bin/sh. Como a linha para gerar o comando shell é criada usando a chamada snprintf() sem a limpeza adequada dos caracteres especiais, os invasores podem substituir seu código para execução. Para explorar a vulnerabilidade, você deve ter direitos que permitam enviar um comando ao controlador BMC via IPMI (se você tiver direitos de administrador no servidor, poderá enviar um comando IPMI sem autenticação adicional).

Gigabyte e Lenovo foram notificadas dos problemas em julho de 2018 e conseguiram lançar atualizações antes que as informações fossem divulgadas publicamente. Empresa Lenovo lançado atualizações de firmware em 15 de novembro de 2018 para os servidores ThinkServer RD340, TD340, RD440, RD540 e RD640, mas apenas eliminou uma vulnerabilidade neles que permite a substituição de comandos, já que durante a criação de uma linha de servidores baseada em MergePoint EMS em 2014, firmware a verificação foi realizada por meio de assinatura digital ainda não foi difundida e não foi inicialmente anunciada.

Em 8 de maio deste ano, a Gigabyte lançou atualizações de firmware para placas-mãe com controlador ASPEED AST2500, mas, assim como a Lenovo, apenas corrigiu a vulnerabilidade de substituição de comando. Placas vulneráveis ​​baseadas em ASPEED AST2400 permanecem sem atualizações por enquanto. Gigabyte também dito sobre a transição para o uso do firmware MegaRAC SP-X da AMI. A inclusão de novo firmware baseado em MegaRAC SP-X será oferecida para sistemas enviados anteriormente com firmware MergePoint EMS. A decisão segue o anúncio da Vertiv de que não oferecerá mais suporte à plataforma MergePoint EMS. Ao mesmo tempo, nada foi relatado ainda sobre atualizações de firmware em servidores fabricados pela Acer, AMAX, Bigtera, Ciara, Penguin Computing e sysGen baseados em placas Gigabyte e equipados com firmware MergePoint EMS vulnerável.

Lembremos que o BMC é um controlador especializado instalado em servidores, que possui interfaces próprias de CPU, memória, armazenamento e sensor polling, que fornece uma interface de baixo nível para monitoramento e gerenciamento de equipamentos de servidores. Usando o BMC, independentemente do sistema operacional em execução no servidor, você pode monitorar o status dos sensores, gerenciar energia, firmware e discos, organizar inicialização remota pela rede, garantir o funcionamento de um console de acesso remoto, etc.

Fonte: opennet.ru

Adicionar um comentário