submitted 2 months ago by Emerald to c/linuxmemes
top 50 comments
sorted by: hot top controversial new old
[-] [email protected] 108 points 2 months ago

Panik: your Debian stable system is so ancient it still contains the heartbleed bug.

[-] meekah 14 points 2 months ago

I thought Debian does do security patches

[-] stuner 16 points 2 months ago

Of course it was patched in all affected Debian versions: https://security-tracker.debian.org/tracker/CVE-2014-0160

[-] bruhduh 3 points 2 months ago* (last edited 2 months ago)

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

load more comments (5 replies)
[-] recapitated 104 points 2 months ago

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.

[-] BURN 20 points 2 months ago

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

[-] [email protected] 28 points 2 months ago* (last edited 2 months ago)


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.


  • 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.

[-] BURN 15 points 2 months ago

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.

[-] [email protected] 3 points 2 months ago

Done properly, an injection like this probably could have been done with no change to default behaviour,

So the sloppiness was in the implementation and not the social engineering.
But then of course, people tend to be not good at both, fooling people and fooling programmers/computers at the same time. In this case, the chap turned out to be better at fooling people than programmers/computers.

And I am being sloppy for not trying to learn enough about exploits even though I should have a good enough programming base to start it.

[-] Theharpyeagle 5 points 2 months ago

It's a rough balance when you're trying to convince people unfamiliar with the internals (let alone non technical people) to make the switch. Saying "Linux is safe, but not bulletproof" may scare them back to the devil they know even if there's no greater guarantee of safety there.

load more comments (1 replies)
load more comments (1 replies)
[-] [email protected] 6 points 2 months ago

I'm just waiting for the backdoor to be found in Firefox and Chromium or some library shared by most applications.

[-] [email protected] 5 points 2 months ago

Like libwebp a few months back? Or Log4j?

load more comments (1 replies)
load more comments (1 replies)
[-] [email protected] 79 points 2 months ago

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.

[-] Dasnap 116 points 2 months ago
[-] UckyBon 24 points 2 months ago

But do it in private, don't let my xz.

[-] [email protected] 35 points 2 months ago

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)
[-] [email protected] 29 points 2 months ago

The linked version in stable was not impacted.

[-] [email protected] 11 points 2 months ago

What do you mean bigger vulnerabilitirs to worry about in Debian stable?

[-] [email protected] 8 points 2 months ago

Mostly a joke about him calling it "ancient", but there may be some unpatched vulnerabilities in older software. Though there could also be some new ones in newest versions.
Still, unless it's Alpha/Beta/RC, it's probably better to keep it up-to-date.

[-] [email protected] 11 points 2 months ago

Debian patches security vulnerabilities in stable. They don’t change the version numbers or anything but they do fix security holes.

[-] [email protected] 10 points 2 months ago

Debian responds to security issues in stable within a fairly short window. They have a dedicated security team.

[-] [email protected] 50 points 2 months ago* (last edited 2 months ago)

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.

[-] sep 52 points 2 months ago

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

[-] [email protected] 25 points 2 months ago

Can't decide which one is more relevant - the $5 wrench hack, or any sort of blackmailing.

XKCD 538 - Security

XKCD 416 - Zealous Autoconfig

[-] [email protected] 8 points 2 months ago

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".

[-] Wooki 48 points 2 months ago* (last edited 2 months ago)

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.

[-] [email protected] 15 points 2 months ago

Yeah, I agree but I know some companies will have stupid thoughts like "a company employee is less likely to do that" or "at least we have an employment contract to back us up legally".

[-] [email protected] 13 points 2 months ago* (last edited 2 months ago)

Until they are attacked...

Not to mention a lot of the time the "attack" is from the company themselves. Just look at the Meta malware as an example

[-] [email protected] 5 points 2 months ago

the Meta malware

What is this?

[-] [email protected] 4 points 2 months ago

The VPN that performed a man in the middle attack to get data from other apps

[-] [email protected] 6 points 2 months ago

Ugh this reminds me of a guy I worked with, he used to be a trucker but became a software tester (he was also very religious).

Anyway he used to hate on open source software and call it open sores. According to him it was all amateur crap. Ugh I still hate that guy and it has been 15 years....

[-] PainInTheAES 17 points 2 months ago

Could be a state actor too

[-] [email protected] 4 points 2 months ago

Certainly, that's why I said organization to be vague.

[-] PainInTheAES 5 points 2 months ago

Sorry I should have been more clear too. I was trying to convey that the dev could have been paid off/threatened or it could be the work of a state actor or team of state actors under an alias. In one case they could care about their reputation but in the other maybe not.

load more comments (1 replies)
[-] shotgun_crab 49 points 2 months ago* (last edited 2 months ago)

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

[-] [email protected] 11 points 2 months ago

The fact that this was planned is what makes me nervous. Imagine what else is lurking.

[-] [email protected] 28 points 2 months ago

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.

[-] [email protected] 4 points 2 months ago

hey Dan, why don't you post blogs now?

[-] [email protected] 5 points 2 months ago

I've been meaning to start blogging again. It's just been a lack of free time. Need to think of ideas, too.

load more comments (2 replies)
[-] [email protected] 37 points 2 months ago

That's basically the idea of having a stable branch. Where all packages have 2+ years of testing and revisions.

load more comments (1 replies)
[-] [email protected] 31 points 2 months ago* (last edited 2 months ago)

The slowness is on purpose.

(OP may know, but I don't know if everyone does.)

Edit: /u/[email protected] is picking up what I was putting down.

load more comments (5 replies)
[-] [email protected] 22 points 2 months ago

Maybe Manjaro should delay update even longer to make it extra secure /s

[-] [email protected] 8 points 2 months ago

Ngl manjaro beeing slow as saved my ass more than once

load more comments (3 replies)
load more comments (6 replies)
[-] [email protected] 18 points 2 months ago

How about you just use any stable system. For instance, stable Fedora wasn't affected

load more comments
view more: next ›
this post was submitted on 30 Mar 2024
980 points (98.6% liked)


19389 readers
360 users here now

I use Arch btw

Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago