Arthur T Knackerbracket has processed the following story:
Thousands of GitHub repositories were forked (copied) with their clones altered to include malware, a software engineer discovered today.
While cloning open source repositories is a common development practice and even encouraged among developers, this case involves threat actors creating copies of legitimate projects but tainting these with malicious code to target unsuspecting developers with their malicious clones.
GitHub has purged most of the malicious repositories after receiving the engineer's report.
Today, software developer Stephen Lacy left everyone baffled when he claimed having discovered a "widespread malware attack" on GitHub affecting some 35,000 software repositories.
Contrary to what the original tweet seems to suggest, however, "35,000 projects" on GitHub have not been affected or compromised in any manner.
Rather, the thousands of backdoored projects are copies (forks or clones) of legitimate projects purportedly made by threat actors to push malware.
Official projects like crypto, golang, python, js, bash, docker, k8s, remain unaffected. But, that is not to say, the finding is unimportant, as explained in the following sections.
While reviewing an open source project Lacy had "found off a google search," the engineer noticed the following URL in the code that he shared on Twitter:
hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ruBleepingComputer, like many, observed that when searching GitHub for this URL, there were 35,000+ search results showing files containing the malicious URL. Therefore, the figure represents the number of suspicious files rather than infected repositories:
We further discovered, out of the 35,788 code results, more than 13,000 search results were from a single repository called 'redhat-operator-ecosystem.'
[...] As a best practice, remember to consume software from the official project repos and watch out for potential typosquats or repository forks/clones that may appear identical to the original project but hide malware.
This can become more difficult to spot as cloned repositories may continue to retain code commits with usernames and email addresses of the original authors, giving off a misleading impression that even newer commits were made by the original project authors. Open source code commits signed with GPG keys of authentic project authors are one way of verifying the authenticity of code.
(Score: 4, Insightful) by Rosco P. Coltrane on Thursday August 04 2022, @02:34PM (1 child)
I stick to the root projects, even if they don't have some improvements that a fork may provide.
Case in point: the super-useful PySerial module for Python has many clones designed to do this-or-that, or solve this-or-that problem. Whenever I find the solution to a PySerial problem in one of the forks, I prefer to stick to the original PySerial module and overload it with my own code based on the modifications offered by the fork - or even plain onboard the modification from the fork locally, after review, but I won't install forked module itself: I don't know who made it, I don't know if they won't join a cult and be asked to load their fork full of malware in 6 months... while I have a reasonable expectation that a module like PySerial is such a biggie that it's unlikely to be subverted.
(Score: 1) by Dichzor on Thursday August 04 2022, @04:44PM
It's indeed a problem, both Python and javascript ecosystems have this weakness.
What you do is a sane mitigation, it does reduce the risk here.
I haven't got a clue as how to solve the problem with people uploading malicious packages.
More authentication or validation is not the answer and never was, neither is cutting the hand they clicked "upload" with (regrettably, it also needs authentication).
Cryptography... not really, spooks can and will get magical certs...
Actually testing the code for side effects and input of length upto N on the spot... opens door for obfuscated multipackage runtime encoded (pick at least one) scripts that synthesise a shellcode etc... also not feasible for a 1 megaline function that takes 65535 parameters...
oooh i know! Someone should start a cult that tracks down and inhumes people who submit malicious typo packages!
But who will finance such a thing?! lol
(Score: 5, Informative) by Mojibake Tengu on Thursday August 04 2022, @04:52PM (7 children)
Malware actors buying legitimate public projects and subverting them is the next threat.
The worst part of contemporary open source philosophy is the continuous update paradigm.
I hate that. It's a plague, disguised as security necessity feature. Every even the smallest update is a risk of collapse to a production system.
In past two decades such collapse happened to me more than once with such established projects like LibreOffice (about 2010) suddenly unable to open old documents from previous versions.
A true disaster for innocent office employees. This incident prompted me to migrate from Linux to BSD where at least I could lock the whole system down to make it update-resistant.
This is a result of corporate based FOSS developers who render themselves self-important ego-builders, irreplacable in their own corporate ecosystem.
What will they do when a state actor agency orders their corp to implant stuff on demand? In flood of regular updates, no one would notice.
Project purchaser attack I mention is in the same category.
This makes global disaster inevitable one day.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 5, Insightful) by vux984 on Thursday August 04 2022, @05:48PM (3 children)
"The worst part of contemporary open source philosophy is the continuous update paradigm."
Just like democracy, its terrible, its just less terrible than everything else we've tried.
Because the alternative of leaving known security vulnerabilities in the production environment forever is definitely not a better solution.
(Score: 1, Informative) by Anonymous Coward on Thursday August 04 2022, @08:38PM
FYI: the fortune on the bottom of the page right now:
(Score: 2) by darkfeline on Friday August 05 2022, @03:35AM (1 child)
> its just less terrible than everything else we've tried
It's not. Every dependency manager that does "continuous update" provides lock files to pin specific versions of all dependencies.
Everyone agrees that continuous update sucks so much that no one uses it. Instead, they update those pinned versions at a regular cadence without sufficient vetting of those updates.
Which is a subtly different problem. "Continuous update" means you simply don't know when you update your dependencies. "Lock and update" means that you do know when you update your dependencies, you just don't care if you blow your eye out.
Join the SDF Public Access UNIX System today!
(Score: 2) by vux984 on Friday August 12 2022, @06:23PM
"Everyone agrees that continuous update sucks so much that no one uses it."
Heh, not 'no one'; there's been a quite few puplic instances of it happening to projects using CI pipelines that just grabbed latest version without even a conscious decision to update the dependencies.
And the way most of the world runs their systems; Windows in particular is forced & automatic for most people (although you can usually roll back), but even say, ios updates -- sure you have to click ok, but there's no way for the average person to make any meaningful evalation ahead of time. And if you just click ok when prompted, that's pretty much 'continuous updates' too, and there's not even the option to roll back in a lot of cases.
But yes, I fully agree, well run/responsibly run projects, use lock files, or local caches or something along that line to limit the cadence of dependency updates, and limit them to happening 'deliberately' even if testing or vetting isn't really inadequate.
(Score: 1, Interesting) by Anonymous Coward on Thursday August 04 2022, @07:43PM
That threat model is already a thing and has been for a while with browser extensions.
(Score: 3, Interesting) by darkfeline on Friday August 05 2022, @03:29AM
Come to the Go side, we have pinned and hashed dependencies by default. It is effectively impossible to modify a package once published (there is a global, zero-trust hash store of every version of every public package), and dependencies are never upgraded implicitly. Of course, that doesn't stop you from adding an update deps script to your CI, but that's your problem.
From https://research.swtch.com/vgo-principles [swtch.com]
"The usual first objection to prioritizing repeatability is to claim that preferring the latest version of a dependency is a feature, not a bug. The claim is that programmers either don’t want to or are too lazy to update their dependencies regularly, so tools like Dep should use the latest dependencies automatically. The argument is that the benefits of having the latest versions outweigh the loss of repeatability.
But this argument doesn’t hold up to scrutiny. Tools like Dep provide lock files, which then require programmers to update dependencies themselves, exactly because repeatable builds are more important than using the latest version. When you deploy a 1-line bug fix, you want to be sure that your bug fix is the only change, that you’re not also picking up different, newer versions of your dependencies.
You want to delay upgrades until you ask for them, so that you can be ready to run all your unit tests, all your integration tests, and maybe even production canaries, before you start using those upgraded dependencies in production. Everyone agrees about this. Lock files exist because everyone agrees about this: repeatability is more important than automatic upgrades."
For the checksum database:
https://go.dev/ref/mod#checksum-database [go.dev]
https://research.swtch.com/tlog [swtch.com]
Join the SDF Public Access UNIX System today!
(Score: 3, Insightful) by jb on Friday August 05 2022, @04:29AM
That's not a bug, it's a feature -- most likely intended to make using LO "feel" more like using Microsoft Office.
(Score: 2) by darkfeline on Friday August 05 2022, @03:19AM (1 child)
Blindly running random code from the Internet, I sure hope you guys don't do this.
You do audit all your dependencies, right? Right? And background check their maintainers?
It shouldn't matter if there's a malicious fork. Fork or not, you're checking them first. Right?
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Friday August 05 2022, @03:33AM
I have't done it in the last 2 hours, ha ha ha... *slinks away*