Intel/AMD Downfall/Inception Vulnerabilities

CyberCr33p

CyberCr33p

There are security vulnerabilities in Intel and AMD processors.

More information can be found at https://www.openssl.org/blog/blog/2023/08/15/downfall/

It appears that changes are required both in the operating system code and microcode/bios updates.

If I remember correctly, when Spectre and Meltdown vulnerabilities were disclosed in early 2018, there was significant controversy surrounding the notification process. Several entities, including certain Linux distributions and the FreeBSD project, were not informed as early as some major tech companies.

I am aware that work is currently being done for upcoming FreeBSD 14 release and there may not be available human resources, but is there anyone working on this?
 
If an attacker can obtain local (but unprivileged) execution on a machine with an affected CPU, and they are able to schedule that process on the same physical core as another process, and they are able to execute AVX instructions, you should assume they are able to obtain read access to any information stored within that process’s memory.

It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk.
Click to expand...
 
It was already established in another thread about Downfall, that the FreeBSD base system and even most ports don't have AVX-options enabled for better compatibility, and make either no or only very minimal use of the vector instructions.
The same was also stated by Theo de Raadt about OpenBSD.
So for both OS it has proven again, that a more conservative approach leads to better security.

Linux and especially Windows make heavy use of vector instructions, especially for security critical operations like cryptography, so on those OS this is a valid attack vector (although with *very* specific prerequisites and hence not very suitable for a targeted attack)


For clarification: this doesn't mean it should be completely neglected/ignored by FreeBSD, but it isn't as catastrophic as some media outlets try to market those vulnerabilities.
 
I'm working on both of those vulnerabilities for FreeBSD. My hardening repo includes both a Zenbleed workaround that updates to the latest AMD microcode, sets the chicken-bit if needed, and links to a Downfall checker able to be used on FreeBSD to verify you have the vulnerability.

I'm researching and tracking the Downfall vulnerability and as soon as I'm able, I'll release the fix/patch/workaround if I can find one and Intel microcode update function as soon as I can. It's like the summer of CPU vulnerabilities!

github.com

GitHub - wravoc/harden-freebsd: Updated for 14.0. A half days worth of work can be done in seconds, with comprehensive logging, togglable secure/performance settings, and backups. Implements a broad, time-tested, thoroughly researched, cohesive grou

Updated for 14.0. A half days worth of work can be done in seconds, with comprehensive logging, togglable secure/performance settings, and backups. Implements a broad, time-tested, thoroughly rese...
github.com github.com
 
sko said:
It was already established in another thread about Downfall, that the FreeBSD base system and even most ports don't have AVX-options enabled for better compatibility, and make either no or only very minimal use of the vector instructions.
The same was also stated by Theo de Raadt about OpenBSD.
So for both OS it has proven again, that a more conservative approach leads to better security.

Linux and especially Windows make heavy use of vector instructions, especially for security critical operations like cryptography, so on those OS this is a valid attack vector (although with *very* specific prerequisites and hence not very suitable for a targeted attack)


For clarification: this doesn't mean it should be completely neglected/ignored by FreeBSD, but it isn't as catastrophic as some media outlets try to market those vulnerabilities.
Click to expand...
My understanding is that it doesn't matter whether the base uses AVX or not - it's whether the attacker can.

If someone can locally compile, or side-download a binary containing AVX2 / AVX512 commands, then the danger exists, and the only way to fix it is either with the microcode update, or for the OS to actively block AVX2 / AVX512 commands within binaries from being executed.

Also, you mean "packages", not "ports" - you are talking about the distributed binaries of the base system, and packages (binaries)

Ports are compiled from source locally, and may use whatever the compiler thinks is available - ditto if you compile the base source locally:
Code: 
03:55 (37.0°C 400) (177) "/tmp" jamie@thompson% elfx86exts /bin/ls /usr/local/bin/openssl

/͟b͟i͟n͟/͟l͟s͟
MODE64 (push)
CMOV (cmovs)
SSE2 (pause)
AVX2 (vpbroadcastq)
AVX (vmovdqa)
NOVLX (vpaddq)
CPU Generation: Unknown

/͟u͟s͟r͟/͟l͟o͟c͟a͟l͟/͟b͟i͟n͟/͟o͟p͟e͟n͟s͟s͟l͟
MODE64 (push)
CMOV (cmovs)
SSE2 (pause)
AVX (vxorps)
NOVLX (vxorps)
AVX2 (vpbroadcastq)
BMI2 (shlx)
BMI (andn)
CPU Generation: Unknown
 
Thanks for the clarification; I had the assumption only information that also was computed through AVX instructions would be at risk of being disclosed.


jamie said:
Also, you mean "packages", not "ports" - you are talking about the distributed binaries of the base system, and packages (binaries)
Click to expand...
I was referring to the default configuration of the ports, but yes, packages might be the better reference here.
 
For reference, this is the relevant part. See the full link, as it contains further details which are much clearer than other reports I've seen. Incidentally, this affects "AVX2" and "AVX512" not "AVX" (and I've seen no mention of AVX10)

  • It should be emphasised that a victim process does not need to execute AVX instructions to be affected. Exploitation can only be mitigated by preventing an attacker process from executing AVX instructions.
Click to expand...

OpenSSL statement on the recent Intel/AMD Downfall/Inception vulnerabilities

Last week marked the public announcement of the Downfall vulnerability in Intel CPUs and the Inception vulnerability in AMD CPUs. Both of these are microarchitectural side-channel attacks allowing an attacker with unprivileged execution on the same physical core as a victim process to extract...
www.openssl.org www.openssl.org

It only affects the "GATHER" instruction, so the microcode update hobbles this command in a way that makes it secure, but less efficient. However, still using AVX2/512 after the update can still give other advantages.

More information: https://downfall.page/

I was referring to the default configuration of the ports, but yes, packages might be the better reference here.
Click to expand...

I'm not trying to be pedantic, but the distinction could be important (well, in this case, as it's the attacker that uses AVX2/512 rather than the victim, it's moot anyway, but you get my point).

Also, not wanting to be pedantic, but "default configuration of ports" is debatable too - Simply having this in /etc/make.conf will cause AVX2/512 commands to be used were appropriate, with no changes to port defaults being made - this would affect ports AND base compiles, and is the only reason my post above shows AVX2 being used on my system:

CPUTYPE=native
 
You must log in or register to reply here.
Back
Top