Panik: your Debian stable system is so ancient it still contains the heartbleed bug.
this post was submitted on 30 Mar 2024
107 points (97.3% liked)
linuxmemes
21210 readers
90 users here now
Hint: :q!
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
I thought Debian does do security patches
Of course it was patched in all affected Debian versions: https://security-tracker.debian.org/tracker/CVE-2014-0160
Is linux 6.1 vulnerable to heartbleed? I'm on lmde6 with linux 6.1 btw) edit: as other comment said debian 12 is good so everything alright
The xz infiltration is a proof of concept.
Anyone who is comforted by the fact they're not affected by a particular release is misguided. We just don't yet know the ways in which we are thoroughly screwed.
This is a huge wake up call to OSS maintainers that they need to review code a lot more thoroughly. This is far from the last time we’re going to see this, and it probably wouldn’t have been caught if the attacker hadn’t been sloppy
https://upvote.au/comment/818245
Nah, I'd say the chap was pretty unsloppy.
Just that we were lucky that someone found it.
It's a good thing that xz is a type of program that people may want to profile.
But this is an eye opener for people saying that Linux is "secure" (not more secure, but just secure .) because the code has many eyes on it. --> jump to digression.
This confirms my suspicion that we may be affected by the bystander effect, so we actually have less eyes than required for this.
digression:
- of course I don't mean that this makes Linux less secure than Windows. The point that it makes it more secure than Windows/MacOS or other closed source systems is already apparent.
- Just that, we can't consider Linux to be secure (without comparing it to something less secure) as many ppl would, when evangelising Linux.
My point being, tell the whole truth. The newbie that's taking your advice will thank you for that later on.
The reason I consider this sloppy is because he altered default behavior. Done properly, an injection like this probably could have been done with no change to default behavior, and we’d be even less likely to have gotten lucky.
Looking back we can see all the signs pointing to it, but it still took a lot of getting lucky to find it.
I’ve always considered the “source is open so people can check for vulnerabilities” saying a bit ironic, because I’d bet 99% of us never look, nor could find it if we were looking. The bystander effect is definitely here as we all just assume someone else has audited it.
And to have strong and continuous analysis of software bills of materials.
I'm just waiting for the backdoor to be found in Firefox and Chromium or some library shared by most applications.
The thing about browsers is that there are so many accidental exploits already, it makes little sense to introduce your own on top of it.
load more comments
(1 replies)
Still paniking, cause the backdoor was apparently targetting Debian servers, it was discovered just by chance and the "mantainer" made commits for 2 years in the same repo
The fact that this was planned is what makes me nervous. Imagine what else is lurking.
and it was only discovered accidentally, when someone was profiling some stuff, noticed SSH using a bit too much CPU power when receiving connections even for invalid usernames/passwords, and spent the time to investigate it more deeply. A lot of developers aren't that attentive, and it could have easily snuck through.
hey Dan, why don't you post blogs now?
I've been meaning to start blogging again. It's just been a lack of free time. Need to think of ideas, too.
The malicious changes were submitted by JiaT75, one of the two main xz Utils developers with years of contributions to the project.
“Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system,” Freund wrote. “Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the ‘fixes’” provided in recent updates. Those updates and fixes can be found here, here, here, and here. https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
That really sucks. This kind of thing can make people and companies lose trust in open source. I wonder if we will learn the reason behind that. I would guess the developer was paid a lot of money by some organization to risk ruining his reputation like that.
No, its the exact opposite.
Supply chain conpromise is a level of risk to manage not unique to FOSS. Ever heard of sunburst? It resulted in a lot of Microsofts cloud customers getting wreaked all because their supply chain was compromised.
Do people continue to buy into 365 and Azure? Yes. Without care.
So will this hurt open source projects? Not at all, in fact it will benefit them, highlight just why source code SHOULD be open source and visible to all! We would have had very little to no visibility and capability to monitor closed source. Let alone learn, improve and harden how projects can protect against this increasingly more common attack.
load more comments
(4 replies)
Like the exact same thing can not happen in a closed source codebase. It probably does daily. Since closed codebases the due dilligence and reviews cost money, and nobody can see the state. They are intentionally neglected.
Open source nor closed source is immune to the 5$ wrench hack
Exactly, if you are as big a Microsoft, you can't tell 100% if one of your developer's is actually being paid by a foreign government. Even if you say completely check the commits other devs make, there will still be deadlines when a code review is just "looks fine, next".
Can't decide which one is more relevant - the $5 wrench hack, or any sort of blackmailing.
Your Debian stable system is so ancient you got bigger vulnerabilities to worry about: Panik!
Also the problem was that Debian's sshd linked to liblzma for some systemd feature to work. This mod was done by Debian team.
Liblzma balls
But do it in private, don't let my xz.
Even if you're using debian 12 bookworm and are fully up to date, you're still running [5.4.1].
The only debian version actually shipping the vulnerable version of the package was sid, and being a canary for this kind of thing is what sid is for, which it's users know perfectly well.
load more comments
(4 replies)
load more comments
(4 replies)
The slowness is on purpose.
(OP may know, but I don't know if everyone does.)
Edit: /u/getaway@lemmynsfw.com is picking up what I was putting down.
The slowness is on purpose? To help identify the sshd in question to the attacker which nodes are compromised? What reason(s) could there be?
He's talking about Debian's slowness in getting new versions to stable, and how the meme ignores security backports.
If the above decides to continue, the code appears to be parsing the symbol tables in memory. This is the quite slow step that made me look into the issue.
That is from the original find. Not sure the relevance of it and this being proof for it being "on purpose". But that is the origin of the slowness.
How about you just use any stable system. For instance, stable Fedora wasn't affected
Maybe Manjaro should delay update even longer to make it extra secure /s
In this case the slower updates payed off. There are many things wrong with Manjaro but slower updates is not one of them.
It's not though, because the malicious release happened more than two weeks ago and manjaro had to fast track the patched xs from arch git repo. This is why manjaro should extend their delayed update policy to catch this kind of issue in the future (maybe 2 months instead of 2 weeks) /s
They honestly should as it probably would fix a lot of issues. Then again, Manjaro is so broken that it probably doesn't matter
load more comments
(3 replies)
That's basically the idea of having a stable branch. Where all packages have 2+ years of testing and revisions.
They are stagnant. They keep getting security/fix patches, just not new features.
view more: next ›