Processador Vulnerabilidade MeltDown / Spectre (aka Kaiser bug)

As falhas só afectarão a credibilidade quando houverem ataques claros que afectem pessoas. Até lá, toda a gente vai achar que é algo teórico. Somos pouco dados à prevenção, infelizmente.
 
Não sei se é bem assim. Com as mitigações que foram sido implementadas a performance de determinadas referências de processadores sofreu redução, o que em ambiente de servidores é importante.
Duvido que tal coisa não tenha afectado a reputação da Intel.
 
Neste momento, a Intel ainda se dedica a corrigir este tipo de falhas de segurança com patches de bios ou software.
Mas assim que lancem uma nova arquitetura, esse suporte vai desaparecer aos poucos e isso significa que passado algum tempo, qualquer nova falha que seja descoberta não vai ter solução.
A Intel ainda vai fazer muito dinheiro a obrigar as empresas a fazer o upgrade.
 
eenqAzz.png


Outch!!!
Eu espero mesmo que este LVI não seja pratico em processadores sem SGX, porque mesmo que existam aperfeiçoamentos nos patchs, este hit de performance é brutal.
 
Outch!!!
Eu espero mesmo que este LVI não seja pratico em processadores sem SGX, porque mesmo que existam aperfeiçoamentos nos patchs, este hit de performance é brutal.

Isto para os servidores web vai ser uma autentica porcaria. Se compilarmos o openssl com as novas mitigações, dá um drop de 88,65%, 1217 sigs/s para 138 sigs/s. Ninguém vai aplicar as mitigações, é impossível.

8667_upload_2020-3-13_9-44-38.png
 
Este LVI, por enquanto, é um ataque mais teórico, a não ser quando SGX é usado. Por isso, não me parece que seja preciso usar todas as mitigações, na maior parte dos casos.
O medo aqui é se aparecerem mais vulnerabilidades semelhantes a este LVI, que não precisem do SGX e/ou que sejam mais fáceis de usar.

Usar todas as mitigações, nesta altura, é praticamente impossível. A quebra de performance é demasiado grande em quase todos os programas.
 
Mais um dia, mais uma vulnerabilidade para os processadores da Intel. Crosstalk.

CROSSTALK

For the first time, we show that speculative execution enables attackers to leak sensitive information also across cores on many Intel CPUs, bypassing all the existing intra-core mitigations against prior speculative (or transient) execution attacks such Spectre, Meltdown, etc. Until now, all the attacks assumed that attacker and victim were sharing the same core, so that placing mutually untrusting code on different cores would thwart such attacks. Instead, we present a new transient execution vulnerability, which Intel refers to as “Special Register Buffer Data Sampling” or SRBDS (CVE-2020-0543), enabling attacker-controlled code executing on one CPU core to leak sensitive data from victim software executing on a different core.

XBuOR07.png


Mitigations

Intel has implemented its mitigation for the SRBDS vulnerability in a microcode update distributed to software vendors on Tuesday June 9, 2020 or earlier. The mitigation locks the entire memory bus before updating the staging buffer and only unlocks it after clearing its content. This strategy ensures no information is exposed to offcore requests issued from other CPU cores. Due to the considerable performance overhead of locking the entire system’s memory bus, Intel only applied the mitigation to harden a small number of security-critical instructions, specifically RDRAND, RDSEED, and EGETKEY (a leaf of the ENCLU instruction). This means that output from any other instruction (e.g., RDMSR) that issues offcore requests can be still leaked across CPU cores.

https://www.vusec.net/projects/crosstalk/

Este ataque é interessante, porque funciona entre diferentes cores no mesmo CPU.
O fix é parcial, devido aos impactos de performance e é via microcode.
Desta vez, desligar SMT não ajuda em nada e, mais uma vez, o SGX ajuda ao ataque.

Desta vez a Intel não ficou "sozinha". Também foi descoberto um Side channel Attack em ARM.

Straight-Line Speculation (SLS)

Arm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13844
 
Mais um dia, mais uma vulnerabilidade para os processadores da Intel. Crosstalk.



XBuOR07.png




https://www.vusec.net/projects/crosstalk/

Este ataque é interessante, porque funciona entre diferentes cores no mesmo CPU.
O fix é parcial, devido aos impactos de performance e é via microcode.
Desta vez, desligar SMT não ajuda em nada e, mais uma vez, o SGX ajuda ao ataque.

Desta vez a Intel não ficou "sozinha". Também foi descoberto um Side channel Attack em ARM.



https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13844


Acredito que a china faz espionagem atravez de suas empresas chinesas... acredito no Trump, como acredito que os EUA faz igual e a muito tempo com os deles... intel..... haha digam que não que acredito! Problema é agora não ser só eles a terem acesso :facepalm:
 
Mais um dia, mais uma vulnerabilidade...

New SMM Callout Privilege Escalation Vulnerability Affects AMD Platforms
a new security vulnerability affecting certain client- and APU processors launched between 2016 and 2019. Called the SMM Callout Privilege Escalation Vulnerability, discovered by Danny Odler, and chronicled under CVE-2020-12890, the vulnerability involves an attacker with elevated system privileges to manipulate the AGESA microcode encapsulated in the platform's UEFI firmware to execute arbitrary code undetected by the operating system. AMD plans to release AGESA updates that mitigate the vulnerability (at no apparent performance impact)
https://www.techpowerup.com/268680/...scalation-vulnerability-affects-amd-platforms

Edit: a vulnerabilidade não está no CPU mas na motherboard.
 
Eu nao sei como a nivel empresarial isto não esta a dar mais salgalhada, ou entao ninguem anda a aplicar patchs.

Recentemente levei com este problema, num Servidor HPE DL 380 Gen9, em que a board morreu e foi substituida, por uma nova com firmwares atualizados.
O impacto na performance dos arrays foi enorme( a nivel de processamento tambem deve ter sido, mas como a maquina tem muita disponibilidade, não se notou).
Tive quebras na performance em alguns parametros até 60% em arrays com ssd´s (nos outros arrays com SAS e Sata a diferença foi residual).

Contactada a HPE diz que a performance parece bem e para correr o SPP de Março para atualizar firm e drivers, piorou ainda mais, mas nada de significativo face ao que já estava.
Relembrei a HPE que tinha mais servidores exatamente iguais(não intervencionados, com boa performance) a replicar e que os testes comparativos foram feitos em condições identicas, em que me dizem para atualizar os servidores que tem boa perfrmance para os firmwares mais recentes tambem. Nem lhes respondi mais.

Reverti os updates de firmware na maquina intervencionada para a versão das outras maquinas e a performance voltou ao espectavel.
 
Eu nao sei como a nivel empresarial isto não esta a dar mais salgalhada, ou entao ninguem anda a aplicar patchs.
A nível empresarial, de grande dimensão, a Intel deve andar a oferecer grandes descontos em novas aquisições aos maiores clientes e/ou a pagar compensações.

A quebra de performance é enorme em data centers com centenas e milhares de cpu's. Representa uma quebra de performance/rendimento e aumento de custos (para repor a performance, maior consumo energético para mesma performance, tempo de técnicos perdido a repor a disponibilidade de performance, etc) brutal para as empresas.

Aos grandes clientes a Intel tem sabido fazer damage control e abrir os cordões à bolsa para manter as coisas calmas.

O mexilhão é que se lixa.
Mas nos EUA estava a correr dezenas de lawsuits relacionados com isto. Não sei como está, mas é bem capaz de a Intel ter que pagar umas centenas de milhões.
 
Última edição:
Back
Topo