Ataques Side-Channel- ao Kernel CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

Produtos impactados

Red Hat Product Security classificou esta atualização com um impacto de segurança Importante.

As seguintes versões dos produtos de Red Hat são impactadas:

• Red Hat Enterprise Linux 5
• Red Hat Enterprise Linux 6
• Red Hat Enterprise Linux 7
• Red Hat Atomic Host
• Red Hat Enterprise MRG 2
• Red Hat OpenShift Online v2
• Red Hat OpenShift Online v3
• Red Hat Virtualization (RHEV-H/RHV-H)
• Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno)
• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7
• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7
• Red Hat OpenStack Platform 8.0 (Liberty)
• Red Hat OpenStack Platform 8.0 (Liberty) director
• Red Hat OpenStack Platform 9.0 (Mitaka)
• Red Hat OpenStack Platform 9.0 (Mitaka) director
• Red Hat OpenStack Platform 10.0 (Newton)
• Red Hat OpenStack Platform 11.0 (Ocata)
• Red Hat OpenStack Platform 12.0 (Pike)

Enquanto os Containers Linux da Red Hat não são diretamente afetados pelos problemas do kernel, sua segurança depende da integridade do ambiente kernel do host. A Red Hat recomenda você usar as versões mais recentes de suas imagens de container. O Container Health Index, parte do Red Hat Container Catalog, sempre pode ser usado para verificar o status de segurança dos containers de Red Hat. Para proteger a privacidade dos containers em uso, você precisará garantir que o host do Container (como o Red Hat Enterprise Linux ou Atomic Host) tenha sido atualizado contra esses ataques. A Red Hat lançou um Atomic Host atualizado para este caso de uso.

Descrição do ataque e Impacto

Os ataques descritos neste artigo abusam da capacidade de execução especulativa de microprocessadores modernos de alto desempenho. Os microprocessadores modernos implementam uma otimização de design conhecida como execução "Out-of-Order" (OoO), o que significa que o microprocessador começará a executar instruções independentes assim que suas dependências de dados ficarem disponíveis (o chamado modelo “data flow”) em vez de sempre estar executando instruções na ordem literal fornecida pelo programador através do seu binário de aplicação. A ilusão de uma execução seqüencial é mantida dentro do processador por meio de várias estruturas de reordenamento interno que amortecem esses estados intermediários de execução do processador e apresentam os resultados em ordem. A execução Out-of-Order (OoO) foi originalmente inventada pelo Robert Tomasulo em 1967 para uso nos sistemas IBM mainframe iniciais. Nas décadas intermediárias, tornou-se uma característica estándar de quase todos os microprocessadores.

Uma extensão do modelo de execução Out-of-Order adiciona algoritmos de predição de branch (salto) altamente sofisticados que visam prever se um determinado path (branch) do código de software será executado. Um branch (salto) pode ser pensado como alterar o fluxo de instruções que está sendo executado pelo processador em resposta a uma declaração "Se" da forma "se isso acontecer, então faça A, caso contrário faça B". A condição sobre a qual um branch é tomado ou não geralmente depende de dados que podem não estar disponíveis de maneira imediata (por exemplo, porque requer uma carga de RAM mais lenta na hierarquia de cache do microprocessador interno). Como a condição de branch (salto) pode não estar pronta em tempo e forma, o processador pode começar a executar especulativamente o path mais provável, baseado na entrada do preditor do branch. Os resultados dessa execução são armazenados de tal forma que todo o path pode ser descartado se a direção do branch especulado se revelar incorreta. Assim, a execução especulativa é completamente invisível para o programador, ou para outros usuários do mesmo sistema.

Os ataques descritos neste artigo dependem de abrir a caixa preta que é o estado interno do microprocessador durante a execução especulativa. Em particular, os ataques dependem de uma técnica conhecida como análise side-channel (canal lateral) do cache. Durante a execução especulativa, um processador não dará resultados intermediários na memória ou registros visíveis para o programador, para outros processadores ou para outros aplicativos em execução. No entanto, para acessar a memória dentro dos paths de código especulados, deve trazer os dados no cache do processador. A análise side-channel permite que um invasor observe alocações especuladas (cargas) nos caches do sistema, mesmo aqueles provenientes de paths de execução que, em última instância, foram descartados. Um programa especialmente criado pode ser projetado para executar cargas de maneira especulativa no cache de locais de memória privilegiados e monitorar os resultados que podem ser usados para inferir o conteúdo dessa memória privilegiada.

