Como mitigar as vulnerabilidades Spectre e Meltdown nos sistemas Linux?

34

Pesquisadores de segurança publicaram no Projeto Zero uma nova vulnerabilidade chamada Spectre and Meltdown, que permite 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 redhat , equipe de segurança do Ubuntu .

Vazamento de informações através de ataques especulativos ao canal lateral de execução (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754, também conhecido como Spectre and 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 o código malicioso nos convidados para ler 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 nos futuros Avisos de segurança do Ubuntu assim que estiverem disponíveis.

Exemplo de implementação em JavaScript

Como prova de conceito, o código JavaScript foi escrito que, quando executado no navegador Google Chrome, permite que o JavaScript leia a memória privada do processo em que é executado.

Meu sistema parece estar afetado pela vulnerabilidade do espectro. Eu compilei e executei essa 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 atenuar as vulnerabilidades Spectre e Meldown nos sistemas Linux?

Leitura adicional: Usando o Meltdown para roubar senhas em tempo real .

Atualizar

Usando a opção Spectre & Meltdown Checkerdepois de alternar para a 4.9.0-5versão do kernel após a resposta @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 é oficialmente empacotado pelo debian, está disponível para o Debian Stretch através do repositório de backports, Buster e Sid.

Atualização 22/05/2018

Bypass de armazenamento especulativo (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 anteriores sejam conhecidas podem permitir a divulgação não autorizada de informações a um invasor com acesso local ao usuário 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 executam leituras especulativas de registros do sistema podem permitir a divulgação não autorizada de parâmetros do sistema a um invasor com acesso local ao usuário por meio de uma análise de canal lateral.

Editar 27 de julho de 2018

NetSpectre: Leia memória arbitrária na 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 de destino, afetando 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 gadgets Spectre necessários em uma interface de rede ou API exposta podem ser atacados com nosso ataque remoto Specter genérico, permitindo a leitura de memória arbitrária na rede. O atacante envia apenas uma série de solicitações criadas à vítima e mede o tempo de resposta para vazar um valor secreto da memória da vítima.

GAD3R
fonte
11
Eu removi a tag Debian para permitir que este Q se aplicasse a todo Linux (conforme o título); revert se sua intenção é focar isso apenas no Debian.
Jeff Schaller

Respostas:

12

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

Resolvido pelas atualizações de software / sistema operacional a serem disponibilizadas pelos fornecedores e fabricantes do sistema. Impacto negligenciável no desempenho esperado.

Variante Dois: Injeção no Alvo de Filial

As diferenças na arquitetura da AMD significam que há um risco quase zero de exploração dessa variante. A vulnerabilidade à variante 2 não foi demonstrada nos processadores AMD até o momento.

Variante três: carga de cache de dados não autorizados

Zero vulnerabilidade da AMD devido a diferenças de arquitetura da AMD.

Seria 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 existem pacotes lançados com as correções:

Debian:

Outras fontes de informação que encontrei:

Carlos Pasqualini
fonte
12
Um monte de informações da AMD não vai ajudar um questionador cuja CPU é um Intel Core.
JdeBP
4
Para o kernel Linux, consulte a postagem de Greg Kroah-Hartman: kroah.com/log/blog/2018/01/06/meltdown-status
alanc
De acordo com as páginas debian vinculadas acima (e as páginas vinculadas), parece que os patches do kernel serão distribuídos à medida que os fornecedores responsáveis ​​publicam seu microcódigo. No entanto, a partir de security-tracker.debian.org/tracker/CVE-2017-5754 (o único corrigido até agora), parece que as correções foram disponibilizadas apenas para versões estáveis ​​e instáveis. Alguém sabe se podemos esperar correções para o oldstable ("jessie")? Eu não tenho sido capaz de encontrar qualquer declaração por Debian ou a equipe Debian de Segurança sobre esta matéria ...
Shevek
11

27 de janeiro de 2018 Intel Microcode quebra alguns sistemas

A atualização de 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 adia o Microcode mais antigo de 2017-07-07.

Se você teve problemas com as atualizações, reinstalou o Ubuntu e desativou as atualizações entre 08-01-2018 e 22-01-2018, convém tentar as atualizações automáticas do Ubuntu novamente.

16 de janeiro de 2018 atualiza o Spectre em 4.14.14 e 4.9.77

Se você já está executando as versões 4.14.13 ou 4.9.76 do Kernel, como eu sou, é fácil de instalar 4.14.14e 4.9.77quando elas saem em alguns dias para atenuar a falha de segurança do Spectre. O nome dessa correção é Retpoline e não tem o grave desempenho atingido anteriormente especulado:

Greg Kroah-Hartman enviou os últimos patches para os lançamentos de pontos do Linux 4.9 e 4.14, que agora incluem o suporte ao Retpoline.

Este X86_FEATURE_RETPOLINE está ativado para todas as CPUs AMD / Intel. Para obter suporte completo, você também precisa criar o kernel com um compilador GCC mais recente que contenha suporte -mindirect-branch = thunk-extern. As alterações do GCC chegaram no GCC 8.0 ontem e estão potencialmente sendo portadas para o GCC 7.3.

Aqueles que desejam desativar o suporte do Retpoline podem inicializar os kernels corrigidos com noretpoline .

Sem entrar em detalhes do JavaScript, veja como evitar imediatamente o buraco de fusão (e em 10 de janeiro de 2018, proteção contra espectros)

12 de janeiro de 2018 atualização

A proteção inicial do Spectre chegou e será aprimorada nas próximas semanas e meses.

Kernels do Linux 4.14.13, 4.9.76 LTS e 4.4.111 LTS

Neste artigo da Softpedia :

Os kernels Linux 4.14.13, 4.9.76 LTS e 4.4.111 LTS estão agora disponíveis para download no kernel.org, e incluem mais correções contra a vulnerabilidade de segurança Spectre, bem como algumas regressões do Linux 4.14.12, 4.9 .75 LTS e 4.4.110 kernels lançados na semana passada, como alguns relataram problemas menores.

Esses problemas parecem estar corrigidos agora; portanto, é seguro atualizar seus sistemas operacionais baseados em Linux para as novas versões de kernel lançadas hoje, que incluem mais atualizações x86, algumas correções de PA-RISC, s390 e PowerPC (PPC), várias melhorias para drivers (Intel i915, criptografia, IOMMU, MTD) e as alterações usuais de mm e núcleo.

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 no YMMV .


7 de janeiro de 2018 atualização

Greg Kroah-Hartman escreveu uma atualização de status sobre as falhas de segurança Meltdown e Spectre Linux Kernel ontem. Alguns podem chamá-lo de o segundo homem mais poderoso do mundo Linux, ao lado de Linus. O artigo aborda os kernels estáveis ​​(discutidos abaixo) e os kernels LTS que a maioria dos usuários do Ubuntu possui.


Falha no derretimento de patches do Linux Kernels 4.14.11, 4.9.74, 4.4.109, 3.16.52 e 3.2.97

Deste artigo :

Os usuários são convidados a atualizar seus sistemas imediatamente

4 de janeiro de 2018 01:42 GMT · De Marius Nestor

Os mantenedores de kernel Linux Greg Kroah-Hartman e Ben Hutchings lançaram novas versões das séries de kernel Linux 4.14, 4.9, 4.4, 3.16, 3.18 e 3.12 LTS (Long Term Support) que aparentemente corrigem uma das duas falhas críticas de segurança que afetam as mais modernas 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 são convidados a 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 corrigem uma vulnerabilidade crítica chamada Meltdown.

Conforme relatado anteriormente, Meltdown e Spectre são duas explorações que afetam quase todos os dispositivos equipados com processadores modernos (CPUs) lançados nos últimos 25 anos. Sim, isso significa quase todos os telefones celulares e computadores pessoais. O colapso pode ser explorado por um invasor sem privilégios para obter maliciosamente informações confidenciais armazenadas na memória do kernel.

Patch para a vulnerabilidade Spectre ainda em andamento

Embora o Meltdown seja uma vulnerabilidade séria que possa 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 nos assombrará por algum tempo. Sabe-se que o Spectre explora a técnica de execução especulativa usada pelas CPUs modernas para otimizar o desempenho.

Até que o bug Spectre seja corrigido também, é altamente recomendável que você atualize pelo menos suas distribuições GNU / Linux para qualquer uma das versões do kernel Linux recém-lançadas. Portanto, pesquise nos repositórios de software de sua distribuição 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-o agora!


Eu estava usando o Kernel 4.14.10 por uma semana, então o download e a inicialização do Ubuntu Mainline Kernel versão 4.14.11 não foram uma grande preocupação para mim.

Os usuários do Ubuntu 16.04 podem se sentir mais confortáveis ​​com as versões do kernel 4.4.109 ou 4.9.74 que foram lançadas ao mesmo tempo que o 4.14.11.

Se suas atualizações regulares não instalam a versão do Kernel desejada, você pode fazê-lo manualmente, seguindo esta resposta do Ask Ubuntu: https://askubuntu.com/questions/879888/how-do-i-update-kernel-to-the-latest -mainline-version / 879920 # 879920


14.04.12 - Que diferença faz um dia

Menos de 24 horas após a minha resposta inicial, um patch foi lançado para corrigir a versão do kernel 4.14.11, que eles podem ter apressado. A atualização para 4.14.12 é recomendada para todos os usuários 4.14.11. Greg-KH diz :

Estou anunciando o lançamento do kernel 4.14.12.

Todos os usuários da série 4.14 do kernel devem atualizar.

Existem alguns problemas menores ainda conhecidos nesta versão em que as pessoas se deparam. Espero que eles sejam resolvidos neste fim de semana, pois os remendos não chegaram à árvore de Linus.

Por enquanto, como sempre, teste seu ambiente.

Observando esta atualização, não foram alteradas muitas linhas de código-fonte.

WinEunuuchs2Unix
fonte
11
A solução existe para o Meltdown agora, disponível via apt-get dist-upgrade.
Luchonacho
11
No meu telefone agora, mas a atualização no LTS causa pânico no kernel em 10/01/2018. Veja Pergunte ao Ubuntu.
WinEunuuchs2Unix
11
Felizmente eu atualizei com 109 (108 dá pânico ao kernel). Então não tive esse problema. Funciona bem.
Luchonacho
11
@ WinEunuuchs2Unix, há uma atualização aqui USN-3531-2: Regressão em microcódigo da Intel
GAD3R
11
@ GAD3R Muito obrigado pelo link. Ele me ajudar a postar uma resposta no Ask Ubuntu que poderia ajudar muitas pessoas: askubuntu.com/questions/998471/...
WinEunuuchs2Unix
6

Essa falha pode ser explorada remotamente, visitando um site JavaScript.

De fato. Portanto, uma atenuação sensata é desativar o JavaScript nos navegadores da Web ou usar navegadores da Web que não suportam JavaScript.

A maioria dos navegadores que suportam JavaScript possui 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 o JavaScript é permitido, existem vários complementos que podem ajudar, como o uBlock Origin e o NoScript .

NB Não é necessário dizer que desativar / restringir o JavaScript não deve ser sua única atenuação. Você deve revisar adicionalmente (e provavelmente aplicar) quaisquer correções relevantes do kernel e outras atualizações de segurança assim que forem gravadas, testadas e publicadas. Nas distribuições derivadas do Debian, use comandos , tais como sudo apt update , sudo apt list-upgradablee sudo apt upgrade.

Atualizar: não aceite minha palavra. Alan Cox diz o mesmo:

O que você precisa para se preocupar muito é com javascript, porque a exploração pode ser usada remotamente por javascript em páginas da Web para roubar coisas da memória do sistema. ... considere coisas como Adblockers e extensões como noscript, que podem impedir a execução de muito lixo em primeiro lugar. Faça isso o mais rápido possível. Quando as atualizações do sistema operacional aparecerem, aplique-as. ( Fonte )

sampablokuper
fonte
5
Com licença, embora isso ajude contra o attac, sem JS, você não seria capaz de deixar a resposta aqui. Este conselho é semelhante a "parar de usar a Internet" (em 2018).
Moritz Ambos
4
Felizmente, muitos sites funcionam bem sem o JS. Infelizmente, o StackExchange exige JS para postagem, como você aponta. Essa é uma lacuna SE :( (sério!)
sampablokuper
3
Para o FireFox, um addon como noScript pode ajudar a reduzir o uso de JavaScript em sites duvidosos - embora as recentes mudanças provocadas pelo FF Quantum (V57) tenham arremessado uma pedra muito grande em todo o pool de
add
2
Desde o lançamento do Quantum, mudei para Pale Moon, exatamente por esse motivo. Funciona muito bem para mim, incluindo NoScript e Cookie Masters (antes Cookie Monster).
Murphy em
2
@MoritzBoth Eu realmente não acho que desabilitar o JS equivale a "parar de usar a web", muito menos "parar de usar a internet". No entanto, este é um ótimo momento para aumentar a conscientização sobre os problemas que vêm com a dependência universal de JS de alguns provedores de conteúdo da web.
precisa saber é o seguinte
5

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, pois dessa maneira o código remoto pode ser facilmente executado em seu sistema, mas esse 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 estar corrigida. Infelizmente, para a maioria da onda atual de bugs, isso não parece ser possível. O Debian, junto com todas as outras partes fornecedoras de SO, irá, portanto, a única outra maneira possível, além de recomendar uma CPU que não seja falha: forçam o sistema a solucionar o bug na CPU. Esses patches não corrigem os problemas. Em vez disso, o sistema operacional os oculta da melhor forma possível em qualquer programa que um usuário executa na máquina (e, portanto, também no seu navegador).

Essa ocultação é um trabalho computacional extra e, portanto, o desempenho geral do sistema será menor do que sem. Quanto menor depende provavelmente do que exatamente esses programas fazem.

Com isso em mente, de volta à 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 rodar 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 numerosos gurus de hardware e Linux. Não quero impedi-lo de tentar algo sozinho ou de tentar ajudar o esforço geral. No entanto, se você tem interesse em sua própria segurança e uma correção oportuna, é provável que eles encontrem uma solução melhor em menos tempo do que você, começando agora a analisar isso por conta própria.

user68856
fonte