Processador Vulnerabilidade MeltDown / Spectre (aka Kaiser bug)

Reverti os updates de firmware na maquina intervencionada para a versão das outras maquinas e a performance voltou ao espectavel.
Como não sei qual o negócio envolvido, não sei até que ponto isto é importante para a empresa onde estás, mas as falhas de segurança não te preocupam? Não há riscos de ataques mais problemáticos?
 
Não se trata de um compromisso entre segurança vs performance, estas maquinas são hosts onde so correm vms em cima, e todos os serviços são internos não tem exposição publica.
Mesmo internamente não será facil alguem conseguir executar codigo numa destas maquinas.
Acima disso existem varias camadas de segurança, e varios mecanismos de backup.

Preferia aplicar os patchs e não ter problemas de performance, mas tenho de decidir com aquilo que tenho.
 
Onde isto tem dado mais salgalhada é exactamente no mercado empresarial, mas por estranho que pareça, estes problemas de segurança parece que têm sido favoráveis à Intel.

Têm lido as análises sobre os resultados muito bons a cada trimestre, na parte Datacenter da Intel?
Todos eles apontam para o seguinte:
  • São descobertos problemas de segurança com os processadores Intel.
  • São lançados patchs que pioram a performance, especialmente em workloads servidor.
  • As empresas testam a aplicação dos patchs e verificam que têm pior performance.
  • Como grande parte deste mercado dá prioridade à segurança, têm que aplicar os patchs em produção. Solução para a perca de performance? Comprar mais servidores.
  • No mercado de servidores, com que processadores há mais soluções? Intel.
Conclusão, devido à perca de performance, vendem-se mais servidores, beneficiando assim economicamente a Intel.


Voltando à salgalhada e perca de performance. Leram a mitigação do "Crosstalk"?

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.

A Intel só aplicou a mitigação em algumas instruções, porque senão, a performance vinha por aí abaixo. A própria Intel não pode dar 100% de prioridade à segurança.

Só para terem uma ideia. Uma das instruções é o "RDRAND". Com a mitigação, o "RDRAND" ficou 97% mais lento num E3-1200 Skylake.

PkD9GOA.png


Sim, é "só" uma perca de 97%. Coisa pouca.....

Eu não sei como é que a Intel ainda não levou com processos em tribunal nos USA.
 
PkD9GOA.png


Sim, é "só" uma perca de 97%. Coisa pouca.....

Eu não sei como é que a Intel ainda não levou com processos em tribunal nos USA.

:004:Intel:004:

:freak3:Minha pequena empresa com 5 maquinas intel e um pequeno servidor :freak3:

Processar alegando problemas de segurança e depois perda de performance em tribunais portugueses :freak3: :facepalm: :berlusca:



Uma questão a AMD está tão venerável quanto a Intel?

é que perda de performance ou segurança é preocupante... isto não dá qualquer cliente processar a mesma? :lol: estou a rir... mas conhecendo a justiça também sei se for um processo colectivo em massa, poderá vir a intel ter que ser responsabilizada, bem talvez nem seja boa ideia, a Intel iria a falecia se tiver compensar todos :joker: poderia ter grande impacto quer pessoas ficarem sem trabalho, quer o mercado sem um player em cpu's

isto é o que aprendi em gestão quando um sistema grande depende de uma determinada enorme firma... estamos a falar dependência mundial :004: e tornar o mercado desequilibrado sem um grande player em cpu.

Resumido a AMD está ou não tanto afectado com estes problemas?
 
Resumido a AMD está ou não tanto afectado com estes problemas?

Não está, pelo menos do que é conhecido até agora. Não é que a AMD e outras arquitecturas estejam imunes. Qualquer processador out of order vai ser alvo de ataques e em processadores onde a performance é importante, é quase tudo out of order há muitos anos.
No entanto, a quantidade de problemas descobertos em AMD e outras arquitecturas tem sido bem menor e mesmo quando são afectados, às vezes não é de forma tão grave.
A Intel parece ter dois factores para serem tão afectados, além do out of order. A forma como implementaram SMT (conhecido em Intel como Hyperthreading) e a forma como implementaram SGX.

