The new AMD vulnerability discovered by @taviso and his team makes all AMD zen2 processors vulnerable. Also known has Zenbleed.
I compiled the demo code and there we go, I can see lot of information getting leaked from the memory. Not great, it’s the AMD variant of the meltdown/spectre bug basically. It uses however an “optimization” operator (cvtsi2sd) to trigger the vulnerability in the CPU allowing to read 30kb/core/second of data. No special permissions required. Works on all platforms, all operating systems, VM or docker, it doesn’t matter…
This vulnerability was found using fuzzing, which is an automated way of injecting wrong input values and see when or if something breaks or not.
Currently only EPYC processors have received a fix. All other AMD Zen 2 processors are still fully vulnerable. There are also no BIOS firmware updates yet. I doubt wherever this premature public release from AMD was intentional or not…
More info: https://lock.cmpxchg8b.com/zenbleed.html
Ps. For some reason the severity is marked as “medium”, while I can read all my data without any special user privilege on my system: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html. This should be a very high severity for sure.
High severity is for remote execution or remote information gathering.
Currently to exploit this you need someone to run your software right on their machine, and if they’re doing that chances are you may trick them into simply running whatever you want as admin. The technique also is very findable by antivirus solutions, with no real avenue to obfuscate it.
Medium fits well for an exploit that needs to run locally and may or may not expose secrets. Even if you run it in a VM, you still need access to other VMs or the hypervisor through other means in order to do something with stolen secrets.
But what about hosting GitLab/GitHub/Codeberg runners? Even when using Docker. That might still allow hackers to run software on the machine, and since this vulnerability doesn’t require any specific permissions anybody can take advantage of this vulnerability.
How many of those run on zen2 CPUs? All of github’s are in azure which uses Intel, gitlab AFAIK runs on AWS, and I don’t know what codeberg uses bug I’m willing to be they don’t self-host either. If they do, and they use zen2, they’re probably using EPYC. Honestly this is a nasty bug but it isn’t as bad as you’re making it out to be.
I’m running 6 gitlab runners and 3 Forgejo runners. Self hosted. Yes it matters.
Does it? Who are you hosting gitlab runners for on consumer hardware?
If this affects you in more than a “well, better be careful about what I download” way, either you’re significantly outside of the intended use case for your hardware or you are blowing this way out of proportion.
Hmm
So you are basically saying, you should not use consumer hardware to create a server yourself. Instead you need to spent 1000’s of dollars for a EYPC processor and very expensive motherboard and memory. Just because…
The internet is already broken enough. I believe in decentralizing the WWW by enabling users to create their own server. Moving all to Amazon cloud isn’t the future I want to see either. Forcing users to spent 1000 or 10.000 of dollars for a server is definitely not helping either.
What I’m saying is that if you are enabling unvetted users to run things on your hardware, for free, you probably shouldn’t be doing it on consumer hardware in the first place.
If the users are paying, doubly so.
If the users are vetted but free, then this is a “your friends are hacking you” problem.
There is nothing wrong with using consumer hardware to host servers. I’m doing it right this moment with great success. What I’m saying is that if you have public gitlab runners, then you’re just hosting a Monero mining rig for randoms in the first place.
This has nothing to do with heartbleed. It’s a branch prediction error exploit, which is similar in spirit to meltdown/spectre which is what you’re thinking about. Why the authors would name it zenbleed is beyond me.
This won’t be fixed by a BIOS firmware upgrade. This will be fixed by a microcode update that will probably install automatically on all major platforms.
Ah you’re right I was thinking about the meltdown/spectre of Intel. Why they called it Zenbleed I’m not sure either. BIOS firmware upgrades can also fix CPU vulnerabilities.
