Embedded Malicious Code in node-ipc

https://github.com/advisories/GHSA-97m3-w2cp-4xx6

by planb • 4 years ago

139 123 4 years ago

arriu• 4 years ago

This is career suicide and undermines the ecosystem due to the loss of trust.

Honest question, what can be done to address this type of issue? Lock fines are great and all but people rarely dig into their dependencies when upgrading.

How are you guys dealing with upgrades?

kevinsundar2• 4 years ago

Upgrade to the latest version only after its been available for 7 days. Obviously this won't work if everyone starts doing it.

jahewson• 4 years ago

But what happens when the latest version fixes a zero-day? Stay vulnerable for a week?

RKearney• 4 years ago

Wasn't SolarWinds compromised for 6+ months? 7 days doesn't sound like enough time. Although maybe that's not a good comparison as this was open source and SolarWinds is closed source.

I remember watching a Walmart talk on Node.js and how they vet every single update to every single module before they pull it into their internal repository for internal distribution. Perhaps the answer is to stop blinding pulling down dependancies from the internet?

rosndo8• 4 years ago

This is career suicide

Unlikely.

undermines the ecosystem due to the loss of trust.

Good, that trust was always misplaced. At least it’s only Russia and Belarus getting screwed instead of everybody getting hit by ransomware.

bastijn2• 4 years ago

I actually agree this is destroying your credibility as an author and caused me to search all projects author is involved in and blacklist them.

* Despite the motive for the act there is actual malicious code injected in a library without notifying or disclosing any information.

* The whole act was not well thought out. The check is rudimentary to put it gently, or plain naive to say it straight. Not only Russians are targeted but also anyone having vpns or other legitimate reasons to run under Russian IPs. Finally the check is crude and might as well fail at some point, with devastating effect.

* Author seems to be removing github issues, hiding conversations and doing damage control now that this backfires.

inopinatus7• 4 years ago

Wow that is naive. Geolocation by IP address is notoriously error-prone.

The most obvious is former Soviet republics, or any neighbour of a target nation, being mis-identified. That includes Ukraine itself, by the way, but also Finland and Poland. How about territory that is disputed? Or adjacent to enclaves like Kaliningrad? But it can also include friendly-nation assets that just happen to be currently inside Russia or Belarus, including government entities and journalists. It can affect folks simply relying on mobile networks near borders. Address blocks are routinely reallocated, reassigned, reused, misused, on a global basis and an address range announced in Korea last year can show up in Canada tomorrow.

Even geolocation by client-side request can be wrong, too. Not just because it's easy to lie, but major nations also fuck with the GPS, which is an issue currently affecting Baltic aviation¹. By the same token, IP geolocation databases are easily misled by self-reporting from mobile devices. Simple example: imagine someone using a dedicated VPS in the US as a personal VPN exit node for their devices when visiting mainland China (actually, we don't have to imagine: I did exactly this). Any IP-based location assumptions start out incorrect, since it's by VPN exit IP; but later on, thanks to mobile device reporting, that IP address can end up misclassified long-term as "Chinese".

None of this is hypothetical. I visited Jordan a few years ago and whilst visiting ruins near Umm Qais, up by the Sea of Galilee, my phone was switching to Israeli networks. I also know of an Australian startup that was mis-identified as Russian and lost access to a major partner API². That's since resolved, but the point is, forget what you see on police procedurals; identifying the political jurisdiction of a device, whether it's by IP address or any other means, remains an art, not a science, and it's incredibly easy to be wrong.

As for the suggestion that the rest of us remain unaffected; any malware incident in the node ecosystem requires immediate attention and audit from every security team, whether you were the intended target or not. This idiot has cost all of us time and energy.

[1] https://www.theguardian.com/world/2022/mar/09/finland-gps-di...

[2] https://twitter.com/cyclytics/status/1503211938133966851

ugh123• 4 years ago

