Contents [show]
1. Sobre a vulnerabilidade do Zombieload / MDS
2. 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.

KernelCare começou a testar patches ao vivo para MDS na sexta-feira, maio 17, e eles estão agora lançado para todas as principais distribuições, com outros em breve a seguir. Para as últimas notícias, siga-nos no @KernelCare.

Assista ao vídeo com os insights sobre MDS de Igor Seletskiy abaixo ou role para baixo para obter instruções sobre como mitigar a vulnerabilidade de MDS / Zombieload sem necessidade de reinicialização.

Novo call-to-action

Como atenuar a vulnerabilidade do MDS / Zombieload

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.

Etapa 3: Aplicar patches 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 30-day.

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-day.

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

Segunda-feira atualizada, maio 27

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
  • 7 CentOS
  • CentOSPlus para CentOS 7
  • CloudLinux OS 6
  • Híbrido Cloud Linux 6
  • CloudLinux OS 7
  • Debian 8
  • Debian 9
  • Ubuntu 14.04 LTS (Trusty Tahr)
  • Ubuntu 16.04 LTS (Xenial Xerus)
  • Ubuntu 18.04 LTS (Bionic Beaver)
  • Oracle Enterprise Linux
  • Oracle Enterprise Linux 6
  • Oracle Enterprise Linux 7
  • Oracle UEK 3
  • Oracle UEK 4
  • Oracle UEK 5
  • OpenVZ
  • Proxmox VE
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Amazon Linux 1
  • Amazon Linux 2

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

comentários 43

  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!

    2. Interessante, já que não tenho problema em entendê-lo e sou um nova-iorquino - tenho poucos amigos com sotaques semelhantes e não tenho habilidades especiais no idioma. Acho Igor incrivelmente experiente e um orador muito interessante. Eu ficaria desapontado por perder a voz dele.

    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. Olá Deyan, obrigado por trazer isso à minha atenção! Estamos trabalhando para consertar a documentação agora. Por favor, aceite minhas desculpas pelo inconveniente. Eu mencionarei você nos comentários quando consertarmos.

      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. INCORRETO, POR FAVOR DESISTIR A ISSO: Oi Paul, você precisa atualizar o microcódigo real como descrito aqui, atualizando o pacote microcode_ctl não é suficiente

          1. Oi Alexandra, isso não é verdade. Esse manual é apenas para atualizar o microcódigo sem reiniciar. A reinicialização deve sempre aplicar novo microcódigo, mas parece que isso não está acontecendo após a atualização mais recente do pacote microcode_ctl, portanto "/ sys / devices / system / cpu / vulnerabilidades / mds" sempre retorna "no microcode", mesmo quando o microcódigo é aplicado manualmente .

          2. Olá Deyan, você pode criar um ticket para nossa equipe de suporte? aqui. Meus colegas poderão aprofundar os detalhes técnicos de seu caso e evitaremos comentários nos comentários. Obrigado!

          3. Eu acho que meu post não foi bem entendido. Você quer dizer que agora está empurrando o pacote microcode_ctl 20190514 (que é o mais recente) e suporta CPUs E5 v4?
            Lucas Rolff perguntou quando você apoiaria o mesmo, e você perguntou qual erro ele estava tentando aplicar o 20190507. Em sua resposta a ele, você confirmou que o pacote microcode_ctl fornecido pelo CloudLinux e pelo CentOS no momento contém apenas o microcódigo 20190507, não o 20190514 que suporta CPUs E5 v4. Então, como agora, aqueles de nós usando CPUs E5 v4 não atualizaram porque o microcódigo 20190507 que você forneceu não funciona para CPUs E5 v4.

            Desde que você pediu Lucas para o erro e ele não forneceu. Eu continuei e fiz. Mas acho que sua resposta me indicou uma direção diferente.

          4. Paul, Lucas, Deyan, desculpe por desinformar você - temos que esperar que o microcódigo 20190514 fique disponível a partir do upstream - vamos liberá-lo no CL OS logo depois disso

    1. Olá Richard, estamos trabalhando para movê-los para produção em breve.
      Vai atualizar o post e anunciá-lo em nossa página do Facebook quando estiver pronto.
      Por favor, aceite minhas desculpas por qualquer inconveniente causado pelo atraso.

    1. Olá Andre, a equipe KernelCare está trabalhando no patch para o CL7. Pedimos desculpas por qualquer inconveniente que esse atraso possa causar e esperamos que você entenda.

      1. Alguma explicação para esse longo atraso? O patch é mais complicado ou problemático no CL7? Eu esperava que o patch para o seu próprio sistema operacional tivesse prioridade.

    1. Olá Sumesh, obrigado pela sua pergunta. Estamos trabalhando ativamente nesses patches. O ETA será conhecido amanhã. Você receberá a notificação em nossos canais sociais.

  5. Alguma notícia no microcódigo? Minhas máquinas ainda estão vulneráveis:

    [root @ hotspare ~] # cat / sys / devices / system / cpu / vulnerabilidades / mds
    Vulnerável: Limpar buffers de CPU tentados, sem microcódigo; SMT desativado

    processador: 15
    vendor_id: GenuineIntel
    família cpu: 6
    modelo: 45
    nome do modelo: CPU Intel (R) Xeon (R) E5-2690 0 @ 2.90GHz
    revisão: 7
    microcódigo: 0x714
    CPU MHz: 1199.896
    tamanho do cache: 20480 KB

      1. Para outras pessoas que têm esse problema: o microcódigo não é liberado para todos os processadores, então você pode estar sem sorte também. Verifique / sys / devices / system / cpu / vulnerabilidades / mds para ter certeza de que você está protegido.

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, envie um e-mail para sales@cloudlinux.com ou Preencha este formulário.