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
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.
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.
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.
Totally agree.
All the push back Iām getting is from people who seem to be worried about open source somehow losing a positive talking point, when comparing it to close source systems, which is not my intention (the loss of the talking point). (I personally use Fedora/KDE.)
But sticking our heads in the sand doesnāt help things, when issues arise, we should acknowledge them and correct them.
using what was a socially engineered attack on a weak point in the entire dependency chain.
An example of what you may be speaking about, indirectly. We can only hope that maintainers do due diligence, but it is volunteer work.
In the broader context of that thread, Iām inclined to agree with you: The circumstances by which this particular vulnerability was discovered shows that it took a decent amount of luck to catch it, and one can easily imagine a set of circumstances where this vulnerability wouldāve slipped by the formal review processes that are applied to updates in these types of packages. And while it would be nice if the billion-dollar-companies that rely on certain packages would provide financial support for the open source projects they use, the question remains on how we should handle it when those corporations donāt. Do we front it ourselves, or just live with the knowledge that our security posture isnāt optimized for safety, because nobody will pay for that improvement?
There are two big problems with the point that youāre trying to make:
There are many open source projects being run by organizations with as much (often stronger) governance over commit access as a private corporation would have over its closed source code base. The most widely used projects tend to fall under this category, like Linux, React, Angular, Go, JavaScript, and innumerable others. Governance models for a project are a very reasonable thing to consider when deciding whether to use a dependency for your application or library. Thereās a fair argument to be made that the governance model of this xz project should have been flagged sooner, and hopefully this incident will help stir broader awareness for that. But unlike a closed source code base, you can actually know the governance model and commit access model of open source software. When it comes to closed source software you donāt know anything about the companyās hiring practices, background checks, what access they might provide to outsourced agents from other countries who may be compromised, etc.
Youāre assuming that 100% of the source code used in a closed source project was developed by that company and according to the companyās governance model, which you assume is a good one. In reality BSD/MIT licensed (and illegally GPL licensed) open source software is being shoved into closed source code bases all the time. The difference with closed source software is that you have no way of knowing that this is the case. For all you know some intern already shoved a compromised xz into some closed source software that youāre using, and since that intern is gone now it will be years before anyone in the company notices that their software has a well known backdoor sitting in it.
None of what Iām saying is unique to the mechanics of open source. Itās just that the open source ecosystem as it currently exists today has different attack surfaces than a closed source ecosystem.
Governance models for a project are a very reasonable thing to consider when deciding whether to use a dependency for your application or library.
At a certain point, though, thatās outsourced to trust whoever someone else trusts. When I trust a specific distro (because Iām certainly not rolling my own distro), Iām trusting how they maintain their repos, as well as which packages they include by default. Then, each of those packages has dependencies, which in turn have dependencies. The nature of this kind of trust is that we select people one or two levels deep, and assume that they have vetted the dependencies another one or two levels, all the way down. XZ did something malicious with systemd, which opened a vulnerability in sshd, as compiled for certain distros.
Youāre assuming that 100% of the source code used in a closed source project was developed by that company and according to the companyās governance model, which you assume is a good one.
Not at all. Iām very aware that some prior hacks by very sophisticated, probably state sponsored attackers have abused the chain of trust in proprietary software dependencies. Stuxnet relied on stolen private keys trusted by Windows for signing hardware drivers. The Solarwinds hack relied on compromising plugins trusted by Microsoft 365.
But my broader point is that there are simply more independent actors in the open source ecosystem. If a vulnerability takes the form of the weakest link, where compromising any one of the many independent links is enough to gain access, that broadly distributed ecosystem is more vulnerable. If a vulnerability requires chaining different things together so that multiple parts of the ecosystem are compromised, then distributing decisionmaking makes the ecosystem more robust. Thatās the tradeoff Iām describing, and making things spread too thin introduces the type of vulnerability that Iām describing.
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.
I feel like thatās really crappy non-vegan mental gymnastics. I think veganism is morally superior, but I really want to show mine off, just because Iām offended by how stupid all these are-the fact I know theyāre real makes me more ashamed of eating that yogurt earlier than any amount of chatt slavery or butchery ever will.
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.
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.
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.
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.
Researchers have found a malicious backdoor in a compression tool that made its way into widely used Linux distributions, including those from Red Hat and Debian.
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.
Shameless plug to the OSS Review Toolkit project (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.
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.
Easily, just look at the standard libraries of Java/Python and Golang! :-P
To get one thing out of the way: Each standard library has dark corners with bad APIs and outdated modules. IMHO it is a tradeoff, and from my experience even a bad standard library works better than everyone reinvents their small module. If you want to compare it to human languages: Having no standard library is like agreeing on the English grammar, but everyone mostly makes up their own words, which makes communication challenging.
My examples of missing items from the Rust standard library (correct me, if I am wrong, not a Rust user for many reasons):
Cross platform GUI library (see SWING/Tk)
Enough bits to create a server
Full set of data structures and algorithms
Full set of serialization format processing XML/JSON/YAML/CVS/INI files
HTTP(S) server for production with support for letsencrypt etc.
Things I donāt know about if they are provided by a Rust standard library:
Go like communication channels
High level parallelism constructs (like Tokyo etc.)
My point is, to provide good enough defaults in a standard library which everybody knows/are well documented and taught. If someone has special needs, they always can come up with a library. Further, if something in the standard library gets obsolete, it can easily be deprecated.
Python doesnāt have a production web server in its standard library. Neither does Java. Those are external programs or libraries. C# is the only language I know that comes with an official production grade server, and thatās still a separate package (IIS).
Golangs web server is production grade and used in production. (Of course everyone uses some high performance proxy like NGINX for serving static pages, thatās another story.)
Technically you are right that java has no production web server, which I donāt like, OTOH Java has standard APIs WebServers and Spring is the defacto standard for web applications. (I totally would not mind to move Spring into the OpenJDK.)
My point is simple: Instead of having Rust edtion 2020, 2021 etc. and tweaking the syntax ad infinitum, Iād rather have a community which invests in a good/broad standard library and good tooling.
The only platform widely used in production w/o a big standard library is Node.js/JavaScript, mostly for historical reasons and look at the problems that Node.js has for a decade now because of the missing standard library.
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.
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.ā
You're starting to come to an interesting realization about the state of 'modern' programming and the risks we saw coming 20 years ago.
I donāt want to go back to the days [...]
You don't need to trade convenience for safety, but having worked in OS Security I would recommend it.
Pulling in random stuff you haven't validated should feel really uncomfortable as a professional.
Actually the dude was looking to profile some other program of his own and tried to reduce nose on the machine. Thatās when he noticed sshds creating a load of load with no reason.
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?
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.
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.
Yeah he didnāt find the right unmaintained project. There are many many many cs undergrads starting projects that will become unmaintained pretty soon.
Depends, for example Debian unattended-upgrade caused system restarts after many updates that was extremely inconvenient for me because I have a more manual bringup process. I had restarts turned off in its settings and it still restarted.
I uninstalled it and have not one single unwanted restart since then, so manual upgrades it is.
