Uma vulnerabilidade de hardware, descoberta de forma independente por pesquisadores de universidades americanas e pesquisadores do Google, ressalta uma falha de microprocessador que, se explorada, poderia permitir que um invasor consiga ter acesso a dados da memória do kernel.
Esta vulnerabilidade é considerada uma falha importante para infraestruturas complexas e implantações em nuvem e deve ser corrigida para evitar possíveis impactos futuros.
Uma vez que esta falha afeta grande parte dos microprocessadores modernos (Intel, AMD e ARM fabricados nas últimas duas décadas estão sujeitos), ela pode afetar qualquer dispositivo que os use, incluindo múltiplos sistemas operacionais em dispositivos móveis, laptops, estações de trabalho e servidores.
É importante notar que para explorar essa vulnerabilidade, um invasor precisaria executar código não confiável no sistema físico ou em uma máquina virtual vinculada a esse sistema. Isso pode incluir a execução de conteúdo de páginas da Web ou aplicativos para smartphones.
Uma falha, três variações
A falha tem três variações técnicas que foram atribuídas três CVEs separadas. Os pesquisadores chamaram dois deles de Spectre e um deles Meltdown. Se usados em conjunto, pode resultar em:
- Escalação de privilégio
- Vazamento de dados da memória do kernel
- Patching pode resultar em degradação do desempenho
Essência desta falha
A falha da CPU decorre da forma como os processadores modernos tentam otimizar o desempenho especulando sobre caminhos de processamento corretos. Por exemplo, na maioria dos sistemas modernos, a memória é armazenada em três locais gerais: cache do processador, memória RAM e no disco. Cada tipo tem diferentes velocidades de acesso e tamanhos de armazenamento – por exemplo, o cache é menor e mais rápido que a memória RAM, que é em si menor e mais rápido do que o armazenamento de memória no disco.
Isso afeta a rapidez com que os programas podem ser processados. Os programas não são lineares – eles frequentemente se ramificam entre diferentes caminhos de processamento possíveis. Às vezes, a decisão sobre o ramo a seguir requer informações armazenadas em um espaço de memória lento, como memória principal ou no disco.
Em vez de ocioso até que a informação seja recuperada, o processador normalmente irá especular sobre qual ramo será seguido. Em seguida, continuará processando esse ramo até que a informação seja finalmente recuperada. Se escolheu o ramo correto, ele continua processando; se ele escolheu o ramo errado, eleva os resultados de processamento agora incorretos e segue o ramo correto.
Muitas vezes, a execução especulativa resulta no processador executando as instruções antes de saber se os comandos violam as proteções de segurança.
No geral, essa vulnerabilidade da CPU aproveita os diferentes aspectos do tempo no processamento especulativo e, mais especificamente, a janela não preditiva quando o processador supostamente executa a opção errada, mas ainda não recebeu o caminho correto.
Variante #1: CVE-2017-5715, ou Spectre
Esta variação da falha da CPU é uma nova jogada em uma vulnerabilidade mais antiga que se concentra na previsão de ramificação.
“A predição do ramo prevê o alvo do ramo e permite que o processador comece a executar instruções muito antes do caminho de execução verdadeiro do ramo ser conhecido”.
As vulnerabilidades descobertas anteriormente demonstraram que é possível que o código que está sendo executado em um contexto de segurança influencie a predição de em um contexto de segurança completamente diferente. Esta influência, embora possível, só foi de um jeito: do kernel ao espaço de usuários. Por exemplo, de um hypervisor para um usuário convidado.
A novidade no CVE-2017-5715, é que agora, a interferência da predição do ramo pode ser gerada em ambas as direções, o que significa que as previsões do kernel podem ser afetadas por um invasor que só possui privilégios de espaço de usuários, permitindo a visão do invasor em dados que de outra forma não teriam.
Variante #2: CVE-2017-5753, ou Spectre
A segunda variante da falha baseia-se no fato de que o processador efetivamente faz o carregamento do código fora dos limites durante a fase de especulação. O objetivo do atacante aqui seria enganar a CPU para expor sua eventual escolha de ramo durante a janela de especulação.
Em circunstâncias normais, a CPU pode realmente ler do código que não é suposto executar, mas uma vez que o ramo correto é selecionado, ele reverte o estado de execução e descarta quaisquer efeitos que outros ramos tenham tido.
Durante um possível ataque, a CPU pode carregar um offset não confiável de um chamador, iniciar uma carga de um offset dependente de dados, então carregar a linha de cache correspondente no L1. Ao contrário do código que a CPU está esperando, o código do atacante é mais longo, o que ficaria fora de limites para essa leitura. Isso fará com que a execução volte para um caminho não especulativo, em que ponto o atacante pode medir o tempo necessário para carregar os dados para os diferentes caminhos e determinar de que maneira a CPU foi e, portanto, índice dos dados.
Variante #3: CVE-2017-5754, ou Meltdown
A terceira variação da falha da CPU visa ler a memória do kernel do espaço do usuário sem qualquer influência / má direção do código que está sendo executado no espaço do kernel.
Em resumo, durante a janela de especulação, a CPU verifica as permissões para acessar um endereço de memória, mas essa verificação pode impor impacto no desempenho. Para permitir o desempenho ideal, a CPU poderia optar por verificar as permissões mais tarde, de forma assíncrona, aumentando uma flag de exceção somente se a verificação falhar por qualquer motivo.
Uma vez que também é possível executar uma instrução por trás de uma ramificação de alta latência não preditiva, para evitar uma falha de paginação, a janela de especulação pode ser ampliada aumentando o atraso entre a leitura de um endereço de kernel e a entrega da exceção associada. O resultado pode estar permitindo que um invasor do espaço do usuário seja lido da memória no espaço do kernel sem as verificações usuais que devem estar no lugar para limitar essa opção. A exceção não é levantada até que as instruções ilegais se retirem, o que, sob a execução especulativa, não o fazem.
Como reduzir os riscos associados a esta falha?
Esta nova falha exige um processo de avaliação de risco para todas as organizações. As equipes de segurança terão que inventariar seus ativos e determinar quais podem ser vulneráveis. Então, depois de definir críticos e pontuações de sensibilidade, os recursos devem ser corrigidos ou aplicados controles atenuantes.
Um invasor deve poder colocar o código em um aplicativo executado no próprio sistema ou em uma máquina virtual anexada ao sistema para usar essa vulnerabilidade. Portanto, as proteções para impedir o acesso não autorizado a sistemas de fora da infraestrutura podem servir como uma primeira barreira, bem como controles de acesso existentes para usuários internos.
As ações que as equipes de segurança podem tomar para proteger os ativos é impedir a execução de software não autorizado ou o acesso de sites não confiáveis, em qualquer sistema que manipule dados sensíveis, incluindo máquinas virtuais adjacentes. Suponha que qualquer tipo de execução, incluindo a execução binária, tenha o potencial de ataque.
Além disso, assegure-se de políticas de segurança para impedir o acesso não autorizado aos sistemas e a introdução de software ou atualizações de software não aprovadas.
Se a organização estiver operando ambientes onde a prevenção da execução de software não autorizado não é possível, ou é inconsistente, a proteção só pode ser possível, aplicando atualizações para o firmware do sistema, sistemas operacionais e código do aplicativo, além de alavancar as proteções do nível do sistema para evitar a execução de código não autorizado.
Em casos de problemas de impacto de atualização, os controles atenuantes devem ser aplicados de forma interina, mas o patch é, em última instância, a remediação necessária para evitar potenciais ataques. Observe que a maioria dos patches lançados até agora requer sistemas de reinicialização e deve ser avaliado quanto ao impacto potencial de tal evento em um determinado bem.
Avalie riscos e tome medidas
Neste momento, os tipos de ativos para os quais a alta prioridade de remediação deve ser definida são ambientes Multi-Tenancy de missão crítica, tais como:
- XaaS – nuvem, virtualizações e serviços externos.
- Appliances
- Supplychains com recursos de atualização automatizada.
- Servidores de aplicativos que executam aplicativos com recursos de upload de arquivos ou JumpHost.
- Ambientes de desenvolvimento de aplicativos.
- Dispositivos de usuário de todos os tipos.
A prioridade de remediação pode ser configurada para moderar os ambientes Single-Tenancy de missão crítica, bem como ambientes Multi-Tenancy que não sejam de missão crítica, tais como:
- Nuvens internas que não sai para fora da rede.
- Usuários privilegiados, usuários com acesso a dados confidenciais / confidenciais, desenvolvedores.
- Infraestrutura com acesso limitado, como bancos de dados e servidores de aplicativos sem recursos de upload de arquivos.
A prioridade de remediação pode ser definida como baixa em casos de ambientes não críticos e de Single-Tenancy, tais como:
- Infra-estrutura compartilhada com acesso limitado.
- Dispositivos de rede e segurança.
- Aparelhos internos.
Potencial degradação do desempenho
Na atualização de ativos e, em alguns casos, ter que atualizar o BIOS, pode resultar em um impacto significativo no desempenho. O nível de impacto dependerá do processador específico usado, da natureza da carga de trabalho e do método de remediação selecionado pelo fabricante.
As equipes de segurança devem avaliar a exposição e o impacto potencial para seus ambientes antes de aplicar as atualizações que possam afetar negativamente o desempenho.
Para entender melhor o potencial de impacto no desempenho em ambientes específicos de aplicativos, as equipes de segurança são encorajadas a buscar informações de seus fornecedores de aplicativos. Em todos os casos, é recomendável implantar as atualizações necessárias em um ambiente de validação para testes antes de prosseguir os planos gerais de implantação.
Verifique os patches emitidos pelos fabricantes
Todos os fabricantes relevantes estarão emitindo e liberando elementos de correção e patches para resolver esta nova vulnerabilidade da CPU. Equipes de segurança devem verificar o fabricante recursos para obter patches e atualizações à medida que ficam disponíveis.
As equipes de segurança devem procurar receber e testar patches de microcode, bem como patches do sistema operacional para host subjacente e Convidado.
Verifique a Remediação do Provedor de Nuvem
Tendo em mente os modelos comuns de segurança da nuvem que compartilham as responsabilidades de segurança entre o fornecedor e seus clientes, as organizações com implantações em nuvem devem verificar a cobertura de remediação oferecida pelo provedor de serviços na nuvem. Definir o que cada lado deve comprometer para corrigir a remediação resultará em uma melhor mitigação.
Referências: https://googleprojectzero.blogspot.com.br/2018/01/reading-privileged-memory-with-side.html
