Processador Vulnerabilidade MeltDown / Spectre (aka Kaiser bug)

[Dark Kaeser]

Hmmm.... já era de prever não?

A Survey of Techniques for Improving Security of GPUs






https://arxiv.org/pdf/1804.00114.pdf

https://forum.zwame.pt/threads/vuln...-aka-kaiser-bug.1007042/page-29#post-15259252

Demorou, mas não falhou

Intel's Mitigation For CVE-2019-14615 Graphics Vulnerability Obliterates Gen7 iGPU Performance
https://www.phoronix.com/scan.php?page=article&item=intel-gen7-hit&num=1

When taking the geometric mean of all graphics tests ran, the Core i7 3770K was 18% lower from this lone mitigation while the Core i7 4790K fell by 42%! The mitigated i7-4790K HD Graphics 4600 performance basically put the performance in line with the pre-mitigated i7-3770K graphics performance. Haswell (or at least the Core i7 4790K) appears to get hit particularly hard, more so than the Core i7 3770K. But even the Core i7 3770K performance penalty introduced by yesterday's mitigation patches is very significant. But to reiterate, those not using Gen7 graphics but newer Gen9 (or Gen8) graphics should see minimal difference from the already mainlined mitigation on that front. It's for Ivybridge/Haswell era systems along with the likes of Valley View that are much more impacted by this vulnerability's mitigation.

Many readers have already asked, but no, the current Intel graphics driver patches do not respond to the generic "mitigations=off" kernel parameter that is used for disabling other mitigations. Hopefully before the Gen7 mitigation is mainlined there will be a kernel module parameter to disable this mitigated behavior or some other means of turning it off short of reverting a Git commit and recompiling the Linux kernel. Or ideally Intel is able to devise a new means of mitigation for CVE-2019-14615 on Gen7 that incurs less of a performance hit, but so far there has been no indication of an alternative mitigation.

https://www.phoronix.com/scan.php?page=article&item=intel-gen7-hit&num=4

E já agora

Zhaoxin 7-Series x86 CPUs Mitigated For Spectre V2 + SWAPGS

This patch by a Zhaoxin engineer from Wednesday confirms that the Family 7 processors are not affected by SWAPGS and thus whitelisted from software mitigations.

Additionally, a separate patch whitelists the new Zhaoxin CPUs from Spectre V2 mitigations.

These are the first whitelists we're seeing for any Zhaoxin CPUs within the Linux kernel when it comes to these CPU vulnerabilities.

https://www.phoronix.com/scan.php?page=news_item&px=Zhaoxin-7-Series-Mitigations

 

[DJS]

Se isto continua assim ainda acabo a ir buscar um p3 que tenho là em casa que deve-se mexer melhor que o 4690k com todos os patchs que ainda estão para vir

 

[JPgod]

Mais uma rodada de CVEs de HW da Intel, agora até os GPUs podem ser usados para hack? o que é possível fazer agora?

Os gen7 levam uma talhada do carago, se já eram fracos agora então... E mesmo em 2D levam porrada.

é praticamente uma obsolência programada.

 

[Peter1986]

Uma dúvida, estes patches são atualizados via windows update?
É possível desativá-los?
Obrigados

 

[VelhoDoRestelo]

Ao desactivares uns desactivas todos... O que nao e aconselhavel!

 

[Dark Kaeser]

O patch disponibilizado pela Intel para Linux não dá para desactivar.

E o estudo que tinha citado foi divulgado em Março de 2018, e tal como outros que estiveram na origem do Spectre e afins foram divulgados alguns anos antes.
Mas pela 2° imagem os GPU da Intel não seriam os únicos afectados.

 

[Nemesis11]

Se isto continua assim ainda acabo a ir buscar um p3 que tenho là em casa que deve-se mexer melhor que o 4690k com todos os patchs que ainda estão para vir

Uma boa parte destas vulnerabilidades afectam todos os processadores da Intel desde o Pentium Pro (As excepções são as gerações iniciais do Atom) e outra grande parte afecta todos os processadores Intel com SMT ligado (Apareceu inicialmente a meio da vida do Pentium IV).
A Intel não lança updates de microcode para processadores anteriores ao Sandy Bridge.

Quanto à Gen7.......

LOL.....WTF!!!!
Tenho um 4770T. Felizmente não faz nada a nível gráfico.

 

[Dark Kaeser]

Mais uma rodada.... desta vez para os GPU da AMD

AMD Quietly Patched Four Major GPU Security Vulnerabilities with Radeon 20.1.1 Drivers

Normally you'd expect the shader compiler to properly check all code it compiles and simply reject things that aren't supposed to work.

• The first vulnerability, CVE-2019-5146, is briefly described as "AMD ATI Radeon ATIDXX64.DLL MAD shader functionality denial-of-service vulnerability."
• CVE-2019-5147 describes "AMD ATI Radeon ATIDXX64.DLL MOVC shader functionality denial-of-service vulnerability."
• CVE-2019-5124 points to "AMD ATI Radeon ATIDXX64.DLL shader functionality constant buffer denial-of-service vulnerability."
• CVE-2019-5183 talks about "AMD ATI Radeon ATIDXX64.DLL shader functionality VTABLE remote code execution vulnerability."