Um caso que desencadeia a execução especulativa da CPU é branches. Um invasor pode começar treinando o preditor de branch que um branch particular no código do kernel é fortemente tomado (ou não tomado). Na próxima vez que o branch for executado, o processador começará a executar o código na direção escolhida pelo atacante. Se o atacante escolher um path que carrega um valor da memória, tal carga será executada de forma especulativa. Os ataques contra a possibilidade de previsão de branch (salto) (em algumas implementações de microprocessadores afetadas) podem ser estendidos através do limite do kernel/hipervisor, permitindo que os sistemas operacionais guest não privilegiados exerçam influência sobre a execução do hipervisor e, quando combinados com a análise side-channel (canal lateral), para extrair memória sensível do hipervisor .

Os efeitos da execução especulativa, no entanto, podem ser ainda mais abrangentes. Como o estado interno do microprocessador não é visível para o programador, ou para outros usuários ou aplicativos que funcionam no sistema, o processador pode realizar acessos especulativos aos dados mesmo antes de verificar se eles são permitidos. As verificações de permissão ocorrerão em paralelo e, em última instância, desencadearão um aborto da especulação antes de retirar as instruções especuladas e tornar visíveis seus resultados de execução fora do processador. Se o processador usa dados de forma especulativa em cache da memória antes de completar as verificações de permissão, torna-se possível observar esses dados ao usá-lo em acessos de memória subsequentes.

Um exemplo de tais verificações de permissão é a verificação de acesso à página da unidade de administração de memória (MMU, pelas siglas em inglês). Paging, também conhecido como memória virtual, é uma característica comum dos microprocessadores de alto desempenho; ele permite que o sistema operacional controle o mapeamento de endereços virtuais nos endereços físicos da RAM do sistema e também limite os acessos aos endereços virtuais através de bits de controle de acesso. Por exemplo, uma página pode ser marcada como “read-only” (para que as gravações causem uma page fault exception) ou como “kernel memory” (para que os acessos no modo usuário causem uma page fault exception).

Como a permissão do processador exigem que os aplicativos do usuário não possam acessar a memória do kernel, é uma prática padrão na indústria para kernels do sistema operacional (incluindo o Linux) para mapear endereços de memória virtual do kernel no mesmo espaço de endereço que as aplicações do usuário. Isso cria uma vantagem de desempenho significativa, já que as aplicações fazem uso frequente das chamadas do sistema fornecidas pelo kernel e os espaços de endereço cambiantes durante cada chamada do sistema implicariam uma sobrecarga de desempenho significativa. Cada switch exigiria o flushing (invalidando) o conteúdo de muitas estruturas de CPU internas, como os TLBs (Translation Lookaside Buffers) que armazenam as traduções da memória virtual-a-física e aceleram o uso da memória virtual.

Compartilhar as tabelas de páginas entre o kernel e as aplicações do usuário, no entanto, permite outro tipo de ataque contra a execução especulativa. Neste caso, a fase preparatória faze com que o atacante adultere o kernel  para que carregue um endereço virtual "interessante" no cache de dados Nível 1 (L1) do processador. O cache de dados L1 é comumente organizado usando uma técnica conhecida como VIPT (Virtually Indexed, Physically Tagged), que permite que a tradução de endereços virtual e físico e as verificações de permissão ocorram em paralelo com o acesso. Na presença de um espaço de endereço virtual compartilhado, os endereços virtuais privilegiados do kernel podem ser acessados de forma especulativa através do cache L1 por código de usuário não confiável durante a execução especulativa, e os valores carregados podem ser usados mais adiante no path de execução especulativa. Um segundo acesso especulativo à memória pode, portanto, encher o cache de uma maneira que faze que dependa dos conteúdos da memória privilegiada, e os efeitos podem ser observados para derivar esses conteúdos.

Esses ataques side-channel do microprocessador podem permitir que um usuário não confiável tenha acesso a um sistema para extrair informações confidenciais da memória do kernel ou do hipervisor privilegiado, bem como de outras aplicações ou máquinas virtuais que funcionam no mesmo sistema. A mitigação envolve uma série de passos discretos, alguns ou todos os quais podem ser necessários, dependendo da marca e modelo exato do microprocessador, cada um dos quais pode ser vulnerável de forma diferente a cada variante do ataque:

• Separando os espaços de endereço virtual do kernel e do usuário: isso é realizado usando uma alteração de design para o kernel do Sistema Operacional conhecido como KPTI (Kernel Page Table Isolation), às vezes referido usando o nome "KAISER".
• Desativando a predição de branch indireta após a entrada no kernel ou no hipervisor: novas capacidades foram adicionadas a muitos microprocessadores em toda a indústria por meio de microcódigo, milicode, firmware e outras atualizações. Essas novas capacidades são alavancadas por atualizações para o Red Hat Enterprise Linux que controlam seu uso.
• Fazer um fencing de cargas especulativas de certos locais de memória: tais cargas devem ser anotadas através de pequenas mudanças no kernel do Linux, que foram integradas nas atualizações da Red Hat.

