this post was submitted on 30 Mar 2024
1604 points (100.0% liked)

linuxmemes

25111 readers
1233 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
  • Don't get baited into back-and-forth insults. We are not animals.
  • 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.
  • 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 sudo in Windows.
  • No porn, no politics, no trolling or ragebaiting.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
  • 5. πŸ‡¬πŸ‡§ Language/язык/Sprache
  • This is primarily an English-speaking community. πŸ‡¬πŸ‡§πŸ‡¦πŸ‡ΊπŸ‡ΊπŸ‡Έ
  • Comments written in other languages are allowed.
  • The substance of a post should be comprehensible for people who only speak English.
  • Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
  • 6. (NEW!) Regarding public figuresWe all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations.
  • Keep discussions polite and free of disparagement.
  • We are never in possession of all of the facts. Defamatory comments will not be tolerated.
  • Discussions that get too heated will be locked and offending comments removed.
  • Β 

    Please report posts and comments that break these rules!


    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.

    founded 2 years ago
    MODERATORS
    top 50 comments
    sorted by: hot top controversial new old
    [–] [email protected] 197 points 1 year ago (2 children)

    To be fair, we only know of this one. There may well be other open source backdoors floating around with no detection. Was heartbleed really an accident?

    [–] [email protected] 100 points 1 year ago (1 children)

    True. And the "given enough eyeballs, all bugs are shallow" is a neat sounding thing from the past when the amount of code lines was not as much as now. Sometimes it is scary to see how long a vulnerability in the Linux kernel had been there for years, "waiting" to be exploited.

    [–] [email protected] 72 points 1 year ago (2 children)

    Still far better than a proprietary kernel made by a tech corp, carried hardly changed from release to release, even fewer people maintain, and if they do they might well be adding a backdoor themselves for their government agency friends.

    [–] [email protected] 17 points 1 year ago

    true, opensource can be flawed, but it's certain less flawed than a closed source alternatives

    load more comments (1 replies)
    [–] [email protected] 34 points 1 year ago

    Yeah he didn't find the right unmaintained project. There are many many many cs undergrads starting projects that will become unmaintained pretty soon.

    [–] [email protected] 171 points 1 year ago (7 children)

    I've gotten back into tinkering on a little Rust game project, it has about a dozen dependencies on various math and gamedev libraries. When I go to build (just like with npm in my JavaScript projects) cargo needs to download and build just over 200 projects. 3 of them build and run "install scripts" which are just also rust programs. I know this because my anti-virus flagged each of them and I had to allow them through so my little roguelike would build.

    Like, what are we even suppose to tell "normal people" about security? "Yeah, don't download files from people you don't trust and never run executables from the web. How do I install this programming utility? Blindly run code from over 300 people and hope none of them wanted to sneak something malicious in there."

    I don't want to go back to the days of hand chisling every routine into bare silicon by hand, but i feel l like there must be a better system we just haven't devised yet.

    [–] [email protected] 30 points 1 year ago (4 children)

    Debian actually started to collect and maintain packages of the most important rust crates. You can use that as a source for cargo

    load more comments (4 replies)
    [–] [email protected] 28 points 1 year ago

    Which is why you shouldn't do that. Dependency nightmare is a real problem many developers face. More to the point they impose it on you as well if you are by any reason forced to use their software. Well established libraries are gateway to this. People are getting out of their way to complicate lives to themselves and massive amount of others just so they could avoid writing a function or two. Biggest absurdity I like to point out to people is the existence of is-number NPM package, which does that. It has 2300 dependent projects on it!!! Manifest file for said package is bigger than the source. And the author had the hubris to "release it under MIT". How can you claim copyright on num - num === 0?

    On all the projects I manage I don't allow new dependencies unless they are absolutely needed and can't be easily re-implemented. And even then they'd have to be already in the Debian respository since it's a good and easy way to ensure quick fixes and patching should it be needed. Sometimes alternative to what we wanted to use already is in repo, then we implement using different approach. We only have few Python modules that are not available in repo.

    Managing project complexity is a hard thing and dependencies especially have a nasty habit of creeping up. I might be too rigid or old-school or whatever you want to call it, but hey at least we didn't get our SSH keys stolen by NPM package.

    [–] [email protected] 27 points 1 year ago (6 children)

    THIS.

    I do not get why people don't learn from Node/NPM: If your language has no exhaustive standard library the community ends up reinventing the wheel and each real world program has hundreds of dependencies (or thousands).

    Instead of throwing new features at Rust the maintainers should focus on growing a trusted standard library and improve tooling, but that is less fun I assume.

    load more comments (6 replies)
    [–] [email protected] 18 points 1 year ago* (last edited 1 year ago) (1 children)

    It's a really wicked problem to be sure. There is work underway in a bunch of places around different approaches to this; take a look at SBoM (software bill-of-materials) and reproducible builds. Doesn't totally address the trust issue (the malicious xz releases had good gpg signatures from a trusted contributor), but makes it easier to spot binary tampering.

    [–] [email protected] 12 points 1 year ago* (last edited 1 year ago)

    +1

    Shameless plug to the OSS Review Toolkit project (https://oss-review-toolkit.org/ort/) which analyze your package manager, build a dependency tree and generates a SBOM for you. It can also check for vulnerabilitiea with the help of VulnerableCode.

    It is mainly aimed at OSS Compliance though.

    (I am a contributor)

    [–] [email protected] 18 points 1 year ago (2 children)

    Do you really need to download new versions at every build? I thought it was common practice to use the oldest safe version of a dependency that offers the functionality you want. That way your project can run on less up to date systems.

    [–] [email protected] 39 points 1 year ago* (last edited 1 year ago) (2 children)

    Most softwares do not include detailed security fixes in the change log for people to check; and many of these security fixes are in dependencies, so it is unlikely to be documented by the software available to the end user.

    So most of the time, the safest "oldest safe" version is just the latest version.

    load more comments (2 replies)
    [–] [email protected] 23 points 1 year ago (3 children)

    Okay, but are you still going to audit 200 individual dependencies even once?

    load more comments (3 replies)
    load more comments (2 replies)
    [–] [email protected] 96 points 1 year ago

    Getting noticed because of a 300ms delay at startup by a person that is not a security researcher or even a programmer after doing all that would be depressing honestly.

    [–] [email protected] 93 points 1 year ago (1 children)

    I love free software community. This is one of the things free software was created. The community defends its users.

    load more comments (1 replies)
    [–] [email protected] 73 points 1 year ago (1 children)

    ~~opensource~~autists win!

    [–] [email protected] 40 points 1 year ago

    Opensautists

    [–] [email protected] 64 points 1 year ago* (last edited 1 year ago) (1 children)

    The problem I have with this meme post is that it gives a false sense of security, when it should not.

    Open or closed source, human beings have to be very diligent and truly spend the time reviewing others code, even when their project leads are pressuring them to work faster and cut corners.

    This situation was a textbook example of this does not always happen. Granted, duplicity was involved, but still.

    [–] [email protected] 13 points 1 year ago* (last edited 1 year ago) (5 children)

    100%.

    In many ways, distributed open source software gives more social attack surfaces, because the system itself is designed to be distributed where a lot of people each handle a different responsibility. Almost every open source license includes an explicit disclaimer of a warranty, with some language that says something like this:

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

    Well, bring together enough dependencies, and you'll see that certain widely distributed software packages depend on the trust of dozens, if not hundreds, of independent maintainers.

    This particular xz vulnerability seems to have affected systemd and sshd, using what was a socially engineered attack on a weak point in the entire dependency chain. And this particular type of social engineering (maintainer burnout, looking for a volunteer to take over) seems to fit more directly into open source culture than closed source/corporate development culture.

    In the closed source world, there might be fewer places to probe for a weak link (socially or technically), which makes certain types of attacks more difficult. In other words, it might truly be the case that closed source software is less vulnerable to certain types of attacks, even if detection/audit/mitigation of those types of attacks is harder for closed source.

    It's a tradeoff, not a free lunch. I still generally trust open source stuff more, but let's not pretend it's literally better in every way.

    load more comments (5 replies)
    [–] [email protected] 46 points 1 year ago (4 children)

    Immediately noticed even though the packages have been out for over a month?

    Easily could have stolen a ton of information in that month.

    [–] [email protected] 41 points 1 year ago (2 children)

    Yeah but tbf it was deployed on mostly rolling release and beta releases.

    No enterprise on prod is worried because they're still on RHEL 6 /s

    [–] [email protected] 18 points 1 year ago (3 children)

    Why the /s? We are migrating our host to RHEL7 since months.

    load more comments (3 replies)
    [–] [email protected] 12 points 1 year ago

    Yeah they got lucky. But shows how susceptible systems are. Really makes you wonder how many systems are infected with similar - this wouldn't be the first back door that's live in Linux systems.

    load more comments (3 replies)
    [–] [email protected] 42 points 1 year ago (3 children)

    i feel like the mental gymnastics should end with a rake step

    [–] [email protected] 48 points 1 year ago (4 children)

    It's about the complex rationalizations used to create excuses (pretexts).

    The original is this:

    [–] [email protected] 12 points 1 year ago

    Alright I won't argue about that specific version's point, but this is basically a template for constructing a strawman argument.

    load more comments (3 replies)
    load more comments (2 replies)
    [–] [email protected] 33 points 1 year ago

    It is pretty funny, I bet he's kicking himself right now for it.

    [–] [email protected] 30 points 1 year ago

    I just updated xz in my system. Thanks Lemmy!

    [–] [email protected] 24 points 1 year ago (2 children)
    [–] [email protected] 48 points 1 year ago (1 children)
    [–] [email protected] 31 points 1 year ago

    Openssh backdoor via a trojan'ed release of liblzma

    [–] [email protected] 21 points 1 year ago (1 children)

    Ever wondered why ${insert_proprietary_software_here} takes so long to boot?

    [–] [email protected] 19 points 1 year ago

    because AbstractTransactionAwarePersistenceManagerFactoryProxyBean needs to spin up 32 electron instances (one for each thread) to ensure scalability and robustness and then WelcomeSolutionStrategyExecutor needs to parse 300 megabytes of javascript to facilitate rendering the "welcome" screen

    [–] [email protected] 16 points 1 year ago (10 children)

    The only real downside on the open source side is that the fix is also public, and thus the recipe how to exploit the backdoor.

    If there's a massive CVE on a closed source system, you get a super high-level description of the issue and that's it.

    If there's one on an open source system, you get ready-made "proof of concepts" on github that any script kiddy can exploit.

    And since not every software can be updated instantly, you are left with millions of vulnerable servers/PCs and a lot of happy script kiddies.

    See, for example, Log4Shell.

    [–] [email protected] 80 points 1 year ago* (last edited 1 year ago) (3 children)

    If your security relies on hidden information then it's at risk of being broken at any time by someone who will find the information in some way. Open source security is so much stronger because it works independently of system knowledge. See all the open source cryptography that secures the web for example.
    Open source poc and fix increases awareness of issues and helps everyone to make progress. You will also get much more eyes to verify your analysis and fix, as well as people checking if there could other consequences in other systems. Some security specialists are probably going to create techniques to detect this kind of sophisticated attack in the future.
    This doesn't happen with closed source.
    If some system company/administrator is too lazy to update, the fault is on them, not on the person who made all the information available for your to understand and fix the issue.

    [–] [email protected] 10 points 1 year ago (1 children)

    Crowd sourcing vulnerability analysis and detection doesn’t make open source software inherently more secure.

    Closed source software has its place and it isn’t inherently evil or bad.

    This event shows the good and bad of the open source software world but says NOTHING about closed source software.

    [–] [email protected] 27 points 1 year ago (12 children)

    Crowd sourcing vulnerability analysis and detection doesn’t make open source software inherently more secure.

    It does, because many more eyes can find issues, as illustrated by this story.

    Closed source isn't inherently bad, but it's worse than open source in many cases including security.

    I think you're the only one here thinking publishing PoC is bad.

    load more comments (12 replies)
    load more comments (2 replies)
    [–] [email protected] 43 points 1 year ago

    Honestly, for closed source software the POCs are also immediately available. Lots of threat actors just use patch diffing.

    These days vulnerabilities are at times also patched with other non-related commits to conceal what exactly has changed.

    [–] [email protected] 27 points 1 year ago

    Even in open source, responsible disclosure is generally possible.

    See, e.g. Spectre/Meltdown, where they worked privately with high level Linux Kernel developers for months to have patches ready on all supported branches before they made the vulnerability public

    [–] [email protected] 26 points 1 year ago (3 children)

    bUt gUyS WhAt aBoUt sEcUrItY ThRoUgH ObScUrItY??

    load more comments (3 replies)
    load more comments (5 replies)
    [–] [email protected] 14 points 1 year ago (1 children)
    load more comments (1 replies)
    load more comments
    view more: next β€Ί