The first three CVEs are all variations of a similar approach, which lets malformed shader code lets crash the graphics driver, which in a VM situation would crash the VM software, taking all running virtual machines down with it.

The last vulnerability is more serious, because it potentially allows remote code execution. If you pass a properly crafted shader, you can execute vTable methods, which give you control over code flow, instead of crashing with an error. With further bug exploitation that would let you execute arbitrary code that you supply.

https://www.techpowerup.com/263237/...ty-vulnerabilities-with-radeon-20-1-1-drivers

 

[miguelbazil]

Agora era giro ver que impacto teve em uso.

 

[Dark Kaeser]

É dar um tempo, mas deve vir.
Mas faltará saber ao certo o tipo de vulnerabilidades e se afecta transversalmente todas as "gerações" GPU e iGPU, se é nos controladores de memória e/ou front-end, e se for esse o caso é claro que os maiores efeitos serão notados nas integradas.

 

[Nemesis11]

Mais um dia, mais dois disclosures de vulnerabilidades nos processadores Intel. Está a tornar-se um hábito.

Intel Makes Public Two More Data Leakage Disclosures

Intel last night made public two more data leakage disclosures, which tie back to Zombieload and November's TAA issue.

Here are the new disclosures:
CVEID: CVE-2020-0548
Description: Cleanup errors in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
CVSS Base Score: 2.8 Low

CVE-2020-0549
Description: Cleanup errors in some data cache evictions for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
CVSS Base Score: 6.5 Medium

CVE-2020-0548 is referred to as Vector Register Sampling and CVE-2020-0549 is going as L1D Eviction Sampling.
A speculative execution side channel variant known as L1D Eviction Sampling may allow the data value of some modified cache lines in the L1 data cache to be inferred under a specific set of complex conditions.
L1D Eviction Sampling is to be mitigated by new CPU microcode updates.

A speculative execution side channel variant known as Vector Register Sampling may allow the partial data values of some vector operations to be inferred under a specific set of complex conditions that include vector operations executing after a period of vector inactivity.

Vector Register Sampling will also require CPU microcode updates and they recommend SMT scheduling restrictions to reduce the exposure risk.

https://www.phoronix.com/scan.php?page=news_item&px=Intel-Two-More-Data-Leakage

Os dois problemas só são resolvidos por updates de microcode.

As of writing no CPU microcode updates have been released for Linux users but as soon as that happens I'll begin with some tests for seeing any new performance overhead.

Ainda não vi se há e qual será o hit a nível de performance.

EDIT: Site oficial da vulnerabilidade. https://cacheoutattack.com/

 

[Dark Kaeser]

Acrescentar mais uns à lista...

-

With "Take A Way: Exploring the Security Implications of AMD’s Cache Way Predictors", we reverse-engineered AMD's L1D cache way predictor, resulting in two new attack techniques. Accepted @ #AsiaCCS '20 - https://mlq.me/download/takeaway.pdf - /cc
@duxcode @misc0110 @BloodyTangerine @lavados

https://twitter.com/mlqxyz/status/1235979728860872705

A conta é do Moritz Lipp, parte da equipa da TU Graz que esteve na origem disto tudo.

Spoiler

Michael Schwarz (middle) with Moritz Lipp and Daniel Gruss – and the few lines of code that can be used to execute the ZombieLoad attack. © Lunghammer – TU Graz
https://www.tugraz.at/en/tu-graz/se...ve-ideen-halten-sich-nicht-an-arbeitszeiten0/

-

The scenario that Intel system architects, engineers, and security specialists perhaps feared most is now a reality. A vulnerability has been found in the ROM of the Intel Converged Security and Management Engine (CSME). This vulnerability jeopardizes everything Intel has done to build the root of trust and lay a solid security foundation on the company's platforms. The problem is not only that it is impossible to fix firmware errors that are hard-coded in the Mask ROM of microprocessors and chipsets. The larger worry is that, because this vulnerability allows a compromise at the hardware level, it destroys the chain of trust for the platform as a whole.

http://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html

 

[Nemesis11]

A resposta da AMD:

Take A Way
3/7/20

We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerabilities. AMD believes these are not new speculation-based attacks.

AMD continues to recommend the following best practices to help mitigate against side-channel issues:

• Keeping your operating system up-to-date by operating at the latest version revisions of platform software and firmware, which include existing mitigations for speculation-based vulnerabilities
• Following secure coding methodologies
• Implementing the latest patched versions of critical libraries, including those susceptible to side channel attacks
• Utilizing safe computer practices and running antivirus software

https://www.amd.com/en/corporate/product-security


A vulnerabilidade da Intel é bem interessante:

The EPID issue is not too bad for the time being because the Chipset Key is stored inside the platform in the One-Time Programmable (OTP) Memory, and is encrypted. To fully compromise EPID, hackers would need to extract the hardware key used to encrypt the Chipset Key, which resides in Secure Key Storage (SKS). However, this key is not platform-specific. A single key is used for an entire generation of Intel chipsets. And since the ROM vulnerability allows seizing control of code execution before the hardware key generation mechanism in the SKS is locked, and the ROM vulnerability cannot be fixed, we believe that extracting this key is only a matter of time. When this happens, utter chaos will reign. Hardware IDs will be forged, digital content will be extracted, and data from encrypted hard disks will be decrypted.

