Não quero escrever sobre Spectre, mas preciso: semana passada, essa é de longe a notícia mais importante. As novas opções de vulnerabilidade Spectre, bem como as originais, foram mostradas por representantes da comunidade acadêmica. Um pesquisador do Instituto de Tecnologia de Massachusetts Vladimir Kiryansky e o especialista independente Karl Waldspurger mostraram duas novas modificações no Spectre, chamadas Specter 1.1 e Specter 1.2, sem logotipos ou logotipos (
notícias ,
trabalho científico original).
Diferenças importantes da vulnerabilidade Spectre original em ambos os casos são o uso de um mecanismo de gravação especulativo. No caso do Spectre 1.1, um ataque teoricamente permite que você cause um estouro de buffer (também especulativo) e leia a seção "proibida" da memória. O Spectre 1.2 fornece a capacidade de sobrescrever informações somente leitura e, teoricamente, permite que um ataque de fuga da sanbox contorne os sistemas de proteção de hardware. Para a descoberta da vulnerabilidade, os pesquisadores receberam cem mil dólares como parte do programa de bugs da Intel, e hoje é um dos maiores pagamentos. As vulnerabilidades são afetadas pelos processadores Intel, ARM e, provavelmente, AMD.
Segundo os autores, uma das principais conclusões do estudo é precisamente o novo conceito de "excesso de buffer especulativo". Um estouro provoca uma operação de gravação - executada no momento e no lugar certos, inevitavelmente será descartada como incorreta, mas mesmo antes disso, abre a possibilidade de ler uma área de memória à qual o processo de ataque não deve ter acesso.
Uma ilustração importante da idéia: a verificação de limites não está usando uma operação de leitura, como no Spectre original, mas com uma operação de gravação.A lista de condições sob as quais uma das novas vulnerabilidades pode ser implementada na prática ocupa quase mais espaço do que uma descrição do mecanismo de ataque. Essa é a complexidade das vulnerabilidades de hardware dessa classe: muito deve coincidir para que o ataque seja bem-sucedido. Porém, quando ocorre um ataque, na pior das hipóteses, ele permite que você roube informações valiosas, muitas vezes sem a possibilidade de entendimento pós-factum do que exatamente aconteceu. Mais importante: As condições do Spectre 1.x podem ser criadas mesmo quando um ataque do Spectre 1.0 não é possível.
Os pesquisadores argumentam que não há como detectar vulnerabilidades como o Spectre 1.1 por meio de ferramentas de análise ou compilação de código. Além disso, essa vulnerabilidade pode ser fechada no nível do ferro. Note-se também que a responsabilidade pela redução dos riscos de um ataque bem-sucedido do Spectre é geralmente de responsabilidade dos desenvolvedores de software. Considerando que, nos 30 anos que se passaram desde a primeira demonstração pública de um ataque com estouro de buffer, as vulnerabilidades no software se tornaram muito menores, os autores prevêem ataques ao mecanismo de execução especulativa de código da “década” de relevância.
Não obstante o exposto, os autores acreditam que teoricamente é possível uma combinação de software e hardware seguro com os benefícios da proteção contra mecanismos de execução especulativos. Resta implementar isso na prática, que, no caso de uma classe de vulnerabilidades que afetam o hardware, pode levar anos ou décadas. Eu me pergunto se a história de Spectre / Meltdown e seus derivados não se tornará um passo em direção a uma mudança séria na prática de desenvolvimento de software e hardware?
Isenção de responsabilidade: as opiniões expressas neste resumo nem sempre coincidem com a posição oficial da Kaspersky Lab. Caros editores, geralmente recomendam tratar qualquer opinião com ceticismo saudável.