If you removed most of the complexity from modern hardware and software, you would lose a bit of performance but gain massive amounts of reliability. The human mind can only guarantee the reliability of a design up to a certain point in it's complexity, after that it's becomes a lottery.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Intel ‘Downfall’: Severe flaw in billions of CPUs leaks passwords and much more
- Thread starter CAD4466HK
- Start date
DukenukemX
Supreme [H]ardness
- Joined
- Jan 30, 2005
- Messages
- 7,953
From what I gather he's SSH'ing into a machine or VM and running a local script. Doesn't look like he needs root, but he does need access to the machine.
CAD4466HK
2[H]4U
- Joined
- Jul 24, 2008
- Messages
- 2,784
I'll take your word for it since it looked like ancient Sumerian to me.
DukenukemX
Supreme [H]ardness
- Joined
- Jan 30, 2005
- Messages
- 7,953
When he runs ssh [email protected] then he's logging into another machine running ssh server to run terminal commands. I guess he's trying to simulate a remote attack. When he runs things like ./name_of_script.sh then he's running a script. If you see a # sign at the command prompt then that means root but he had a $ sign which means no root. You can still get the $ if you use sudo which gives temporary root, but I didn't see him enter sudo. Kinda scary he doesn't need root, but he also needed access to the machine. If you downloaded something that wasn't trusted and runs a similar script then yes you are SOL.I'll take your word for it since it looked like ancient Sumerian to me.
You don't need a command prompt, that just makes it easier, but you could be hacked simply by visiting a website which runs a piece of javascript that makes use of these exploits. This has nothing to do with having root or administrator privileges, if someone has them, then they already have full control of your computer. That's the whole point of these exploits, to escalate privileges. To access files and memory of processes and users which should not be accessible.
He's running SSH on the same remote machine, as the IP address doesn't change (100.67.22.1) - He's simply logging in using different accounts. All the demonstration appears to be showing is the user probing for cached openssl keys used by another account on the same machine via a script to decrypt files, it's not showing any evidence of privilege escalation. The user logs into both accounts as part of the video to demonstrate the attacker's account as well as the victim's account in order to highlight the exposed keys. It's obvious such an attack is fairly dependent on actual physical access to the machine being attacked to begin with, as well as a valid account the attacker can SSH into in order to carry out the attack locally on the remote machine - Making such an attack fairly awkward.
Realistically speaking, it appears to be more of an attack aimed at cloud based servers running multiple accounts where the attacker has access to at least one local account on the machine being attacked, as opposed to desktop computers running only one account and home directory.
It's very hard to follow considering the user appears to struggle so much with copy/paste while in terminal, and is demonstrating using tabs as opposed to separate terminal sessions. The fact there's no voice over describing the process doesn't help.
Last edited:
Absalom
[H]ard|Gawd
- Joined
- Oct 3, 2007
- Messages
- 1,269
You are both overthinking it. What was stated is enough.
That's it. No sudo, no escalation required. No need to overcomplicate things. The invisible fence that hardware normally provides doesn't exist. Normal operating system rules do not apply here.
The nature and volatility of hardware cache probably makes this exploit a bit harder to pull off in a real world scenario, so in a controlled environment or lab this might seem like a magic trick that can be conjured at will. So realistically (i.e. in the real world), I would state that what the example demonstrates does not explain statistical probability nor the whole picture. For example, a server under load might not keep a key around long enough to stick around in cache to be mined. But a server mostly idling? A much easier target.
So the video only serves to demonstrates what is probable. It does not defend its practicality.
That's it. No sudo, no escalation required. No need to overcomplicate things. The invisible fence that hardware normally provides doesn't exist. Normal operating system rules do not apply here.
The nature and volatility of hardware cache probably makes this exploit a bit harder to pull off in a real world scenario, so in a controlled environment or lab this might seem like a magic trick that can be conjured at will. So realistically (i.e. in the real world), I would state that what the example demonstrates does not explain statistical probability nor the whole picture. For example, a server under load might not keep a key around long enough to stick around in cache to be mined. But a server mostly idling? A much easier target.
So the video only serves to demonstrates what is probable. It does not defend its practicality.
Yes that is completely the point you don't need root access you don't need to even know basic credentials of the accounts also running on the CPU.
This exploit can be run on cloud services that often have 100s of accounts spun up on the same CPU cluster. (like if you buy access to a 4 core cloud server... those 4 cores could actually be 4 cores on a larger 64 core CPU, or you could be buying 16 cores that is one chip in a 4 chip rack that shares load) You could potentially with these attacks just rent your own space... scrape the CPU over a week and see what you get. You might get lucky and get some major companies credentials and use that to do other things... you could get nothing. If you wanted to attack a company that has remote VM running offices. You could use the good old hey this is tech support from head office type call to a fairly low access account holder... need you to log in and check a couple things for me. OH ok all looks good thanks. Then sift their data for a few weeks and hopefully pull some higher end credentials. You don't need to trick a sysadmin or a stupid CEO... any low level employee with a locked down can't do anything account would do fine.
IMO the scary nature of these is they would be almost impossible to detect and defend against if you where not mitigated. For companies using cloud services... heck they are sort of relying on another company to ensure they are mitigated.
This exploit can be run on cloud services that often have 100s of accounts spun up on the same CPU cluster. (like if you buy access to a 4 core cloud server... those 4 cores could actually be 4 cores on a larger 64 core CPU, or you could be buying 16 cores that is one chip in a 4 chip rack that shares load) You could potentially with these attacks just rent your own space... scrape the CPU over a week and see what you get. You might get lucky and get some major companies credentials and use that to do other things... you could get nothing. If you wanted to attack a company that has remote VM running offices. You could use the good old hey this is tech support from head office type call to a fairly low access account holder... need you to log in and check a couple things for me. OH ok all looks good thanks. Then sift their data for a few weeks and hopefully pull some higher end credentials. You don't need to trick a sysadmin or a stupid CEO... any low level employee with a locked down can't do anything account would do fine.
IMO the scary nature of these is they would be almost impossible to detect and defend against if you where not mitigated. For companies using cloud services... heck they are sort of relying on another company to ensure they are mitigated.
I mean, this is one reason why you pay fat stacks to the major hyperscalers - it's already patched there.
I'm not overthinking anything, I'm explaining the process used. The attack demonstrated is in many cases a fairly useless one, I don't think it was actually used in any large scale out in the wild.
At the end of the day, if you need to phish in order to gain access to a local account to run your script, you may as well just phish for an account that has better privileges to begin with. As stated, it's also unlikely to be an issue regarding home users with only one account on their PC.
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,455
I remember this about ARM CPUs that used speculative execution were vulnerable until it was fixed in firmware/microcode and/or hardware.
The only ARM CPUs that were immune were the much older Cortex-A53 era CPUs that did not use speculative execution.
It wasn't just x86-64 and ARM ISAs, anything that used speculative execution was suddenly vulnerable, so it wasn't exclusive to any specific ISA.
You are correct, though, it wasn't like one ISA was better than the other when it comes to these exploits - unless they are brand-specific like all of these Intel-specific exploits...
It's interesting, my Pi doesn't list any mitigations as being patched, yet my x64 system lists many patched mitigations:
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,455
The Raspberry Pi community has not been happy about the complacency of the RP4 being vulnerable, and the devs being meh about it.
Basically these vulnerabilities have existed for a long long time and are now white hat knowledge.
Nobody really cares except anyone doing workloads or storing data on cloud services. On cloud services you are *actively* sharing your hardware with malicious local access. On fucking purpose. Otherwise people wouldn't be nuking 50% of their performance over esoteric attack vectors.
If your shit is in the cloud its already been pwned just not by low stakes ransomware fuckos.
For most of use though nation states really aren't in our threat list. We just accept that they all can see everything we do and carry on with life and hope that we never come to their attention.
If you have IP you wanna keep away from say, China, and you have any of it on any public cloud, you're a fuckwit. soz.
The NSA's job *should* be to guarantee no American infrastructure has backdoors. Instead they guarantee everything is swiss cheese.
Still If I had a shedload of intel chips that just all got their balls cut off I'd be fuckin pissed. I suddenly need twice as many machines, twice the datacenter space, twice the power, twice the cooling.... business model might well be fucked by that. What an amazing lil patch.
Nobody really cares except anyone doing workloads or storing data on cloud services. On cloud services you are *actively* sharing your hardware with malicious local access. On fucking purpose. Otherwise people wouldn't be nuking 50% of their performance over esoteric attack vectors.
If your shit is in the cloud its already been pwned just not by low stakes ransomware fuckos.
For most of use though nation states really aren't in our threat list. We just accept that they all can see everything we do and carry on with life and hope that we never come to their attention.
If you have IP you wanna keep away from say, China, and you have any of it on any public cloud, you're a fuckwit. soz.
The NSA's job *should* be to guarantee no American infrastructure has backdoors. Instead they guarantee everything is swiss cheese.
Still If I had a shedload of intel chips that just all got their balls cut off I'd be fuckin pissed. I suddenly need twice as many machines, twice the datacenter space, twice the power, twice the cooling.... business model might well be fucked by that. What an amazing lil patch.
- Joined
- Jun 27, 2001
- Messages
- 15,814
heh, that sucks, we are still running tons of ivy bridge xeons
guess I have another reason to suggest AMD for the next round of servers
This is the first I've heard about it. Considering most Pi's only run one user account, it's unlikely to be an issue.
only advice I would give is check with your black box vm appliance vendors to see if they are supported and can test if not if you run any of those.
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,455
Still no excuse on them not offering an optional patch for it at least.
The vulnerability is a half-decade old at this point, and older than the Pi 4 itself.
The problem is: Any performance loss regarding the RPi will be immediately noticeable, in some use cases it may actually render the device useless. It's not like they have oodles of performance to spare.
The microcode update dropped for Linux LTS releases today. Spectre v1 I can handle, Spectre v2 I can handle, then we have Meltdown, and now Downfall - From a performance perspective this is becoming ridiculous.
Added "mitigations=off" to /etc/default/grub, everything running amazing now.
Added "mitigations=off" to /etc/default/grub, everything running amazing now.
Absalom
[H]ard|Gawd
- Joined
- Oct 3, 2007
- Messages
- 1,269
Downfall mitigations only affect workloads that use AVX instructions, specifically the Gather instruction. I think Intel hinted up to 50% overhead on certain workloads when mitigation is in effect. It remains to be seen how much performance loss there is given AVX tends to imply very specific workloads (i.e. lots of vector operations). I imagine for most real world scenarios, these are not exactly broad strokes.
It gets even more fun for processors where microcode isn't readily available:
Maybe a reason to upgrade to 12th gen or newer?
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,455
I stand corrected.Maybe a reason to upgrade to 12th gen or newer?
Poor Skylake has been hit the hardest of all of these exploits, it really has been the weakest architecture and the buggiest.
Last edited:
Absalom
[H]ard|Gawd
- Joined
- Oct 3, 2007
- Messages
- 1,269
Up to but not including 12th gen. Basically Skylake through Tiger Lake.
Straight from the website:
12th gen is not affected by Downfall currently.
Edit: What's also interesting is Haswell isn't affected nor Broadwell. Haswell would have been the first to support the Gather instruction via AVX2.
Last edited:
AVX is almost used on everything now. I think 'certain workloads' translates to 'most workloads of varying impact'.
Not a chance when this 8700k's still more than capable.Maybe a reason to upgrade to 12th gen or newer?
Benchmarking The Performance Impact to AMD Inception Mitigations
https://www.phoronix.com/review/amd-inception-benchmarks
https://www.phoronix.com/review/amd-inception-benchmarks