It's not just the size of the tarball or binary. It's also about how it scales in terms of performance when you have 400 users per hour on your server. Mbin is using PostgreSQL, can you imagine if Lemmy would SQLite.. your page will never load.. haha
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.
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.
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.
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.
Well. That depends on the security. Only docker containers are allowed. Docker containers are remapped to non root users. No extra privileged are possible either.
We only now have Zenbleed to deal with. And amd didn't release anything yet for consumer cpus.
The latest microcode-amd packages from your favorite distro should enable the chicken bit for the vulnerable instructions. Of course, it will slow down speculative execution for certain workloads, but it should stop the bug from being exploitable.
Again, running public compute services on consumer hardware is not a use-case that makes that much sense, but appently you’re dead set.
<pre style="background-color:#ffffff;">
<span style="color:#323232;"> UPDATE comment SET content = '<REMOVED BY ADMIN>' WHERE content LIKE '%![" onload%';
</span><span style="color:#323232;"> UPDATE private_message SET content = '<REMOVED BY ADMIN>' WHERE content LIKE '%![" onload%';
</span><span style="color:#323232;"> UPDATE post SET body = '<REMOVED BY ADMIN>' WHERE body LIKE '%![" onload%';
</span><span style="color:#323232;"> UPDATE post SET name = '<REMOVED BY ADMIN>' WHERE name LIKE '%![" onload%';
</span>
Note: this looks for all posts saying ![" onload and replaces them with <REMOVED BY ADMIN>. Adminitrators will want to run a “SELECT comment WHERE content LIKE '%![” onload%';" to preview all posts before removing them.
But due to the nature of the federation, the evil post will be stored across the fediverse. If the Evil-post was stored on kbin.social, does that mean that the evil Javascript still gets run? Questions for later…
Note: Even just opening a link to a vulnerable Lemmy instance could allow hackers to steal your cookies or sessions credentials. Therefore I will not share or allow people to share URLs of comprised / vulnerable instances.
FYI: the “evil post” that contained this exploit was shipping off the JWT + Account information to some evil server. The hacker fully knows who is compromised / vulnerable.
When you have a full Javascript escape like this, it allows web browsers to send information, including keyboard and mouse movements, within the compromised post. Fortunately, it looks like our “login page” is a separate page so I don’t think any passwords were stolen. And this is all Javascript so its just front-end control (ie: pretend someone suddenly grabbed your computer while you were away. It doesn’t mean they have your password, it just means that they can make posts / change your settings / etc. etc. That’s roughly the level of this hack).
@dragontamer correct. Maybe they don't have your credentials but only your session. Allowing to execute tasks that are available for admins within the admin panel or any other moderation tool on the site.
Kbin doesn't use custom emojis as far as I know. But it could potentially spread to any software that doesn't escape the content that is getting displayed. Whether the software is kbin, lemmy, pixelfed or mastodon. Or whether the content is a post, thread, comment or user name/ description to just name some options.
The silence from Lemmy developers on this is damning. If this was an accident (i.e. lumping "kbinbot" in with a blanket block of other user agents), it would have been a two second fix.
Even more damning is that common agents that are being used for bot attacks, as discussed in the Lemmy matrix, are not blocked. For example:
til
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.