Do lado da Intel, de uma forma melhor ou pior, do Pentium Pro aos Skylakes, quase todos os processadores podem ser considerados "broken". As excepções são alguns Atoms antigos, Quark e.........pouco mais.
 
Não está, pelo menos do que é conhecido até agora. Não é que a AMD e outras arquitecturas estejam imunes. Qualquer processador out of order vai ser alvo de ataques e em processadores onde a performance é importante, é quase tudo out of order há muitos anos.
No entanto, a quantidade de problemas descobertos em AMD e outras arquitecturas tem sido bem menor e mesmo quando são afectados, às vezes não é de forma tão grave.
A Intel parece ter dois factores para serem tão afectados, além do out of order. A forma como implementaram SMT (conhecido em Intel como Hyperthreading) e a forma como implementaram SGX.

Do lado da Intel, de uma forma melhor ou pior, do Pentium Pro aos Skylakes, quase todos os processadores podem ser considerados "broken". As excepções são alguns Atoms antigos, Quark e.........pouco mais.

esses patchs são realizados como? tem de ser manual ou tipo ao actualizar a bios de uma board vem isso? ou é de outra forma a aplicação dos patchs... digo isso pois na minha empresa como sou um casmurro, tudo o sistema informática é numa rede interna sem ligação a net... mesmo o servidor....

só temos net num dos pc, esse não ligado a rede interna haha esse pc tem um nome malacioso cá que não vou comentar, é feio :D e wireless para o pessoal mas nos seus telemoveis... nos pc não tem wifi etc... sempre aprendi melhor segurança é não ligado à net e dificultar a mesma... querem usar net usem nos seus telemóveis nem me importo, até partilho wifi com todos.
 
esses patchs são realizados como? tem de ser manual ou tipo ao actualizar a bios de uma board vem isso? ou é de outra forma a aplicação dos patchs... digo isso pois na minha empresa como sou um casmurro, tudo o sistema informática é numa rede interna sem ligação a net... mesmo o servidor....

Depende, mas normalmente é uma mistura de Microcode, drivers (em problemas com o Intel ME, por exemplo) e Sistema Operativo/Compiladores.

O Microcode pode ser aplicado com novas versões de BIOS ou pode ser aplicado a cada boot, pelo Sistema Operativo.

Em *nix, para verificar os computadores, tens o "spectre-meltdown-checker" e penso que actualmente o dmesg e o lscpu também reportam.
Em Windows tens o "Get-SpeculationControlSettings" em Powershell.

só temos net num dos pc, esse não ligado a rede interna haha esse pc tem um nome malacioso cá que não vou comentar, é feio :D e wireless para o pessoal mas nos seus telemoveis... nos pc não tem wifi etc... sempre aprendi melhor segurança é não ligado à net e dificultar a mesma... querem usar net usem nos seus telemóveis nem me importo, até partilho wifi com todos.

Até agora, acho que quem tem que estar mais preocupado são alvos grandes e importantes. Para o mercado mais "comum", a partir do momento que grande parte das pessoas coloca as passwords em post-its e abre o que quer que seja que venha num email, talvez não faça grande sentido andar a perder tempo e trabalho a explorar bugs de processadores.
 
É mais uma rodada para a mesa do canto faxabor

Security researchers from Graz University of Technology and CISPA Helmholtz are out with their latest findings on CPU speculative execution vulnerabilities, namely taking another look at L1TF/Foreshadow.
In turn this research means that existing mitigation techniques may not be enough, there are other new vectors discovered as a result, and ARM/IBM/AMD CPUs may also be affected by Foreshadow.

The new vulnerability outlined in the paper is "Dereference Trap" for leaking registers from an SGX enclave in the presence of only a speculative register dereference.

The discovery of speculative dereferencing of a user-space register in the kernel as opposed to the prefetcher not only means that some mitigations may be inadequate, but they can improve the performance of the original attack and reportedly produce similar behavior on non-Intel CPUs.
https://www.phoronix.com/scan.php?page=news_item&px=Reviving-Foreshadow-Bad
 
