Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
Yeh maybe security wise businesses would be worse off with the data leak, but we are all getting the updates that will effect performance to a degree, how much is currently unknown, but I remember the patch (CPU Microcode updates) for the Meltdown & Specture exploits, just opening a folder and the CPU usage shot up to 50+% usage, it might have only been for 1 second but depending on the usage scenario it will have some effect on performance, I don't care once gaming is not effected.
I'm benching now before the patches and again after them to see how much (if any) performance is effected.
Yet none of the CVEs show this level of remote execution. Remote execution almost always causes the rating to skyrocket to at least a 9. Yet the CVE is a 6.8 and is clearly stated as a local issue
Note this is still bad, but its not "someone can send you a bad ad and steal your passwords" kind of thing. You can read stuff locally which in a virtualized environment is bad. Which is why AMD has prioritized microcode for their server lines. You could also get local privileges, then keep using this exploit to scan for the root password from another process on the server. Again this is bad, but its not something normal users have to be concerned about.
Note Metldown/Spectre had the problem of it coudln't be mitigated in microcode. Meaning it was functionally unpatchable. So they had to do it at the OS level which is highly inefficient. Its why it could only be truly mitigated via new hardware
AMD is sending out microcode updates. Meaning that it can be patched at the CPU level so the impact should be much much less.
Well that sounds more promising :)
I do however remember installing CPU microcode updates (security updates) within Linux for my Intel CPU for Meltdown & Specture, but this was at the software level as you stated, hardware level is more secure and effiecent if that's how they intend to do it.
I mean realistically as a user, you could probably not update the BIOS on your system and be totally fine. Windows won't come out with a patch like Spectre/Meltdown since they will just tell you "update your BIOS firmware to fix this" once it comes out in December.
The article is seemingly misleading in that this cannot be exploited remotely. So you can't be served some kind of malicious ad and then get all your stuff stolen via some kind of browser i-frame running in the background. The attacker already has to be local on your system, at which point you're functionally already screwed.
If you run a server/datacenter this stuff is very concerning (ive had meetings about this but we don't really run any AMD stuff so its not been a big deal)
But for regular users? Honestly you probably don't need to do anything. Unless you're a dissident reporter in a dictatorship country, at which point yes its possible a state actor would want to spend this kind of resources to track you down.
My memory is a bit hazy on this but I think there were certain parts of Meltdown that could be mititated by a microcode update so that was widely sent out. But most of the performance tanking patches were done on the OS level
Lol.
There seems to be very little information or details on how the attack could be carried out, it just states in the article that it's exploitable (data leakable) through Javascript without root privileges:
"The attack does not require physical access to the computer or server and can even be executed via javascript on a webpage."
Then as you said CVEs say local access is required? usually there is a detailed breakdown of such attack, but none so far.
Could it be there is not enough info on this threat yet or is the issue for whatever reason being portrayed as being bigger than it is?
I found the study/exploit here if your interested:
https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed
After analysis it looks like there is potential to exploit locally on a system or in a cloud setup (users connected to a network on a VM can exploit this to monitor activities on the host, or other guests on the same physical core (I mean admins can anyway, just in this case you don't need root access to do it) You can also steal a cookie and passively monitor for passwords, keys, secrets, and so on, I would imagine that this would also be done locally.
However I wouldn't underestimate this attack through the browser using Javascript where it could be possible to exploit the CPU vulnerability to extract data, lets not forget some websites run bit miners unawares to the user through Javascript.
Researched based on:
https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed
This stuff affects the average user.
It's a side-channel attack similar to Meltdown and Spectre.
And just like those; it's due to a problem with branch prediction. Just with AMD's specific flavor of it, rather than Intel's. (So much for AMD's posturing back when Meltdown and Spectre happened, that their chip designs were all safe from this stuff...)
It can be exploited with arbitrary execution rights; requires no local privileges; and can be done even from a web browser, to exfiltrate data at a rate of about 30 kB per second.
That's more than enough to grab chunks of resident data that are copied or moved around and are often processed using strlen, strcmp and other similar functions in both C and other languages that defer to the CPU vectorization instruction sets, and would have data flow through the register that is vulnerable to exfiltration.
You wouldn't initially be able to make much sense of the data, for sure.
But if this stuff involves limited length tokens like passwords kept in memory ...
Most of the initial updates to counter Meltdown boiled down to setting so-called chicken bits (as in 'chickening out') to just disable the exploitable CPU features altogether. This can be driven from the OS-level of things. Beyond that, you can have temporary microcode patches hot-patched onto the CPU from the OS-level; but those will need to be developed by the CPU vendor and need to be signed by them. Actual hard firmware updates are even more involved and happen extremely rarely. Usually the buck stops at boot-time microcode hot-patches.