Contents [show]

Sobre a vulnerabilidade do Zombieload / MDS

Programação de Liberação de Patch


Sobre a vulnerabilidade do Zombieload / MDS

Vulnerabilidades estão se tornando como celebridades, com nomes esquisitos e seus próprios sites.

Os mais recentes a acertar a cena são Zombieload, RIDL e Fallout, também conhecidos como Amostragem de Dados Microarquitetural, (MDS abreviado), descoberto por Intel e pesquisado por departamentos acadêmicos em instituições focadas em segurança em todo o mundo. Essas vulnerabilidades estão na mesma linha que Specter e Meltdown, sendo falhas de design que revelam dados. O Zombieload é particularmente preocupante porque afeta todos os processadores Intel Core e Xeon fabricados desde o 2011.

Há quatro registros de vulnerabilidade distintos combinados para possibilitar uma exploração do Zombieload: CVE – 2018 – 12126, CVE – 2018 – 12127, CVE – 2018 – 12130 e CVE – 2019 – 11091. Olhe para os códigos e você verá três foram registrados no ano passado. A questão foi mantida em sigilo, uma prática conhecida como Divulgação Coordenada, para impedir que "maus atores" explorem vulnerabilidades antes que o resto de nós possa se defender contra eles. microsoft, Amazon AWS e google Todas mitigaram o problema em seus centros de dados, estando no 'círculo interno' de empresas que se beneficiam do aviso prévio de tais problemas. Qualquer outra pessoa tem que esperar por uma atualização do seu fornecedor de SO.

O KernelCare começou a testar patches ao vivo para o MDS na sexta-feira, maio 17, lançando-os para as principais distribuições primeiro, outros mais tarde. Para as últimas notícias, siga-nos no @KernelCare.

Enquanto estamos trabalhando em patches para você - assista ao vídeo com os insights sobre o MDS de Igor Seletskiy:

Como atenuar a vulnerabilidade do MDS / Zombieload

a) Se você estiver executando em hardware

Para mitigar esta vulnerabilidade, você precisará executar as etapas 3 que exigem sem reinicialização se você seguir as instruções abaixo:

-

Atualize o microcódigo sem uma reinicialização

Microcódigo é o código que é executado dentro da própria CPU e é tratado pela Intel. A atualização do microcódigo geralmente é feita na reinicialização: você obtém o novo kernel, ele terá um novo microcódigo e, quando o kernel inicializar, ele instalará um novo microcódigo na CPU.

Você pode atualizar o microcódigo sem reiniciar usando nossas instruções.

-

Desativar Hyperthreading sem uma reinicialização

Se você não desabilitar o multithreading simultâneo da CPU (SMT), você ainda terá um problema que o invasor poderá ler os dados da mesma CPU.

Com o KernelCare você pode desabilitar o Hyperthreading sem reiniciar usando nossas instruções.

-

Aplicar patches do KernelCare

Mesmo se você tiver feito as etapas 1 e 2, ainda deverá atualizar o Kernel do Linux para garantir que o usuário local não possa ler os dados que estão sendo executados na CPU.

Com o KernelCare você pode fazer isso sem reiniciar. Inscreva-se para o teste gratuito de 30 dias.

b) Se você estiver executando em uma máquina virtual

Você só precisa corrigir o kernel do Linux dentro da VM. Certifique-se de que o nó do host também esteja atualizado, o que normalmente é feito pelo provedor de serviços.

Se você estiver usando o seu KernelCare - seus patches serão entregues automaticamente pelo KernelCare e você não precisa fazer nada extra.

Se não - este é o momento certo para inscreva-se para o teste gratuito 30-days.

Programação de lançamento de patches de vulnerabilidades do MDS / Zombieload

Atualizado sexta-feira, maio 24

O cronograma de lançamento do patch KernelCare é mostrado abaixo. Os cronogramas de lançamento estão sujeitos a alterações. Confira aqui regularmente ou entre em contato com o nosso helpdesk.

Lançado para produção:

  • 6 CentOS
  • CentOSPlus para CentOS 6
  • CloudLinux OS 6
  • Ubuntu 18.04 LTS (Bionic Beaver)
  • Ubuntu 16.04 LTS (Xenial Xerus)
  • Oracle Enterprise Linux 6
  • Oracle Enterprise Linux 7
  • Oracle UEK 3
  • OpenVZ
  • Proxmox VE
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7

