Processador Vulnerabilidade MeltDown / Spectre (aka Kaiser bug)

[Nemesis11]

Já no inicio de Março foi feito upload para o VirusTotal, de um exploit funcional do Spectre para Linux e Windows.

Someone was silly enough to upload a working spectre (CVE-2017-5753) exploit for Linux (there is also a Windows one with symbols that I didn't look at.) on VirusTotal last month, so here is my quick Sunday afternoon lazy analysis.

In the case of /etc/shadow, the default option, the content of the file is shoved in memory by running the following command in the background: return system("echo \"whatever\n\" | su - 2> /dev/null"). In my lab, on a vulnerable Fedora, the exploit is successfully dumping /etc/shadow in a couple of minutes.

https://dustri.org/b/spectre-exploits-in-the-wild.html

Um proof of concept no Browser ainda é mais interessante.


EDIT: Reparei agora nesta parte.

Google's Leaky.Page PoC is a Spectre V1 gadget that is a JavaScript array that is speculatively accessed out of bounds. While the V1 gadget can be mitigated at the software level, Chrome's V8 team determined that other gadgets such as for Spectre Variant 4 to be "simply infeasible in software" for mitigating.

Maravilha.

 

[Ansatsu]

Significa isso que daqui a algum tempo pode começar a aparecer websites que têm o exploit a correr em javascript, e com isso podem fazer dump de dados do nosso sistema, e não há nada que se possa fazer?

Vai ser bonito vai...

 

[Torak]

Um exploit destes a correr num mero site e sem hipoteses de ser mitigado por software...

Realmente, vai ser bonito...

 

[Nemesis11]

Significa isso que daqui a algum tempo pode começar a aparecer websites que têm o exploit a correr em javascript, e com isso podem fazer dump de dados do nosso sistema, e não há que se possa fazer?

Vai ser bonito vai...

Um exploit destes a correr num mero site e sem hipoteses de ser mitigado por software...

Realmente, vai ser bonito...

Acho que a conclusão é mesmo essa. Nesta altura, é impossível prevenir todos os ataques de side channel, por software, nos Browsers. E não é só javascript. Poderão existir outros meios de ataque, via WASM, CSS, etc.

A W3C no dia 11 colocou um Draft cá fora, que basicamente confirma isso.

Post-Spectre Web Development
Editor’s Draft, 11 March 2021

1. Introduction
In early 2018, Spectre made it clear that a foundational security boundary the web aimed to maintain was substantially less robust than expected. [SPECTRE] This revelation has pushed web browsers to shift their focus from the platform-level origin boundary to an OS-level process boundary. Chromium’s threat model, for instance, now asserts that "active web content … will be able to read any and all data in the address space of the process that hosts it". [POST-SPECTRE-RETHINK] This shift in thinking imposes a shift in development practice, both for browser vendors, and for web developers. Browsers need to align the origin boundary with the process boundary through fundamental refactoring projects (for example, [SITE-ISOLATION] and [PROJECT-FISSION]).

1.1. Threat Model
Spectre-like side-channel attacks inexorably lead to a model in which active web content (JavaScript, WASM, probably CSS if we tried hard enough, and so on) can read any and all data which has entered the address space of the process which hosts it. While this has deep implications for user agent implementations' internal hardening strategies (stack canaries, ASLR, etc), here we’ll remain focused on the core implication at the web platform level, which is both simple and profound: any data which flows into a process hosting a given origin is legible to that origin. We must design accordingly.

Pelo que percebo do documento, o objectivo é que cada site corre numa sandbox ainda mais limitada.

1.2. TL;DR

1. Decide when (not!) to respond to requests by examining incoming headers, paying special attention to the Origin header on the one hand, and various Sec-Fetch- prefixed headers on the other, as described in [resource-isolation-policy].
   
   
2. Restrict attackers' ability to load your data as a subresource by setting a cross-origin resource policy (CORP) of same-origin (opening up to same-site or cross-origin only when necessary).
   
   
3. Restrict attackers' ability to frame your data as a document by opt-ing into framing protections via X-Frame-Options: SAMEORIGIN or CSP’s more granular frame-ancestors directive (frame-ancestors 'self' https://trusted.embedder, for example).
   
   
4. Restrict attackers' ability to obtain a handle to your window by setting a cross-origin opener policy (COOP). In the best case, you can default to a restrictive same-origin value, opening up to same-origin-allow-popups or unsafe-none only if necessary.
   
   
5. Prevent MIME-type confusion attacks and increase the robustness of passive defenses like cross-origin read blocking (CORB) / opaque response blocking ([ORB]) by setting correct Content-Type headers, and globally asserting X-Content-Type-Options: nosniff.

A parte que me assusta é esta:

Moreover, browsers must provide web developers with tools to mitigate risk in the short term, and should push the platform towards safe default behaviors in the long term. The bad news is that this is going to be a lot of work, much of it falling on the shoulders of web developers. The good news is that a reasonable set of mitigation primitives exists today, ready and waiting for use.

https://w3c.github.io/webappsec-post-spectre-webdev/

 

[Ansatsu]

https://www.reddit.com/r/Amd/comments/mit9vp

 

[Torak]

A explicação técnica da AMD.

It is common for a CPU to execute a load instruction to an address that was recently written by a store. Many modern processors implement a technique known as Store-To-Load-Forwarding (STLF) to improve performance in such cases. With STLF, data from the store is forwarded directly to the load without having to wait for it to be written to memory. In a typical CPU, STLF occurs after the address of both the load and store are calculated and determined to match.

PSF expands on this by speculating on the relationship between loads and stores without waiting for the address calculation to complete. With PSF, the CPU learns over time the relationship between loads and stores. If STLF typically occurs between a particular store and load, the CPU will remember this. When the CPUsees the store/load pair again, it may predict that STLF will occur and speculatively forward the data from the store to the load. This is done before confirming that the store and load are in fact to the same address.

In typical code, PSF provides a performance benefit by speculating on the load result and allowing later instructions to begin execution sooner than they otherwise would be able to. Most of the time, the PSF prediction is accurate. However, there are cases where the prediction may not be accurate and cause incorrect CPU speculation.

https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf

A AMD recomenda usar "hardware-based sandboxing" ou em certos casos, desligar o PSF.

 

[Nemesis11]

O Phoronix correu mais de 100 testes, com e sem PSF e no máximo, a diferença é menor que 1%.

Resultado final:

Resultados ao detalhe:
https://openbenchmarking.org/result/2104035-PTS-RYZEN75825

Em muitos dos testes, até se tem melhor performance com PSF desabilitado. Os resultados são tão parecidos, que devem estar dentro da margem de erro.

Isto também leva a outra conclusão. Talvez as BIOS deviam vir com o PSF desligado por default, nos Zen3.

 

[Nemesis11]

Mais uma vulnerabilidade para a colecção. O modo de ataque, desta vez, está relacionado com a Micro-op Cache e SMT. Afecta Intel e AMD. Não sei se terá um nome "bonito", mas o nome do paper é “I See Dead µops: Leaking Secrets via Intel/AMD Micro-Op Caches”.

UVA Engineering Computer Scientists Discover New Vulnerability Affecting Computers Globally​

A team of University of Virginia School of Engineering computer science researchers has uncovered a line of attack that breaks all Spectre defenses, meaning that billions of computers and other devices across the globe are just as vulnerable today as they were when Spectre was first announced. The team reported its discovery to international chip makers in April and will present the new challenge at a worldwide computing architecture conference in June.

The researchers, led by ASHISH VENKAT, William Wulf Career Enhancement Assistant Professor of Computer Science at UVA Engineering, found a whole new way for hackers to exploit something called a “micro-op cache,” which speeds up computing by storing simple commands and allowing the processor to fetch them quickly and early in the speculative execution process. Micro-op caches have been built into Intel computers manufactured since 2011.

Venkat’s team discovered that hackers can steal data when a processor fetches commands from the micro-op cache.

“Think about a hypothetical airport security scenario where TSA lets you in without checking your boarding pass because (1) it is fast and efficient, and (2) you will be checked for your boarding pass at the gate anyway,” Venkat said. “A computer processor does something similar. It predicts that the check will pass and could let instructions into the pipeline. Ultimately, if the prediction is incorrect, it will throw those instructions out of the pipeline, but this might be too late because those instructions could leave side-effects while waiting in the pipeline that an attacker could later exploit to infer secrets such as a password.”

Because all current Spectre defenses protect the processor in a later stage of speculative execution, they are useless in the face of Venkat’s team’s new attacks. Two variants of the attacks the team discovered can steal speculatively accessed information from Intel and AMD processors.

“Intel's suggested defense against Spectre, which is called LFENCE, places sensitive code in a waiting area until the security checks are executed, and only then is the sensitive code allowed to execute,” Venkat said. “But it turns out the walls of this waiting area have ears, which our attack exploits. We show how an attacker can smuggle secrets through the micro-op cache by using it as a covert channel.”

“In the case of the previous Spectre attacks, developers have come up with a relatively easy way to prevent any sort of attack without a major performance penalty” for computing, Moody said. “The difference with this attack is you take a much greater performance penalty than those previous attacks.”

“Patches that disable the micro-op cache or halt speculative execution on legacy hardware would effectively roll back critical performance innovations in most modern Intel and AMD processors, and this just isn’t feasible,” Ren, the lead student author, said.

“It is really unclear how to solve this problem in a way that offers high performance to legacy hardware, but we have to make it work,” Venkat said. “Securing the micro-op cache is an interesting line of research and one that we are considering.”

https://engineering.virginia.edu/news/2021/04/defenseless

http://www.cs.virginia.edu/venkat/papers/isca2021a.pdf

Esta caixa de pandora, que foi aberta, vai continuar a dar frutos.
Não sei até que ponto, algumas funcionalidades comuns nos dias de hoje, como SMT, não vão ter que ser abandonadas ou pelo menos desligadas em alguns sectores.

 

[Luka_]

Qualquer que seja o processador, a partir do momento que tenha predictable branches, há sempre a possibilidade de inserir um exploit, não há volta a dar, a não ser cortar esses branches, o problema é a perda de performance a isso associado, já que é muito mais rápido um sim ou não que calcular um novo byte...

 

[Torak]

Todas estes exploits baseiam-se em em questões inerentes ao front-end de um CPU com execução OoO.
Só se voltarmos a um pipeline In-Order, sem SMT, sem branch prediction, etc...

 

[Nemesis11]

A maior parte destas vulnerabilidades têm quase sempre 1 de 2 vectores de ataque, que permitem ou facilitam em muito o exploit. É a presença de SMT ou SGX. Fico com ideia que retirando esses dois do cenário, resolveria ou diminuiria em muito a quantidade e perigosidade destes exploits.
Pelo que percebo, a Intel vai-se livrar do SGX e reformula-lo. Quanto a SMT, não sei bem qual é o plano da Intel e AMD.

 

[Dark Kaeser]

Bulletin ID
AMD-SB-1004
Potential Impact
Arbitrary Code Execution
Severity
Medium

AMD is aware of 2 research papers related to AMD’s Secure Encrypted Virtualization (SEV) which will be presented at this year’s 15th IEEE Workshop on Offensive Technologies (WOOT’21).

In the paper titled “SEVerity: Code Injection Attacks against Encrypted Virtual Machines,” researchers from Fraunhofer AISEC, in partnership with Technical University of Munich, make use of previously discussed research around the lack of nested page table protection in the SEV/SEV-ES feature which could potentially lead to arbitrary code execution within the guest.

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

 

[Nemesis11]

Outch. Nada como uma feature de segurança, ter um problema de segurança grave. Verdade seja dita, é preciso ter acesso de administração do Host, mas uma das finalidades do SEV é exactamente isso. Ter um maior isolamento do Host. A partir do momento que o Host consegue executar comandos arbitrariamente no Guest, é Game Over.

Nos últimos Epyc, a utilização de SEV-SNP resolve o problema. Nos anteriores, é "Best Practices", isto é, se percebo bem, não há forma de resolver directamente.

 

[Nemesis11]

Este é mais interessante do ponto de vista do utilizador final, visto que é feito dentro de um browser (numa tab seaparada) com javascript.

Attacking Tumblr with Chrome's Built-in Credential Manager​

We deployed Spook.js on a Tumblr blog, targeting a password that was autofilled into Tumblr's login page by Chrome's built-in credential manager. We show that our blog can be rendered by the same Chrome process as the login page, and that Spook.js can consequently recover the password.

Attacking LastPass with a Malicious Chrome Extension​

This time, we packaged Spook.js as a Chrome extension. We show that under certain conditions, multiple extensions may be consolidated and executed from the same process. We take advantage of this behavior to read the memory of the LastPass credential manager extension, and recover the master password of the target's vault.

Funciona em processadores Intel e no Apple M1. Em AMD, só parcialmente, até agora.

Have I been affected by this attack?​

If you have an Intel processor or an Apple device with the M1 chip, then yes with very high probability. We also expect our attack to be effective for AMD machines, however this has been only partially demonstrated.

What is the impact of this attack?​

Under certain conditions, malicious JavaScript code running in one Chrome browser tab can read the contents being displayed on another Chrome tab, which might contain sensitive information such as passwords, bank details, etc. Furthermore, malicious extensions might be able to read the contents of other extensions, including sensitive information stored inside them (e.g., passwords inside credential managers).

What other information can be leaked?​

Anything stored in the memory of a website being rendered or a Chrome extension is fair game. In our evaluation, we have demonstrated leakage of the following information:

• The list of same-site tabs which a user currently has open
• Phone numbers, addresses, and bank account information displayed on a website
• Usernames, passwords, and credit card numbers autofilled by credential managers
• Under certain circumstances, images in Google Photos which a user is currently viewing
• Information sensitive to an individual Chrome extension, such as its login information

Já foram feitas alterações no Chrome para inibir este vector de ataque.

Should I stop using Chrome extensions?​

No, you can continue using Chrome extensions. While we have found issues with Chrome's extension isolation, Spook.js is still relatively hard to mount and requires substantial side channel expertise. Moreover, in response to our work, Google has deployed changes to how extensions are laid out in memory, which prevents them from being affected by Spook.js. See the 'What countermeasures are available?' question for more information.

https://www.spookjs.com/
POC - https://github.com/spookjs/spookjs-poc

 

[Dark Kaeser]

AMD EPYC Processors Hit by 22 Security Vulnerabilities, Patch is Already Out

AMD says that "During security reviews in collaboration with Google, Microsoft, and Oracle, potential vulnerabilities in the AMD Platform Security Processor (PSP), AMD System Management Unit (SMU), AMD Secure Encrypted Virtualization (SEV) and other platform components were discovered and have been mitigated in AMD EPYC AGESA PI packages."

The latest updates in question are NaplesPI-SP3_1.0.0.G, RomePI-SP3_1.0.0.C, and MilanPI-SP3_1.0.0.4 AGESA versions, which fix all of 22 security holes.

https://www.techpowerup.com/288984/...security-vulnerabilities-patch-is-already-out

 

[Dark Kaeser]

Intel Says Its CPUs Have Fewer New Bugs Than AMD, Nearly Half Its GPU Bugs Come From AMD​

https://www.tomshardware.com/news/intel-2021-security-report-amd-vulnerabilities

 

[Dark Kaeser]

AMD Quietly Lists 31 New CPU Vulnerabilities, Issues Patch Guidance​

AMD quietly divulged 31 new CPU vulnerabilities in a January update, spanning its Ryzen chips for consumers and the EPYC data center processors. The vulnerability update also includes a list of AGESA versions, with mitigations for the impacted processors.

https://www.tomshardware.com/news/amd-discloses-31-new-cpu-vulnerabilities

 

[Dark Kaeser]

Talvez seja altura de alterar o título do tópico?

https://twitter.com/i/web/status/1664194089917505536

 

[Nemesis11]

Cá vamos outravez.....
Zenbleed. Pelo que percebo, só afecta os Zen 2, via AVX.

It turns out that mispredicting on purpose is difficult to optimize! It took a bit of work, but I found a variant that can leak about 30 kb per core, per second.

This is fast enough to monitor encryption keys and passwords as users login!

We’re releasing our full technical advisory, along with all the associated code today. Full details will be available in our security research repository.

If you want to test the exploit, the code is available here.

Note that the code is for Linux, but the bug is not dependent on any particular operating system - all operating systems are affected!

We reported this vulnerability to AMD on the 15th May 2023.

AMD have released an microcode update for affected processors. Your BIOS or Operating System vendor may already have an update available that includes it.

https://lock.cmpxchg8b.com/zenbleed.html

 

[Dark Kaeser]

ReturnAddress Security Bulletin​

AMD has received an external report titled ‘INCEPTION’, describing a new speculative side channel attack. The attack can result in speculative execution at an attacker-controlled address, potentially leading to information disclosure. This attack is similar to previous branch prediction-based attacks like Spectrev2 and Branch Type Confusion (BTC)/RetBleed.

CVE-2023-20569

A side channel vulnerability in some of the AMD CPUs may allow an attacker to influence the return address prediction. This may result in speculative execution at an attacker-controlled instruction pointer register, potentially leading to information disclosure.

Mitigation​

AMD recommends customers apply either the standalone µcode patch or a BIOS update that incorporates the µcode patch, as applicable, for products based on “Zen 3” and “Zen 4” CPU architectures. AMD plans to release updated AGESA™ versions to Original Equipment Manufacturers (OEM), Original Design Manufacturers (ODM) and motherboard manufacturers (MB) on the target dates listed below. Please refer to your OEM, ODM, or MB for a BIOS update specific to your product, which will follow after the dates listed below, as applicable.

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html