Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
sudo in Windows.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.
Immediately get noticed
Realistically, though, we are only aware of that one because it was noticed in that unlikely scenario and then widely reported. For all we know, most open source backdoors are alive and well in our computers, having gone unnoticed for years.
Yup.
But in open source it CAN be noticed, by anyone determined enough to dig into its side effects.
Proprietary software? You file a regression bug that startup takes 500ms longer, and it might get looked at.
Also, backdoors that are discovered in open source software improve automated software auditing.
500ms longer, and it might get looked at.
Why would you even lie to the poor fellow like that? 🤣 lol
The flaw also highlighted a social engineering exploit. It’s not the first time some vulnerability has entered open source software due to social pressure on the maintainer. Notably EventStream exploit.
This is difficult to account for. You can’t build automated tooling for social engineering exploits.
Wait, that references something that actually happened?
edit This?
Wow, thanks, that’s way better than the link I found.
Yes, this particular incident.
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
In February 2024, a malicious backdoor was introduced to the Linux build of the xz utility within the liblzma library in versions 5.6.0 and 5.6.1 by an account using the name "Jia Tan".[b][4] The backdoor gives an attacker who possesses a specific Ed448 private key remote code execution through OpenSSH on the affected Linux system. The issue has been given the Common Vulnerabilities and Exposures number CVE-2024-3094 and has been assigned a CVSS score of 10.0, the highest possible score.[5]
Microsoft employee and PostgreSQL developer Andres Freund reported the backdoor after investigating a performance regression in Debian Sid.[8] Freund noticed that SSH connections were generating an unexpectedly high amount of CPU usage as well as causing errors in Valgrind,[9] a memory debugging tool.[10]
Thats not really how open source works. If you use an open source tool like say, nano. It has been looked at and improved for many years by many people who have worked up an understanding of the code.
I realize that this can only be natively understood by a programmer.
What we (I) do when we work at open source projects is reading through the code for so long until we "get it". It means we start to understand what does what. If you want so change something, you must locate it, finding out what it is not. The chance that someone stumbles across something that then sparks a full blown investigation isnt that low. Of course you can hide something in extremely long and boring code but its alas automatically tested by most software shops.
In short: we dont do this since yesterday and opeb source is so many universes better than closed source is a truth that only a fool would disregard.
Are you sure?
All I'm saying is leftPad, if you still remember.
As a programmer I do not believe you when you claim that you read through all the code of all the libraries you include.
Especially with more hardcore dependencies (like OpenSSL), hardly anyone reads through that.
That's assuming the attacker is stupid enough to put the exploit in the source code where it can be easily discovered.
The Xz exploit was not present in the source code.
It was hidden in the makefile as an obfuscated string and injected into the object file during the build process.
I saw the code. It was pretty obvious once you look at that particular piece. You have to adapt the makefile pretty often so you also would see gibberish. If you're a programmer and you encounter what YOU think is gibberish, all alarms go off.
i dont know your experience in coding but I dont see how a huge number (a given with old and popular code) of experienced people could overlook something like this.
But this is the crucial thing. It wasn't in the repository. It was in the tarball. It's a very careful distinction because, people generally reviewed the repository and made the assumption that what's there, is all that matters.
The changes to the make process only being present in the tarball was actually quite an ingenius move. Because they knew that the process many distro maintainers use is to pull the tarball and work from that (likely with some automated scripting to make the package for their distro).
This particular path will probably be harder to reproduce in the future. Larger projects I would expect have some verification process in place to ensure they match (and the backup of people independently doing the same).
But it's not to say there won't in the future be some other method of attack the happens out of sight of the main repository and is missed by the existing processes.
I feel like its a mixed bag. Certainly there's an infinitely higher chance of someone randomly noticing a backdoor in OSS than in closed source simply because any OSS project in use has someone looking at it. Many closed systems have dusty corners that haven't had programmer eyes on them in years.
But also, modern dev requires either more vigilance than most of us have to give or more trust than most of us would ideally be comfortable offering. Forget leftpad, I've had npm dependencies run a full python script to compile and build sub dependencies. Every time I run npm update, it could be mining a couple of bitcoins for all I know in addition to installing gigs and gigs of other people's code.
The whole industry had deep talks after leftpadgate about what needed to be done and ultimately, not much changed. NPM changed policy so that people couldn't just dissapear their packages. But we didn't come up with some better way.
Pretty much every language has its own NPM now, the problem is more widespread than ever. With Rust, it can run arbitrary macros and rust code in the build files, it can embed C dependencies. I'm not saying it would be super easy to hide something in cargo, i haven't tried so I don't know, but i do think the build system is incredibly vulnerable to supply chain attacks. A dependency chain could easily pull in some backdoor native code, embed it deep into your app, and you might never realize it's even there.
Reminds me of the old Debian OpenSSL vulnerability that went unnoticed for 2 years... but it did eventually get noticed.
https://lists.debian.org/debian-security-announce/2008/msg00152.html
For all we know...
This isn't something we need to speculate about. The vulnerability histories of popular closed and open source tools are both part of public data sets.
Looking into that data, the thing that stands out is that certain proprietary software vendors have terrible security track records, and open source tools from very small teams may be a mixed bag.
Evidence suggests this isn't the case.
We know of so many more closed source backdoors despite them being harder to notice in practice. Either before they became a problem or after they have been used in an attack. So we know backdoors can get noticed even without access to source code.
Meanwhile we have comparatively fewer backdoor type findings in major open source software, despite and thanks to increased scrutiny. So many people want to pad their resume with "findings" and go hit up open source software relentlessly. This can be obnoxious because many of the findings are flat out incorrect or have no actual security implications, but among the noise is a relatively higher likelihood that real issues get noticed.
The nature of the xz attack shows the increased complexity associated with attempting to back door open source. Sneaking a malicious binary patch into test data, because the source code would be too obvious, and having to hide asking the patch in an obfuscated way in build scripts that would only apply in theory under specific circumstances. Meanwhile the closed source backdoors have frequently been pretty straightforward but still managed to ship and not be detected.
Even if we failed to detect unused backdoors, at some point someone would actually want to use their backdoor, so they should be found at some point.
Open source and proprietary software development have very different goals. Open source is generally about making software that's useful. Proprietary software's goal is to make money by any means necessary. Viewing it from that angle, open source devs and the community are more motivated to keep an eye out for backdoors. While proprietary software, they won't give a fuck until something affects their bottom line. Just because of that, I feel safer using open source software in general.
The sad part is is that you're right.
And the reason that it's sad is that most of the individual veneers on proprietary projects deeply about a project itself and have the same goals as they do with open source software, which is just to make something that's useful and do cool shit.
Yep, the business itself can force them not take care of problems or force them to go in directions that are counter to their core motivations.
Also, many proprietary softwares rely on open source libraries. So unless they catch, patch, and do not contribute those fixes, proprietary will be at least as vulnerable as the oss they depend on.
It always seems like it depends on really old libraries with major security flaws
This is why open source, total transparency, radical free speech and democracy is the one and only way. Because if there's even one little shadow there will be a scorpion hiding in it.
radical free speech
If that includes calling company money "free speech" (which the US does) I don't agree. I'm also not ok with holocaust denial and Naziism.
Is this still true in the age of targeted social media propaganda?
Seems to me that radical free speech without moderating for basic accuracy or malicious disinfo has pretty much kicked of the downfall of the American experiment
You keep using that term “mental gymnastics”. I’m not sure it means what you think it does.
i save that meme for the next time a huge psyops heist like with xz gets uncovered and people talk about how it shows the flaws of free open source. If It's proprietary it's easier to just get a job at the company, then gaining trust and building pressure with multiple fake accounts, and hiding it in one of the testing tarballs and then get uncovered anyway by a postgres admin doing performance benchmarks
The proprietary backdoors come with spies doing much more gymnastics to gain access to those who know the secrets to access those backdoors.
Makes me remember, wasn't there a well respected dev who, out of the blue, decided to add a vulnerability in a linux package last year?
That’s what this meme is referencing. That was the XZ Utils backdoor. The contributor spent 5 years gaining the lead dev’s trust, waited for the lead dev to get busy with other things, then basically bullied the lead dev into handing over control of the project. They quietly pushed an SSH backdoor.
And then they were almost immediately called out by a dude who was running benchmarks and realized that his SSH requests were taking like 5ms longer than they should. That delay was because the backdoor was checking the SSH request against a table of backdoor requests, to see if it should allow the connection even if the UN/PW was wrong.
The big concern was that the SSH system was used all over the world. But rolling back to a previous version was easy, and most systems hadn’t updated yet anyways.
yeah this meme is referencing xz
Para hablantes de español, este video explica la vulnerabilidad de XZutils, a la que hace referencia este meme: https://youtu.be/mTpDmhF4BSw