Estas soluções de software, em combinação com microcódigo, milicode e atualizações de firmware podem mitigar os ataques descritos neste artigo. No entanto, a mitigação tem algum custo para o desempenho do sistema. Dependendo do sistema, da marca e do modelo específico dos microprocessadores, bem como das características das cargas de trabalho, o impacto no desempenho pode ser significativo. A Red Hat está assumindo uma posição pró-ativa que favorece a segurança antes do que o desempenho, ao mesmo tempo que permita aos usuários a flexibilidade para avaliar seu próprio ambiente e fazer mudanças adequadas ao ativar e desativar seletivamente as diferentes mitigações.

A equipe de Red Hat Performance Engineering criou um artigo na Knowledgebase relatando o impacto de desempenho observado para uma variedade de cargas de trabalho representativas e descrevendo as opções que os usuários podem tomar para desativar partes das correções de segurança para recuperar o nível de desempenho desejado se o cliente estiver confiante de que seus computadores estão fisicamente isolados. Os dados de desempenho adicionais serão publicados à medida que este incidente se desenvolva.

As equipes da Red Hat Performance Engineering e Product Engineering desenvolveram um artigo na Knowledgebase detalhando os ajustes disponíveis para ativar ou desativar seletivamente essas novas características de segurança.

Detecção e Diagnóstico

A Red Hat está ativamente desenvolvendo vários scripts para ajudar os usuários a entender o impacto dessas questões em seus sistemas.

Para os subscritos que utilizam produtos da Red Hat Virtualization, foi criado um artigo na Knowledgebase para verificar se o microcódigo/firmware fornecido pelo OEM foi aplicado.

Adopte medidas

Recomenda-se aos clientes da Red Hat que executam versões afetadas dos produtos Red Hat atualizá-los assim que as erratas estiverem disponíveis. Insta-se aos clientes a aplicar as atualizações apropriadas imediatamente. Todos os produtos afetados devem aplicar as correções para mitigar todas as 3 variantes; CVE-2017-5753 (variante 1),  CVE-2017-5715 (variante 2), e CVE-2017-5754 (variante 3).

NOTAS

• Meltdown é o nome de marca para CVE-2017-5754 (variante 3)
• Spectre é o nome de marca para o combinado de CVE-2017-5753 (variante 1) e CVE-2017-5715 (variante 2)
• Devido à natureza das mudanças necessárias, um kpatch para clientes rodando o Red Hat Enterprise Linux 7.2 ou superior NÃO estará disponível.
• A Variante 2 pode ser explorada tanto localmente (dentro do mesmo sistema operacional) quanto através do limite do guest de virtualização. As correções requerem o microcódigo/firmware da CPU estar ativado. Os subscritores são avisados para entrar em contato com seu OEM de hardware para receber o microcódigo/firmware apropriado para o processador.
• Para os clientes que utilizam a plataforma Red Hat OpenStack, um artigo da Knowledgebase adicional também está disponível.

Atualizações para produtos afetados

* É necessária uma subscrição ELS ativa para acessar este patch. Entre em contato com o setor de vendas da Red Hat ou com seu representante de vendas específico para obter mais informações se a sua conta não tiver uma subscrição ELS ativa.

** É necessária uma subscrição EUS ativa para acessar este patch. Entre em contato com o setor de vendas da Red Hat ou com seu representante de vendas específico para obter mais informações se a sua conta não tiver uma subscrição EUS ativa.

What is the Red Hat Enterprise Linux Extended Update Support Subscription?

*** É necessária uma subscrição AUS ativa para acessar este patch em RHEL AUS.

What is Advanced mission critical Update Support (AUS)?

**** É necessária uma subscrição TUS ativa para acessar este patch no RHEL TUS.

***** Os subscritos devem entrar em contato com seus OEMs de hardware para obter as versões mais atualizadas do microcódigo / firmware da CPU.

Mitigação

Não há mitigação conhecida, além de aplicar atualizações de software de fornecedores em combinação com o microcódigo/firmware da CPU dos OEMs de hardware. Todos os clientes da Red Hat devem aplicar soluções de fornecedores para corrigir suas CPUs e atualizar o kernel assim que os patches estiverem disponíveis.

Aconselha-se aos clientes a adotar uma abordagem baseada em risco para atenuar este problema. Os sistemas que exigem altos graus de segurança e confiança devem ser abordados primeiro e devem ser isolados de sistemas não confiáveis até que os tratamentos possam ser aplicados a esses sistemas para reduzir o risco de exploração.

Os clientes que executam hipervisores Xen devem estar cientes das limitações técnicas desse software que não podem eliminar completamente o exploit da variante 2 e não podem eliminar o exploit da variante 3 em guests paravirtualizados. A Red Hat preparou um artigo da Knowledgebase detalhando a situação do Xen e as opções disponíveis para os usuários do hypervisor Xen.