I think first thing would be to remove wildcards from version specs and lock them to your known, tested versions. Then only do upgrades after some time of stability in the ecosystem (i'd wait months, not days, for that)

kevinsundar2• 4 years ago

Waiting months means you don't get security fixes for months.

hughrr• 4 years ago

Mostly paying for some expensive software which says it protects us from this sort of crap but all it does is allow us to tick the compliance box while the engineers on the project flip between bouts of paranoia and insomnia.

I wish I was even joking.

At this point I tend to avoid importing anything if I can. I’ve written lots of stuff recently using Go and no imported packages because I trust the vendor more than I trust an open source package repo with 10,000 unknown contributors and dependencies.

avereveard• 4 years ago

you don't. unless your lib has an advisory, why would you upgrade? if it works it works. this whole movement of "move fast and break things" is braindamaged and it's about time it comes crashing unto itself.

progval2• 4 years ago

Honest question, what can be done to address this type of issue?

Limit your number of (transitive) dependencies, to lower the risk. Yes, this often needs more work on your side.

Use a curated package repository such as Debian/Ubuntu or Fedora (or a repository your company maintains), and only use dependencies from there. Yes, this is very painful for ecosystems that are still moving fast such as JS/Go/Rust, because many packages are not available yet, and non-security updates are less frequent.

hn_throwaway_99• 4 years ago

Limit your number of (transitive) dependencies, to lower the risk.

This is not really a viable solution in the JS ecosystem if you're using any popular framework like Vue or React. Note Vue pulled in node-ipc.

This "malicious actor" problem can be solved by NPM if they allowed better options when deciding which dependency version to pull. Right now it will pull any semver compatible version the moment it is published - there is no way to say "wait until all versions are at least a week or two old", which would basically eliminate most of the effects of nefarious versions.

Gravyness• 4 years ago

We are freezing our dependencies and aiming at almost never upgrading or updating things when possible. We rarely need the new things these modules come with in newer versions especially because some enhancements are security concern disguised as features.

It seems that in the past 2 years people became more pissed about the current state of things than normal. Since fakerjs incident I no longer trust maintainers by default.

You know how some people get very funny in the head discussing politics? This seems to be entering the field of programming bit by bit after programmers slowly realized they are the ones who shape the world. Some people don't know how to handle that level of responsibility so they see 'contributing' as a means to having a lot of power so that when something pokes them wrong they can unleash all their anger and it's not on a 140-character tweet that does nothing and instead it is on all the companies they managed to hold ransom over the free work he was going over the time people were treating him right.

UncleMeat4• 4 years ago

We are freezing our dependencies and aiming at almost never upgrading or updating things when possible.

I think this is an equally bad idea. The supply-chain attacks make the news, but getting pwned because of a known vuln in some dependency is a regular occurrence. That 10 year old OpenSSL binary is bad news.

UncleMeat4• 4 years ago

Honest question, what can be done to address this type of issue?

It is hard.

* Minimize dependencies. This is a problem for small organizations that really don't want to rewrite the world.

* Encourage dependencies on organizations that you have trust relationships or contractual relationships with. It is way less likely (though not impossible) that some malicious code will end up in an apache package than some random npm package owned by an individual person.

* Audit dependency changes. At the very least, have systems that detect various known-dangerous APIs showing up in OSS dependencies.

* Make it somebody's job to keep 3rd party code in check. This means pulling updates, auditing updates, and retiring unnecessary dependencies. People at your company should be able to get promoted by saying "we reduced the number of warranty-free dependencies in our codebase by 50%."

corentin88• 4 years ago

Also, don’t gitignore your node_modules directory.

jddil2• 4 years ago

Nope, I'd still hire them and this tells me the ecosystem is dealing with a threat in an appropriate way. Russia citizens have given up their right to play with the rest of the tech world. The fact that this is a silly way to do it doesn't change that In 2022 I'm having to explain that if your citizens are cheering you on as you invade a sovereign nation while indiscriminately killing civilian you will face some reprocussians from those of us who have said enough is enough.

Anything short of literally killing Russians, including a embargo is fair game.

Disagree? Go explain it to the Ukrainian father burying his daughter. I don't want to hear it.

rsstack2• 4 years ago

Regardless of whether I agree with you or not: his shitty method for identifying Russian computers would also target some IP addresses in Eastern Europe outside of Russia and Belarus.

ahelwer3• 4 years ago

Stop thinking in terms of abstractions (countries, nations, sovereignty, citizenry) and think in terms of people. People born into, living in the area of the Earth currently called Russia. Those people, each the equal of yourself, are what you call harm upon. It serves absolutely no purpose. What, you want everyday life to become so unpleasant for people that they take a flyer on a violent revolution to overthrow their government? You wish for them to plunge their country into civil war? And you cover this call to purposeless cruelty with emotional garbage about fathers burying daughters.

This idea that since some people in a country support its foreign misadventures they're fair game is the exact same reasoning employed by Osama bin Laden in his infamous Letter to America: https://www.theguardian.com/world/2002/nov/24/theobserver

nullifidian• 4 years ago

You can look at my comment history. I'm a Russian and vehemently against the war and what Putin has been doing for decades. I'm unlucky to still remain in Russia for a number of personal reasons. Should my life's work be deleted because I'm unlucky to still be in Russia? Software developers in Russia are probably the group least likely to support the War or Putin, by the virtue of their familiarity with English and the west. While such software weapon of mass destruction could case real damage to civilians, cause suicides because their life's work has been erased. Attacking civilians is not unlike what Putin is doing in Ukraine. Indefensible.

CJefferson• 4 years ago

Honestly, the way I wish we could fix this is to go back to people paying for software they rely on.

It would be (in my opinion) a fascinating court case to sue a company which got hacked which used lots of OSS, which all had a warranty that says "may not be fit for purpose".

If you built a house out of wood labelled "no warranty, may not be fit for purpose", and it fell down, I imagine you would be held responsible.

toinetoine• 4 years ago

Honestly, the way I wish we could fix this is to go back to people paying for software they rely on.

How would that be enforced though? Most companies aren't going to be ok making outside connections to the wider internet to check that their JSON de-serializing package can be used.

freeqaz• 4 years ago

I'll shill a little and answer this question:

Short-term: The only way out of this is to review + whitelist every package before it hits the NPM registry. This is something my company is building and we did a write up about it (and Node-ipc) here[0].

Longer term answer: Something like Deno needs to take off that adds permissions per dependency. We need to sandbox all untrusted code by default.

0: https://www.lunasec.io/docs/blog/node-ipc-protestware

UncleMeat4• 4 years ago

I think a really useful piece of information here is why did the Java SecurityManager fail. People talk about sandboxing library code but this is literally what the SecurityManager made possible ages ago. But virtually zero applications make widespread use of the SecurityManager to isolate library code.

Was it a question of being too soon? Was it horribly un-ergonomic (this is the explanation I usually hear)? Did its features not actually match what developers need?

It feels like callstack based permissions are a natural solution to "holy shit my json deserialization code is deleting files on disk" but there clearly is some trap hidden here that caused old solutions to fail.

Vinnl• 4 years ago

In this case it was pretty much addressed: few people have installed the malicious version, due to lockfiles and it being quickly blackholed from the ecosystem, by the major package through which this dependency snuck in (vue-cli, IIRC) quickly pinning its dependency to the unaffected version.

jka• 4 years ago

Supplier-side: multi-party code review for acceptance of changes into widely-used software.

Consumer-side: multi-party review prior to upgrades of dependencies in applications.

(note that neither of these necessarily require knowing the identity of the software author(s). in fact, perhaps reviews would be less biased in the absence of that information)

throwaway9843932• 4 years ago

what can be done to address this type of issue?

Only auto-upgrade for security fixes. For all others, wait between month to a year to update a dependency, unless one specifically fixes a bug you are experiencing.

Gigachad4• 4 years ago

NPM tells me that just about everything is a security issue. Apparently my linter has a critical security issue because I could put a malicious regex in my own linter config causing it to waste cpu..

Gigachad4• 4 years ago

The maintainer needs to go to jail. They knowingly distributed malware.

the42thdoctor• 4 years ago

Honest question, what can be done to address this type of issue?

Paid subscription-based NPM ? Yes, you could download a dependency directly from the repository on Github for free, but if do so through the paid NPM they assure you that the package is malware-free.

0x0000000• 4 years ago

Previous discussion from a few days ago: https://news.ycombinator.com/item?id=30717382

kodah4• 4 years ago

I feel like if you're a maintainer that does, or has done, this sort of thing you should not be maintaining software in FOSS. The FOSS ecosystem is built on a lot of trust and actions like this violate that foundation.

On the other hand, the people that sent SWAT teams to his door and sent death threats are equally threatening the trust foundations of FOSS.

Link to the vice article talking about SWATing: https://www.vice.com/en/article/dypeek/open-source-sabotage-...

tgv• 4 years ago

Just shows how well the trust system works. There is no foundation, unless some certified org wants to take it upon them to verify OSS. And that costs money.

That people call SWAT teams on the maintainer, I hadn't heard, but that's so much worse. The effect is also rather different. I don't have much OSS, and certainly nothing of any importance, but I'm going to keep the project I'm working on private. Too bad if someone else might have been interested.

encryptluks2• 4 years ago

If someone was running around your neighborhood trying to take your belongings, would you feel bad if someone called SWAT on them? I don't see how intentionally deleting people's files is much different.

kodah4• 4 years ago

The node-ipc package is fairly popular and it wouldn't be unreasonable for it to be in software or on machines that could result in someone being harmed. SWATing can certainly result in death, but obviously doesn't always (or most of the time). I think of them both as terrorism rather than trying to go through the mental gymnastics of which is worse.

hombre_fatal• 4 years ago

To me it’s just a reminder that you can’t just rely on trust and good faith when building systems including the internet itself. You have to design for bad actors or the honest people suffer.

Gigachad4• 4 years ago

Desktop computing is still too permissive for random bits of software. It's unreal that some random package you didn't even directly install has the ability to wipe your computer and steal the login cookie for your bank. Further work needs to be done to sandbox applications.

tejohnso• 4 years ago

people that sent SWAT teams to his door and sent death threats

Where are you getting this?

kodah4• 4 years ago

https://www.vice.com/en/article/dypeek/open-source-sabotage-...

tyingq• 4 years ago

Not much detail, but:

"Miller told IT Pro that he had been swatted"

From: https://www.itpro.com/development/open-source/367129/open-so...

rsstack2• 4 years ago

Author updated the README of the package to say "thanks to all the police that showed up to SWAT me". I suspect he's exaggerating, and he got a friendly visit from a couple police / federal agents.

tedunangst• 4 years ago

That article also says “There was no actual code to wipe computers. It only puts a file on the desktop.” So what's all the fuss about?

MauranKilom• 4 years ago

There was also code to replace the content of every file on the system with a heart emoji. I am not certain about the timeline though.

kodah4• 4 years ago

But then some versions of “node-ipc,” the much more popular piece of software that RIAEvangelist maintains, started overwriting files on computers based in Russia and Belarus with a heart emoji, according to a post on GitHub.

Because he went from posting a heart emoji to deleting files.

user3939382• 4 years ago

IANAL but I would go a lot further and say this behavior should be prosecuted. If this isn't a violation of the CFAA or something like it, it should be amended to include it.

TobyTheDog1234• 4 years ago

This is a great and often overlooked/undervalued point. Purposefully sabotaging machines through code repositories should be considered spreading malware & be subject to civil & criminal lawsuits.

Edit: I think I would actually like to see a lawsuit come out of this example.

rossmohax• 4 years ago

Other projects adopted non-malicious approach, where they publish anti war manifests: https://github.com/medikoo/es5-ext/blob/edf9fbac6c0d72a6192d...

tentacleuno• 4 years ago

It looks like the node-ipc has become a target for spam issues lately[0]. This reminds me of what happened with Notepad++[1] (except that was nothing compared to what the node-ipc maintainer did.)

EDIT: looks like Notepad++ also made a political statement about the crisis in Ukraine[2].

[0] https://github.com/RIAEvangelist/node-ipc/issues?q=is%3Aissu... [1]: https://news.ycombinator.com/item?id=21400526 [2]: https://notepad-plus-plus.org/news/v833-make-apps-not-war/

jddil2• 4 years ago

What the node ipc maintainer did was prove there was at least one person with scruples in this industry. Reading the rest of this thread is proving he's a minority though, depressing.

Also if you're going to delete my comments just delete my account. I'm done ignoring my industry will gladly enable dictators and pretending we are neutral. We are complicit and we need to take a stand... Or maybe we all just want to collect our fat paychecks while inventing more ways to kill people. Shrug.

ahelwer3• 4 years ago

I think you need to stop watching American cable news for a couple days. Acts like these will kill the open source ecosystem - an incredible achievement of humanity that showcases us at our best, working to help each other with limited individual economic incentive.

davidmurdoch8• 4 years ago

I maintain what is probably the most popular Ethereum simulator (Ganache) and it uses the npm ecosystem.

Years ago I chose to pin/lock all dependencies, even transitive dependencies (direct dependencies' dependencies) to much disagreement from the semver purists.

Crypto developers are extra high value targets because they likely access their wallet from the same machine they develop on. So I've taken a very hard stance on this, even feel we should do even better by disallowing updates for new releases (I realize adequate security here is not practical/feasible for most).

To make matters worse: devs often install npm packages with sudo (and I have a canned response for sudo related issues telling them that they must now format their drives to fix it, and even that might not be enough as their bios and other embedded firmware could also be compromised).

Meanwhile, yarn, a popular npm alternative, will NOT respect a package author's wishes to lock transitive dependencies. It's maddening (don't use yarn until/unless they fix this).

The only time a dependency shouldn't be pinned is if you are also the author of that dependency.

Anyway, people would say I'm fun at parties, but they stopped inviting me long ago.

jaquers• 4 years ago

How did you accomplish this practically? using '=' in package.json + shrinkwrap or vendoring in dependencies?

davidmurdoch8• 4 years ago

We bundle most, and ship npm-shrinkwrap.json for these ones we don't. The shrinkwrap is pruned (via a a custom script, not npm's prune command, because of reasons ) at publish time, as npm installs all dev dependencies if they exist in the shrinkwrap file (despite being marked as "dev": true in said shrinkwrap).

datalopers• 4 years ago

Do you regret using node/npm on such a high-risk installation?

davidmurdoch8• 4 years ago

When it was first built (6ish years ago? before I took over) there weren't any other practical options if you wanted an Ethereum simulator in JavaScript, which is a very common use case of ours.

Though now that wasm is popular and there are Rust implementations of Ethereum, I still think being able step into and debug from within a JavaScript application is valuable.

I think the ecosystem has just drank too much semver Kool-Aid.

So no, I don't regret it, and I don't think the problem is unique to npm, I think the problem is exacerbated by its popularity and addiction to loose semver (the default when installing a package by name).

nhoughto2• 4 years ago

I didn't know that about yarn transitives, do you have a link explaining more about the problem? I assumed a yarn.lock would.. lock, interesting to know more.

davidmurdoch8• 4 years ago

If a dependency includes it's own yarn.lock yarn will ignore it. It DOES respect the local lock file though, so it's not all bad.

leipert• 4 years ago

I assume the author is talking about the following problem:

I build library X and ship it with a lockfile to lock all transitive dependencies.

User installs library X, even though I ship a lock file, it isn’t respected. (I assume this makes Resolution way to complex)

If you ship a library where everything is locked, one should consider vendoring their dependencies. I think this is what npm does itself. (Or used to do). Or consider reducing your dependencies.

lstamour3• 4 years ago

My preferred fix for Yarn dependency tracking is to use zero installs[1] as there is no command to run and dependencies can be exactly what ships in the repo and nothing more (with the right flags). If accepting PRs from third-parties, the check-cache flag can run in CI to validate checksums from untrusted contributors — plus, you know, reading dependency source code when you have the time or reason to do so would be great within a PR review also.

I wish more tools were able to concisely show you the differences between dependencies, but… sometimes dependencies have binaries and at that point you might need to fork or clone and build your own version of a dependency. I’d suggest only using dependencies when you can read and understand the code, but there are always limits. I can’t think of the last time I thought of a glibc dependency except when using Alpine or compiling something for Cgo. But it’s still something to keep in mind: that sometimes your project will be simpler and easier with fewer, smaller dependencies where you can read the code in full.

1: https://yarnpkg.com/features/zero-installs#does-it-have-secu...

davidmurdoch8• 4 years ago

Great tips for application developers. Though this still exposes you to potential transitive dependency supply-chain attacks on first-time installs, though it's likely very low risk at this point, especially if you're careful as you've described.

For library authors that want to take reasonable precautions yarn makes it very hard. Though some suggest leaving transitive dependency updates up to the consumer makes yarn more secure, as they can update to the fixed packages sooner.. but I don't believe this benefit actually manifests often.

I guess the moral of the story is that semver is really great on paper, but people suck at it, sometimes on purpose.

Gigachad4• 4 years ago

Wouldn't it be more practical to do development inside a container or VM? Locking deps won't be enough if you haven't also audited them.

fragmede2• 4 years ago

Sure, but the valuable crypto credentials need to get used somewhere and the paranoid (justifiably-so) will note that VM escapes vulnerabilities, while not common, do exist, and aren't just hypothetical.

The current best practice, as I see it, is is a disposable chromebook, backed by a cold wallet which holds the keys to the multi-million dollar hoard.

glenngillen• 4 years ago

I appreciate your thoughtfulness, and someone who thinks deeply about things with a touch of self-deprecation is the exact kind of conversation I enjoy at parties ;)

bushbaba• 4 years ago

It's maddening the crypto world relies on Javascript so heavily. As a language it would never be my first, second, or even third choice for financial services.

mhio• 4 years ago

Meanwhile, yarn, a popular npm alternative, will NOT respect a package author's wishes to lock transitive dependencies

Do you mean locking transitive dependencies across an upgrade of a direct dependencies? How does npm do that?

thenerdhead• 4 years ago

Does anyone have an idea as to why OSS maintainers are doing this more and more often? Are they fed up with the sustainability of OSS that this is an opportunity to retaliate? I think this is the third "supply chain attack" through protest in two months. Is this the right way to protest?

userbinator2• 4 years ago

I suspect it's just the fact that there are a lot more SJW types doing software than there used to be.

TobyTheDog1234• 4 years ago

Well I think it's more because of the internet's lack of civility and lack of foresight/forethought, than a strictly SJW thing.

I could see someone on the right pulling a stunt like this if there was an equal representation of conservative coders in the OSS community.

Artur96• 4 years ago

Treating this as "malicious" isn't helping fight Russian disinformation, which is even more concerning seeing as Russian developers are openly dismissing genocide in Ukraine, and unironically citing Putinist "anti-nazi" propaganda.

4oo4• 4 years ago

GitHub really needs to explain itself here. I reported this repo, and of course they never really tell you what they decide to do. However, I asked them specifically to clarify themselves on their malware policies. Since from the looks of it, GitHub declared this as malicious code, but then still left the repo up and the maintainer has apparently suffered no consequences, since he later reverted the malicious code.

So the message they are apparently sending here is that means that it's totally OK to host malware on GitHub, given that it's targeted against a politically unpopular group of people, and if you later revert the change after it's done a bunch of damage.

Are some of those Russian developers assholes who support the Ukrainian genocide? Probably yes, but it's an extremely bad precedent to set to allow someone to use your platform for this just because it's politically fashionable.

And yes, I know that there are other things that other people might consider "malware" on GitHub under an overbroad definition of it (exploit PoCs, things like yt-dl, etc.), but this is pretty clear cut, since it hid this "feature" from users and very clearly caused destruction. Either the developer is incompetent at writing obfuscated code and the wiping functionality was a mistake (unlikely), or they are just that dishonest about what their motives actually were. Or just plain delusions of grandeur, equating cyberwarfare with peace...

Apparently though, it's all OK in this instance since it's collective punishment against the right group of people. I think the thing that makes me most angry about this is that the malware developer used the assumption that geo-ip databases are always 100% accurate...

rickstanley• 4 years ago

Tangential question(s): is there a way to lock node projects within a folder, that is, prevent any scripting action going outside its source folder? Creating a group that has permissions to specific folder helps? How can one isolate these projects (possible) harmful behaviour?

codedokode• 4 years ago

I guess that the only solution for malicious packages problem would be to have someone review the code. As there's lot of code and reviewing takes time, this has to be a paid service - for a pay you get access to a "safe" repository.

I am not sure if it could be viable business model though. People who use open source got used that it is free and are unlikely to pay.

inopinatus7• 4 years ago

For extra irony, observe that node-ipc was previously released under the "Don't Be A Dick" license¹, only switching to MIT in late 2020². The DBAD license includes this:

    Being a dick includes - but is not limited to - the following instances:
    (...)
    1c. Modifying the original work to contain hidden harmful content. That would make you a PROPER dick.

By the terms of its original license, I think we can therefore assert that the author is, indeed, a proper dick.

[1] http://dbad-license.org/

[2] https://github.com/RIAEvangelist/node-ipc/commit/9a1ad86d17a...

Embedded Malicious Code in node-ipc

Related Stories