Pesquisadores de segurança publicaram no Project Zero uma nova vulnerabilidade chamada Specter and Meltdown permitindo que um programa roube informações da memória de outros programas. Afeta as arquiteturas Intel, AMD e ARM.
Essa falha pode ser explorada remotamente visitando um site JavaScript. Detalhes técnicos podem ser encontrados no site da redhat , equipe de segurança do Ubuntu .
Vazamento de informações por meio de ataques de canal lateral de execução especulativa (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754, também conhecido como Spectre e Meltdown)
Foi descoberto que uma nova classe de ataques de canal lateral afeta a maioria dos processadores, incluindo processadores da Intel, AMD e ARM. O ataque permite que processos maliciosos do espaço do usuário leiam a memória do kernel e códigos maliciosos nos convidados leiam a memória do hipervisor. Para resolver o problema, serão necessárias atualizações no kernel do Ubuntu e no microcódigo do processador. Essas atualizações serão anunciadas em futuros Avisos de Segurança do Ubuntu assim que estiverem disponíveis.
Implementação de exemplo em JavaScript
Como prova de conceito, foi escrito um código JavaScript que, ao ser executado no navegador Google Chrome, permite que o JavaScript leia a memória privada do processo em que é executado.
Meu sistema parece ser afetado pela vulnerabilidade do espectro. Eu compilei e executei esta prova de conceito ( spectre.c).
Informação do sistema:
$ uname -a
4.13.0-0.bpo.1-amd64 #1 SMP Debian 4.13.13-1~bpo9+1 (2017-11-22) x86_64 GNU/Linux
$ cat /proc/cpuinfo
model name : Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz
$gcc --version
gcc (Debian 6.3.0-18) 6.3.0 20170516
Como mitigar as vulnerabilidades Spectre e Meldown em sistemas Linux?
Leitura adicional: Usando o Meltdown para roubar senhas em tempo real .
Atualizar
Usando o Spectre & Meltdown Checkerdepois de mudar para a 4.9.0-5versão do kernel seguindo a resposta de @Carlos Pasqualini porque uma atualização de segurança está disponível para mitigar o cve-2017-5754 no debian Stretch:
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO (only 31 opcodes found, should be >= 70)
> STATUS: VULNERABLE (heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation: NO
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
Atualização 25 de janeiro de 2018
O spectre-meltdown-checkerscript é empacotado oficialmente pelo debian , está disponível para Debian Stretch através do repositório de backports , Buster e Sid.
Speculative Store Bypass (SSB) – também conhecido como Variante 4
Sistemas com microprocessadores que utilizam execução especulativa e execução especulativa de leituras de memória antes que os endereços de todas as gravações de memória anteriores sejam conhecidos podem permitir a divulgação não autorizada de informações a um invasor com acesso de usuário local por meio de uma análise de canal lateral.
Rogue System Register Read (RSRE) – também conhecido como Variante 3a
Sistemas com microprocessadores que utilizam execução especulativa e que realizam leituras especulativas de registros do sistema podem permitir a divulgação não autorizada de parâmetros do sistema a um invasor com acesso de usuário local por meio de uma análise de canal lateral.
Editar 27 de julho de 2018
NetSpectre: Ler memória arbitrária pela rede
Neste artigo, apresentamos o NetSpectre, um novo ataque baseado na variante Spectre 1, que não requer código controlado pelo invasor no dispositivo alvo, afetando assim bilhões de dispositivos. Semelhante a um ataque Spectre local, nosso ataque remoto requer a presença de um gadget Spectre no código do alvo. Mostramos que os sistemas que contêm os dispositivos Spectre necessários em uma interface de rede ou API exposta podem ser atacados com nosso ataque Spectre remoto genérico, permitindo a leitura de memória arbitrária na rede. O invasor apenas envia uma série de solicitações elaboradas para a vítima e mede o tempo de resposta para vazar um valor secreto da memória da vítima.
Alan Cox compartilhou um link do blog da AMD: https://www.amd.com/en/corporate/speculative-execution
Variante Um: Desvio de Verificação de Limites Variante dois: injeção de alvo de ramificação Variante três: carregamento de cache de dados não autorizadoSeria bom ter a confirmação dessas declarações da AMD por terceiros.
A 'mitigação' nos sistemas afetados exigiria um novo kernel e uma reinicialização, mas em muitas distribuições ainda não foram lançados pacotes com as correções:
Debian:
Outras fontes de informação que encontrei:
27 de janeiro de 2018 Intel Microcode quebra alguns sistemas
A atualização do microcódigo da Intel 2018-01-08 para solucionar falhas de segurança de ramificação de execução especulativa quebrou alguns sistemas. Isso afetou muitos sistemas Ubuntu de 8 a 21 de janeiro. Em 22 de janeiro de 2018, o Ubuntu lançou uma atualização que traz de volta o Microcódigo mais antigo de 2017-07-07.
Se você teve problemas com atualizações, reinstalou o Ubuntu e desativou as atualizações entre 2018-01-08 e 2018-01-22, tente as atualizações automáticas do Ubuntu novamente.
Atualização de 16 de janeiro de 2018 Spectre em 4.14.14 e 4.9.77
Se você já estiver executando as versões do Kernel 4.14.13 ou 4.9.76 como eu, é fácil de instalar
4.14.14e4.9.77quando eles forem lançados em alguns dias para mitigar a falha de segurança do Spectre. O nome desta correção é Retpoline e não tem o desempenho grave atingido anteriormente especulado:Sem entrar em detalhes do JavaScript, aqui está como evitar imediatamente o buraco Meltdown (e a partir de 10 de janeiro de 2018, proteção Spectre)
Atualização de 12 de janeiro de 2018
A proteção inicial contra o Specter está aqui e será aprimorada nas próximas semanas e meses.
Kernels Linux 4.14.13, 4.9.76 LTS e 4.4.111 LTS
A partir deste artigo da Softpedia :
Muitos usuários tiveram problemas com as atualizações do Ubuntu LTS em 4 de janeiro de 2018 e 10 de janeiro de 2018. Estou usando
4.14.13há alguns dias sem problemas, porém YMMV .Atualização de 7 de janeiro de 2018
Greg Kroah-Hartman escreveu uma atualização de status sobre as falhas de segurança do Meltdown e do Spectre Linux Kernel ontem. Alguns podem chamá-lo de o segundo homem mais poderoso do mundo Linux logo após Linus. O artigo aborda kernels estáveis (discutidos abaixo) e kernels LTS que a maioria dos usuários do Ubuntu possui.
Kernels Linux 4.14.11, 4.9.74, 4.4.109, 3.16.52 e 3.2.97 Patch Meltdown Falha
Deste artigo :
Os usuários são convidados a atualizar seus sistemas imediatamente
4 de janeiro de 2018 01:42 GMT · Por Marius Nestor
Os mantenedores do kernel Linux Greg Kroah-Hartman e Ben Hutchings lançaram novas versões da série de kernel Linux 4.14, 4.9, 4.4, 3.16, 3.18 e 3.12 LTS (Long Term Support) que aparentemente corrige uma das duas falhas críticas de segurança que afetam a maioria dos sistemas modernos. processadores.
Os kernels Linux 4.14.11, 4.9.74, 4.4.109, 3.16.52, 3.18.91 e 3.2.97 estão agora disponíveis para download no site kernel.org, e os usuários devem atualizar suas distribuições GNU/Linux para essas novas versões se eles executarem qualquer uma dessas séries de kernel imediatamente. Por que atualizar? Porque eles aparentemente consertam uma vulnerabilidade crítica chamada Meltdown.
Conforme relatado anteriormente, Meltdown e Spectre são dois exploits que afetam quase todos os dispositivos alimentados por processadores modernos (CPUs) lançados nos últimos 25 anos. Sim, isso significa quase todos os telefones celulares e computadores pessoais. O Meltdown pode ser explorado por um invasor sem privilégios para obter informações confidenciais armazenadas na memória do kernel de maneira mal-intencionada.
Patch para a vulnerabilidade Spectre ainda em andamento
Embora o Meltdown seja uma vulnerabilidade séria que pode expor seus dados secretos, incluindo senhas e chaves de criptografia, o Spectre é ainda pior e não é fácil de corrigir. Pesquisadores de segurança dizem que isso vai nos assombrar por algum tempo. O Spectre é conhecido por explorar a técnica de execução especulativa usada pelas CPUs modernas para otimizar o desempenho.
Até que o bug do Spectre também seja corrigido, é altamente recomendável que você pelo menos atualize suas distribuições GNU/Linux para qualquer uma das versões recém-lançadas do kernel do Linux. Portanto, procure nos repositórios de software de sua distro favorita a nova atualização do kernel e instale-a o mais rápido possível. Não espere até que seja tarde demais, faça isso agora!
I had been using Kernel 4.14.10 for a week so downloading and booting Ubuntu Mainline Kernel version 4.14.11 wasn't too much of a concern for me.
Ubuntu 16.04 users might be more comfortable with 4.4.109 or 4.9.74 kernel versions which were released at the same time as 4.14.11.
If your regular updates do not install the Kernel version you desire you can do it manually following this Ask Ubuntu answer: https://askubuntu.com/questions/879888/how-do-i-update-kernel-to-the-latest-mainline-version/879920#879920
4.14.12 - What a difference a day makes
Less than 24 hours after my initial answer a patch was released to fix 4.14.11 kernel version that they may have rushed out. Upgrading to 4.14.12 is recommended for all 4.14.11 users. Greg-KH says:
Looking at this update not very many lines of source code were changed.
De fato. Portanto, uma mitigação sensata é desativar o JavaScript em seus navegadores da Web ou usar navegadores da Web que não oferecem suporte a JavaScript.
A maioria dos navegadores que suportam JavaScript tem uma configuração para desativá-lo. Como alternativa, se você deseja manter uma lista de permissões de sites ou domínios para os quais permitir JavaScript, existem vários complementos que podem ajudar, como uBlock Origin e NoScript .
NB Não é preciso dizer que desabilitar/restringir o JavaScript não deve ser sua única mitigação. Além disso, você deve revisar (e provavelmente aplicar) quaisquer correções de kernel relevantes e outras atualizações de segurança assim que forem escritas, testadas e publicadas. Em distribuições derivadas do Debian, use comandos como
sudo apt update,sudo apt list-upgradableesudo apt upgrade.Atualização: não acredite na minha palavra. Alan Cox diz quase o mesmo:
O fato de que isso é explorável usando JavaScript não é o ponto principal e não deve ser a principal preocupação (embora seja importante porque desta forma o código remoto pode ser facilmente executado em seu sistema, mas este não é o único como isso pode acontecer).
Seu foco não deve estar no Javascript e/ou no seu navegador. Idealmente, sua CPU deve ser corrigida. Infelizmente, para a maior parte da atual onda de bugs, isso não parece ser possível. O Debian, junto com todas as outras partes que fornecem o sistema operacional, seguirá o único outro caminho possível, exceto recomendar uma CPU que não seja defeituosa: eles forçam o sistema a contornar o bug na CPU. Esses patches não resolvem os problemas. Em vez disso, o sistema operacional os oculta da melhor maneira possível de qualquer programa executado pelo usuário na máquina (e, portanto, também no navegador).
Essa ocultação é um trabalho computacional extra e, portanto, o desempenho geral do sistema será menor do que sem. Quanto mais baixo provavelmente depende muito do que exatamente esses programas fazem.
Com isso em mente, volte à sua pergunta: o que você pode fazer para proteger seu sistema Debian é instalar atualizações de segurança. Eu confio que o Debian fará todo o possível à luz desses bugs para executar o Debian da maneira mais segura possível, apesar das falhas inerentes da CPU.
Todos os tipos de grandes empresas já estão trabalhando nessa questão, assim como vários gurus de hardware e Linux. Não quero impedi-lo de tentar algo sozinho ou de tentar ajudar no esforço geral. No entanto, se sua própria segurança e uma correção oportuna são tudo o que você está interessado, provavelmente eles encontrarão uma solução melhor em menos tempo do que você, começando agora a investigar isso por conta própria.