Patches do feed de produção serão aplicados automaticamente.

Lançado para o feed de teste:

  • 7 CentOS
  • CentOSPlus para CentOS 7
  • Híbrido Cloud Linux 6

Para instalar patches do alimentação de teste, execute o comando:

kcarectl --test --update

Quando as atualizações de produção estiverem disponíveis, o KernelCare usará o feed regular automaticamente.

Devido sexta-feira, maio 24

  • Debian 8
  • Debian 9
  • CloudLinux OS 7
  • Oracle Enterprise Linux

Segunda-feira, maio 27

  • Amazon Linux 1
  • Amazon Linux 2
  • 7 CentOS
  • CentOSPlus para CentOS 7
  • Oracle UEK 4
  • Oracle UEK 5
  • Ubuntu 14.04 LTS (Trusty Tahr)
Novo call-to-action

comentários 31

  1. Por que Igor Seletskiy insiste em ser a voz, ninguém consegue entender uma palavra maldosa que ele diz. Entendemos que ele está por trás do começo, mas a FFS consegue alguém que pode ser a voz nesses vídeos!

    1. Olá meu, esta é Aleksandra Mitroshkina, gerente de marketing de produto da KernelCare.
      Lamento que você tenha tido dificuldades em entender o orador. Vamos trabalhar na narração para fornecer conteúdo mais compreensível no futuro. Muito obrigado pelo seu feedback!

    1. Olá Andre, não tenho certeza se você está se referindo a patches ou guias de instruções, então vou responder a ambos. Estamos agora na fase de testes com patches. Para algumas distribuições, os patches devem ser no início da próxima semana.
      Quanto aos Guias de Como mencionados em um vídeo e uma postagem no blog, nós os publicaremos assim que os primeiros patches estiverem em produção.

    1. Olá Max, estamos testando os patches agora.
      Planejamos começar a distribuir os patches no início da próxima semana.
      Fique atento para as atualizações.

    1. Olá Arthur, obrigado pela sua pergunta.
      Sim, nós temos isso no pipeline. Siga nossos canais de mídia social para se manter atualizado.

    2. Olá Arthur, infelizmente, devido à falha de comunicação interna, forneci a você as informações erradas sobre nossos planos futuros para o suporte ao OpenVZ 7 do KernelCare. Não estamos planejando suportar essa distribuição.

  2. Se eu tiver o SO cloudlinux com o kernelcare no meu servidor, isso será atualizado com o cuidado do kernel? Ou eu preciso fazer algo manualmente?

    1. Olá Donovan, você precisará atualizar o microcódigo e desativar o SMT. Mas antes de fazer isso, diagnostique sua vulnerabilidade usando o guia neste artigo pela CloudLinux OS Team.

      Quando você executa a atualização do mictocode e a desativação do SMT (você saberá se precisa desativá-lo no link acima) Os Patches do Kernel do Linux serão entregues pelo KernelCare automaticamente, sem a reinicialização.

      1. Basicamente, se você não reinicializou em algum momento, isso não funcionará, porque eles não existem:
        / sys / devices / system / cpu / vulnerabilities

  3. Por que uma atualização do kernel funciona apenas para VMs? Não é um hipervisor atualizado e é necessário reiniciá-lo. Também vi pacotes atualizados do qemu para o sinalizador md-clear.

    1. Oi Stefan, Ele também funciona para nós fortes, mas você precisa atualizar o microcódigo e desativar o SMT - então os patches serão aplicados automaticamente - e sem reinicializações, se você usar o KernelCare.

        1. Oi Stefan,
          Bem, o md-clear no qemu é um pouco cpuid para a informação do convidado.
          O kernel corrigido irá ativar a proteção em qualquer caso.

  4. Você pode possivelmente fazer o upstream do CloudLinux (CentOS, eu acho?) Quando eles irão atualizar o microcode_ctl com os microcódigos mais recentes que irão corrigir os CPUs E5 v4 por exemplo? Os patches estão esgotados há cerca de uma semana, mas nenhuma atualização para o pacote microcode_ctl 🙁

    Alternativamente, o CloudLinux pode enviar um pacote atualizado contendo o 20190514 e não o 20190507 - dessa forma, nós que executamos CPUs v4 e v3 também podem ser atualizados.

      1. Oi Alexandra,

        O pacote microcode_ctl fornecido pelo CloudLinux e pelo CentOS contém os microcódigos 20190507 e não 20190514 (que é o mais recente).

        O 20190514 introduz algumas novas versões de microcódigo desde o 20190507:

        Série VLV C0 6-37-8 02 Atom Z
        VLV C0 6-37-8 0C Celeron N00000838xxx, Pentium N2xx
        VLV D0 6-37-9 / 0F 0000090c Atom E38xx
        Série C0 6-4c-3 / 01 Série 00000368 Atom X
        Série D0 6-4c-4 / 01 00000411 Atom X
        BDX-ML B0 / M0 / R0 6-4f-1 / ef 0b00002e-> 00000036 Xeon E5 / E7 v4; Core i7-69xx / 68xx
        DNV B0 6-5f-1 / 01 00000024-> 0000002e Atom C Series

        1. Oi Lucas, você está correto, agora o pacote microcode_ctl fornecido pelo CloudLinux e pelo CentOS contém apenas o microcódigo 20190507, não o 20190514. A razão por trás disso é que geralmente seguimos as atualizações do upstream do RHEL / CentOS. Assim que este microcódigo aparecer no upstream, nós o forneceremos para o CloudLinuxOS.

      2. Esse manual de atualização de microcódigo é somente para RHEL7. Não está correto para CL6 ...

        stat: não pode declarar `/ usr / libexec / microcode_ctl / update_ucode ': Nenhum arquivo ou diretório

        stat: não pode stat `/ sys / devices / system / cpu / microcode / reload ': Nenhum arquivo ou diretório

        1. Hello Deyan, thank you for bringing this to my attention! We are working on fixing the documentation now. Please accept my apologies for the inconvenience. I will mention you in comments when we fix it.

      3. Na CPU Intel (X) Xeon (R) Servidor E5-2640 v4 @ 2.40GHz executando CL7 e SMT desativado com # echo off> / sys / devices / system / cpu / smt / control
        Microcódigo e Kernel atualizados com #yum upgrade microcode_ctl && yum install kernel-3.10.0-962.3.2.lve1.5.25.8.el7
        Servidor reinicializado.
        # cat / sys / devices / system / cpu / vulnerabilidades / mds retorna o seguinte;
        Vulnerável: Limpar buffers de CPU tentados, sem microcódigo; SMT desativado

        1. INCORRECT, PLEASE DISREGARD THIS: Hi Paul, you need to update the actual microcode as described aqui, atualizando o pacote microcode_ctl não é suficiente

          1. Hi Alexandra, that is not true. That manual is only to update microcode without reboot. Reboot should always apply new microcode, but it looks like that is not happening after your latest microcode_ctl package upgrade, so "/sys/devices/system/cpu/vulnerabilities/mds" always return "no microcode", even when microcode is applied manually.

          2. Hello Deyan, can you please create a ticket to our support team aqui. My colleagues will be able to dig deeper into technical details of your case and we will avoid back-and-forth in comments. Thank you!

          3. I think my post wasn't understood well. Do you mean you are now pushing microcode_ctl package 20190514 (which is the latest) and supports E5 v4 CPUs?
            Lucas Rolff asked when you'd support the same, and you asked which error he was getting trying to apply 20190507. In your response to him, you confirmed that the microcode_ctl package supplied by CloudLinux and by CentOS at the moment only contains the 20190507 microcode, not 20190514 which supports E5 v4 CPUs. So as at now, those of us using E5 v4 CPUs haven't patched up because the 20190507 microcode which you've supplied doesn't work for E5 v4 CPUs.

            Since you had asked Lucas for the error and he didn't provide. I proceeded and did. But I think your answer has pointed me to a different direction.

          4. Paul, Lucas, Deyan, sorry to misinform you - we have to wait for 20190514 microcode to become available from the upstream - we'll release it in CL OS soon after that

XHTML: Você pode usar estas tags: <a href="" title=""> <abbr title = ""> <acronym title = ""> <b> <blockquote cite = ""> <cite> <code> <del datetime = ""> <em > <i> <q cite = ""> <s> <strike> <strong>

Dúvidas?

Se você gostaria de agendar uma demonstração de KernelCare, tiver dúvidas, ou com as investigações experimentação e de vendas, ligue para +1 (800) 231-7307, E-mail [Email protegido]ou Preencha este formulário.