- cross-posted to:
- security@lemmy.ml
- cross-posted to:
- security@lemmy.ml
You must log in or register to comment.
Speculative execution seems to be the source of a lot of security flaws in many different CPUs. CPU manufacturers seem to be so focused on winning the performance race that security aware architecture design takes the backseat.
Also, it’s more and more clear that it’s a bad idea that websites can just execute arbitrary code. The JS APIs are way too powerful and complex nowadays. Maybe websites and apps should’ve stayed separate concepts instead of merging into “web apps”.
I also wonder if it’d be possible to design a CPU so vulnerabilities like these are fixable instead of just “mitigable”. Similar to how you can reprogram an FPGA. I have no clue how chip design works though, but please feel free to reply if you know more about this.
Also, it’s more and more clear that it’s a bad idea that websites can just execute arbitrary code. The JS APIs are way too powerful and complex nowadays.
Javascript in general was a mistake, and always has been.
The web should’ve had Scheme or Python instead. Or better yet, we shouldn’t have given up so quickly on Java Web Start because then we could’ve had proper web applications with their own windows and native UIs and such.
Maybe websites and apps should’ve stayed separate concepts instead of merging into “web apps”.
Damn straight!
Being a Linux user I really like everything being ran in the browser. What if we just have more control of which JS APIs can be used? On a site by site bases. Which I assume can probably already be done with extensions.
Some browsers such as cromite disable JIT compilation and WebAssembly by default. Allowing you to opt-in to enable these features on a site by site bases.
JIT and WebAssembly have been the source of many high profile CVE in browser recently including the one mentioned in the post (well, this one is on Safari’s Chrome).
relevant research
Take a look at ARM Morello and CHERI.
I need a bigger nerd than me to explain how much Apple users need to worry about this.
This is a real problem, and Apple can’t patch it out of the hardware. The only thing they can do is write software to run in advance of hardware execution to “randomize” when and where memory is written to and read from. That will slightly decrease the performance of these chips. The “older” chips from 2021 would see the worst performance reduction. M3 users probably won’t even be able to tell.
The attack vector is a web browser. Even a completely updated safari is vulnerable, but Chrome is seemingly easier to exploit (the way browsers store website data in memory is the key). An encrypted browser won’t change anything because the attack is reading the unencrypted data being displayed to the user.
It takes several minutes for a compromised website to perform the attack. So basic sense practices apply. If you think a website is unsafe, don’t open it. If you think something is happening, closing the suspicious sites immediately might stop the attack before any damage is done. I don’t know how easy it would be to compromise a trusted site, but it’s been done in the past.
Apple could potentially patch Safari to do things that make it harder for the attack to work correctly, and you can bet they’re already retooling the next generation of processors to get rid of this exploit. They did the same thing when an unpatchable exploit was found in the M1 series, M2s have a stopgap measure, and M3s were redrawn to make it an nonissue.
If you think a website is unsafe, don’t open it.
Ahh yes, back to the dark ages of the internet where just clicking the wrong link can completely compromise your system.
Thanks crapple and its useful idiots.
I mean, Intel did it first and I do believe AMD and Qualcomm also followed suit.
Yes, and Apple decided to do the same thing knowing the risks.
“Intel did it!” is not a panacea for apple; it makes things worse for them.
You can’t compete without doing it. Do you think Intel and AMD stopped doing it? Hell nah, people will find new exploits in a few years, I’m certain.
If you don’t do speculative execution, you’ll be left in the dust unfortunately.
If anything, this shows that there should be separate lines of CPUs for handling classified data and such, that don’t do it. But it would likely be prohibitively expensive to implement a separate product line.
You do realize this kind of attack first appeared on x86 hardware, right?
https://thehackernews.com/2024/10/new-research-reveals-spectre.html?m=1
Yes, I realize that.
You do realize that this kind of attack happened after spectre and meltdown? Apple knew of the risks, but decided to ignore them.
Well yes, but newer CPU models such as 13th and 14th gen Intel CPUs are also susceptible to these attacks, my points is that Apple is no exception to this vulnerability and should not be singled out for it
The main issue with these vulnerabilities is a loss in performance when the microcode patch gets applied.
On a more philosophical note, it’s also a trend to release insecure products to tout performance metrics. Intel did it. Now it’s apple’s turn.
Don’t trust corporations, ever.
FLOP abuses the LVP in a way that allows the attacker to run functions with the wrong argument—for instance, a memory pointer rather than an integer.
is this a vulnerability in the software? So patching this won’t require disabling speculative execution?
Hardware. There’s a load value predictor that guesses the value of a load from memory
But-but I was told Apple’s security was the very best! That’s why they charge so much for everything they make, right? … Right?
We can laugh all we want but this issue was present on x86 hardware first
https://thehackernews.com/2024/10/new-research-reveals-spectre.html?m=1