Se tiverem um computador com Intel AMT, vão querer actualizar os drivers e firmware do Intel ME.

CVEID: CVE-2020-8758

Description: Improper buffer restrictions in network subsystem in provisioned Intel(R) AMT and Intel(R) ISM versions before 11.8.79, 11.12.79, 11.22.79, 12.0.68 and 14.0.39 may allow an unauthenticated user to potentially enable escalation of privilege via network access. On un-provisioned systems, an authenticated user may potentially enable escalation of privilege via local access.

CVSS Vector (Provisioned, unauthenticated, network):

CVSS Base Score: 9.8 Critical

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00404.html

É "bom" ver que o Intel ME continua a dar barraca. A Intel está quase a conseguir o 10 perfeito.......

De referir que não é preciso ter um processador vPro para ter o AMT ligado. O AMT funciona em processadores sem vPro, com funcionalidades limitadas.

Se tiverem computadores com AMT, devem ver 2 pacotes novos nos fabricantes. Uma para os drivers, outro para o firmware. Exemplos:
hkwbXJL.png


fFpYDIS.png
 
Se tiverem um computador com Intel AMT, vão querer actualizar os drivers e firmware do Intel ME.



https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00404.html

É "bom" ver que o Intel ME continua a dar barraca. A Intel está quase a conseguir o 10 perfeito.......

De referir que não é preciso ter um processador vPro para ter o AMT ligado. O AMT funciona em processadores sem vPro, com funcionalidades limitadas.

Se tiverem computadores com AMT, devem ver 2 pacotes novos nos fabricantes. Uma para os drivers, outro para o firmware. Exemplos:
hkwbXJL.png


fFpYDIS.png
Suponho que não valha a pena instar no meu portátil Ivy Bridge de 2012? Como sei se é afetado por este CVE?
 
A Intel já não suporta versões de AMT 10.X para baixo. Eles só lançaram updates a partir das versões 11.X. Simplificando, só suportam a partir do Skylake.
Referem que não testaram versões anteriores, por isso o problema pode estar lá, ou não, desde o socket 775 (versão 3.X). Seja como for, essas versões não terão updates.

De referir que normalmente o AMT só está ligado em plataformas empresárias. Em desktops, normalmente são os que têm chipset Intel QXXX. Em portáteis, nas gamas empresariais de cada fabricante.

Há uma ferramenta em Linux que dá para verificar se o AMT está ligado se estiver, se está provisionado.
https://github.com/mjg59/mei-amt-check

Em Windows não conheço algo igual.
 
Ainda não percebi como é que um eventual 'hacker' pode explorar essa vulnerabilidade. É através de um email, de um vírus, etc... E que implicações práticas tem no nosso computador pessoal, isto é, quais são, especificamente, os danos que pode causar no mesmo?
 
É através da execução de software, tendo acesso limitado a uma máquina ou enganando alguém a correr esse software na máquina pretendida.
Os danos, depende do que se pretende. Na maioria dos casos, provavelmente vai-se tentar escalar privilégios. Numa máquina *nix, ficar com acesso root. Numa máquina Windows, ficar com acesso administrator. A partir daí, se quem ataca tiver cuidado e alguma sorte, é Game Over. O alvo pode nem se aperceber.

Este tipo de exploits provavelmente é demasiado complexo para a maioria dos ataques, visto que há formas mais simples de se atingir o "utilizador comum". Isto, se este tipo exploits não for incorporado naqueles kits de hacking que fazem com que qualquer um os possa usar.
O outro problema é que um ataque destes pode não ser de fácil detecção.
 
:n1qshok:

Google Publishes "Leaky.Page" Showing Spectre In Action Within Web Browsers

Google's Leaky.Page code shows its possible to leak data at around 1kB/s when running their Chrome web browser on a Skylake CPU. The proof-of-concept code is catering to Intel Skylake CPUs while it should also work for other processors and browsers with minor modifications to the JavaScript. Google was also successful in running this Leaky.Page attack on Apple M1 ARM CPUs without any major changes.
https://www.phoronix.com/scan.php?page=news_item&px=Google-Leaky.Page-Spectre
 
Back
Topo