http://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html

Nice.......
O Intel ME e AMD PSP são más ideias.

 

[Ansatsu]

Digam-me uma coisa. Com um computador pessoal que está ligado à net, que deve ser a grande a maioria.
Qual a probabilidade de sermos alvos deste tipo de ataque e que o mesmo seja concluído com sucesso?

 

[Nemesis11]

Quais deles?

A maior parte dos que estão aqui nesta thread, provavelmente são demasiado complexos para serem usado em alvos "simples" ou para pretensões mais "simples". Isto é, existem outras vulnerabilidades mais fáceis de explorar nesses casos. Na verdade, muitas das vezes nem é preciso vulnerabilidades, porque o ponto fraco está no utilizador.
Isto também pode ser visto de outra forma. Por serem vulnerabilidades complexas, também poderão ser mais difíceis de descobrir que estão a ser usadas. Além disso, quem pretende aproveitar-se de falhas de seguranças, nem sempre tem um alvo fixo. Por exemplo, em Ransomware muitas quem é atingido é porque é apanhado pela "onda".
Mesmo em alvos "complexos", um utilizador "normal" pode ser apanhado na mesma. Exemplo, ficou-se a saber da existência do Stuxnet quando ele se começou a espalhar por computadores e localizações geográficas não pretendidas. O alvo era uma instalação de enriquecimento de urânio no Irão.

O melhor que um utilizador normal tem a fazer é manter o software actualizado e não correr riscos, pelo menos os mais evidentes. Isso resolve grande parte dos problemas.

O que é discutido nesta thread é preocupante noutros sentidos. Fica-se com a impressão que certas empresas de Hardware não levaram muito a sério questões de segurança, ou, no mínimo, fizeram opções sem pensar nessa área.

Outro problema é a opacidade de muito do hardware e software destas empresas (Casos do ME e PSP). A retirada do poder de decisão aos seus consumidores (também no caso do ME e PSP). Tudo por causa de interesses que nem são sequer muito claros.
A maior parte das pessoas não se apercebe que tem um "mini" computador, dentro do computador, que tem mais controlo sobre o computador, que elas próprias. Isto parece uma frase tirada de uma teoria da conspiração, mas é a realidade que temos.

 

[Ansatsu]

Estava só a tentar perceber se vale a pena perder toda essa performance, que em alguns casos ainda é bastante, se no final nunca seriamos alvos realistas desse tipo de ataques.

 

[Nemesis11]

Mais um dia, mais um..........

You only LVI twice: Meltdown The Sequel strikes Intel chips – and full mitigation against data-meddling flaw will cost you 50%+ of performance

Computer security researchers involved in the discovery of the Meltdown and Spectre vulnerabilities affecting many modern processors have developed a related attack technique called Load Value Injection (LVI).

The attack relies on microarchitectural data leakage to inject and execute malicious code in a way that breaks the confidentiality of modern Intel systems.

Chipzilla's processors, already weighed down by defenses deployed against side-channel attacks over the past two years, could get slower still if they try to thwart this latest vulnerability: prototype compiler changes, for full mitigation, have produced performance reductions ranging from 2x to 19x.

https://www.theregister.co.uk/2020/03/10/lvi_reverse_meltdown_intel_attack/

Bah......

 

[miguelbazil]

Holy hell... Para mim, o que mais me preocupa, é isto:

While LVI utilizes code gadgets cherry-picked from memory, just like Spectre-style branch prediction hijacking, it differs in that it's more broadly applicable. It doesn't require mistraining a branch predictor (so it works on CPUs without prediction components and on systems that have current microcode and compiler defenses)

Afecta CPUs antigos, e tem outros efeitos secundários.. Pretty major. E parar os branch predictors também tem zero efeito agora...

 

[Nemesis11]

Sim, mas é principalmente critico nos processadores com SGX. A mim, o mais preocupante é se este ataque for "prático" nos outros processadores. O SGX torna o ataque muito mais fácil.
O IceLake não é afectado. Talvez afecte AMD, ARM, POWER, etc.

Um pormenor que achei interessante. O disclosure à Intel foi feito a 4 de Abril de 2019 e só passado 11 meses é que se torna publico. Dá que pensar o que mais tem sido descoberto e que ainda não é publico, além do que ainda há por descobrir.

 

[tiagoaal]

Eu no passado ainda pensava que estas falhas seriam catastróficas para a Intel. Hoje em dia sempre que saem noticias do género já nem ligo. Já percebi que afectam zero a credibilidade e a reputação da Intel. Por incrível que pareça, acho que até ganham e muito com estas falhas... Acabam por interessar só do ponto de vista técnico.

Houve outros grupos no passado que não aceitaram os pedidos de Intel, estes pelo contrário foram "simpáticos" e deram quase 1 ano de abébia.