11 ms·

Embedded Malicious Code in node-ipc

139 points by planb 5y ago

arriu 5y 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?
- kevinsundar 5y 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 5y ago
    But what happens when the latest version fixes a zero-day? Stay vulnerable for a week?
    - bastijn 5y ago
      In the hypothetical case all versions but the newest are vulnerable and the zero-day is also a problem in your specific deployment: manual tool validation is what should happen. Usually after a quick check if the package can be replaced easily.
  - RKearney 5y 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?
    - kadoban 5y ago
      It's also about threat models, who you're trying to realistically protect yourself from. Some solo idiot with a political cause, not particularly targetting you? Waiting a week before using a new version is probably good enough. A government specifically targetting you? Likely nowhere near good enough. There's a lot in between of course.
    - 41b696ef1113 5y ago
      >...Walmart talk on Node.js and how they vet every single update to every single module... Most organizations are not as big as Walmart? However, if the Walmarts/FANGS/etc with huge mega teams would publish their audited versions, that would be something. However, that seems like a liability without any potential gain for the mega teams.
- rosndo 5y 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.
  - deleted 5y ago
    [deleted]
  - bastijn 5y 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.
    - rosndo 5y 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. “FOSS developer” is hardly a career. Nobody is losing out on income by you blacklisting their projects.
      - ahelwer 5y ago
        Lots of FOSS developers support themselves with lucrative jobs or contracts they received on the basis of their reputation within the FOSS community (conference circuit, online forums, professional network, etc.) and otherwise mainly develop for the clout. Social consequences can be very effective in this way. It isn't quite like being blackballed but you really can't piss too many people off before those contracts start disappearing. Network effects work in reverse too.
- ugh123 5y 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)
  - kevinsundar 5y ago
    Waiting months means you don't get security fixes for months.
    - userbinator 5y ago
      It's known knowns vs unknown unknowns. I'd much rather have the former.
- hughrr 5y 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 5y 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.
- progval 5y 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 5y 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.
    - progval 5y ago
      > 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. Then you may need to reconsider using this kind of framework. If enough people do it, they may have to be more careful about what dependencies they have themselves.
      - Ekaros 5y ago
        It should have been clear from outset that pulling any number of transitive dependencies is horrible idea from security viewpoint. Ofc, it is fast and cheap in the moment... But, long term it clearly is not the best way.
- Gravyness 5y 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.
  - UncleMeat 5y 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.
    - mindri0t 5y ago
      This plus when a vulnerability is discovered and you are a million versions behind facing practically a ground up rewrite to get back to API compatible it is extremely hard to deal with. There is some balance to be had by waiting for things to become tested and stable rather than always defaulting to the bleeding edge, and maintaining a reasonable cadence of dependency management. You don’t always need to be on the latest version but you always need to be ready to be on the latest version
- UncleMeat 5y 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 5y ago
    Also, don’t gitignore your node_modules directory.
- jddil 5y 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.
  - rsstack 5y 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.
  - ahelwer 5y 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 https://www.theguardian.com/world/2002/nov/24/theobserver
    - filleduchaos 5y ago
      > And you cover this call to purposeless cruelty with emotional garbage about fathers burying daughters. On top of that, if there is anybody on the planet I would even entertain that kind of argument/"activism" from, it would definitely not be somebody from the US.
- CJefferson 5y 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 5y 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.
    - fragmede 5y ago
      Never mind enforcement, getting people to pay for things in the first place is actually really hard. Just look at Docker. They only charge for companies with more than $10 million of revenue or greater than 250 employees, yet every time they come up, they're accused of rug-pulling, and few people actually want to pay them for saving them time. Or maybe it's just a vocal minority. At the other end of the enforcement spectrums is an enterprise-y place like Oracle and their army of lawyers. They may not be popular, but developer goodwill doesn't pay the bills, paying customers do. Sun never learned that lesson. At the end of the day, if it's useful enough, IT can make a hole in the firewall. Just look at Splunk.
- freeqaz 5y 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 https://www.lunasec.io/docs/blog/node-ipc-protestware
  - UncleMeat 5y 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.
    - moltke 5y ago
      I personally really like the way wasm modules work. The modules all have a particular interface so you know exactly what they can do to the outside world, it's very clean.
- Vinnl 5y 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 5y 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)
- throwaway984393 5y 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.
  - Gigachad 5y 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..
    - throwaway984393 5y ago
      You can also check the CVE and see if it's critical (or if it even affects your application) and wait if it's not. Security literacy makes your life easier.
      - UncleMeat 5y ago
        This works for OSS code but not for all dependencies in general. That SDK or whatever you are using likely isn't getting CVEs filed on it.
- Gigachad 5y ago
  The maintainer needs to go to jail. They knowingly distributed malware.
- the42thdoctor 5y 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 5y ago
Previous discussion from a few days ago: https://news.ycombinator.com/item?id=30717382 https://news.ycombinator.com/item?id=30717382
kodah 5y 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-node-ipc-wipe-russia-belraus-computers https://www.vice.com/en/article/dypeek/open-source-sabotage-...
- tgv 5y 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 5y 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.
    - corobo 5y ago
      Presumably a person taking my belongings is doing so in person The difference is the possibility of actual bodily harm vs restoring a pc from a backup Also for the record no please don’t bust out the swat team for a burglar, bit much
      - behnamoh 5y ago
        How can you be sure that deleting files doesn’t put someone’s life in danger?
SodiumMerchant0 5y ago
rossmohax 5y ago
Other projects adopted non-malicious approach, where they publish anti war manifests: https://github.com/medikoo/es5-ext/blob/edf9fbac6c0d72a6192de7e0fbfb022eb34c3ac7/_postinstall.js https://github.com/medikoo/es5-ext/blob/edf9fbac6c0d72a6192d...
tentacleuno 5y 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%3Aissue+is%3Aclosed https://github.com/RIAEvangelist/node-ipc/issues?q=is%3Aissu... [1]: https://news.ycombinator.com/item?id=21400526 https://news.ycombinator.com/item?id=21400526 [2]: https://notepad-plus-plus.org/news/v833-make-apps-not-war/ https://notepad-plus-plus.org/news/v833-make-apps-not-war/
- jddil 5y 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.
  - ahelwer 5y 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.
lizardactivist 5y ago
davidmurdoch 5y 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 5y ago
  How did you accomplish this practically? using '=' in package.json + shrinkwrap or vendoring in dependencies?
  - davidmurdoch 5y 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 5y ago
  Do you regret using node/npm on such a high-risk installation?
  - davidmurdoch 5y ago
thenerdhead 5y 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?
- userbinator 5y ago
  I suspect it's just the fact that there are a lot more SJW types doing software than there used to be.
  - deleted 5y ago
    [deleted]
  - TobyTheDog123 5y 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.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
Artur96 5y 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.
deleted 5y ago
[deleted]
4oo4 5y 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 5y 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 5y 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.
inopinatus 5y 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/ http://dbad-license.org/ [2] https://github.com/RIAEvangelist/node-ipc/commit/9a1ad86d17af6343b144b2e8435d3d3318aa3503 https://github.com/RIAEvangelist/node-ipc/commit/9a1ad86d17a...

139 points by planb 5y 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?

kevinsundar 5y 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 5y ago
  But what happens when the latest version fixes a zero-day? Stay vulnerable for a week?
  - bastijn 5y ago
    In the hypothetical case all versions but the newest are vulnerable and the zero-day is also a problem in your specific deployment: manual tool validation is what should happen. Usually after a quick check if the package can be replaced easily.
- RKearney 5y 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?
  - kadoban 5y ago
    It's also about threat models, who you're trying to realistically protect yourself from. Some solo idiot with a political cause, not particularly targetting you? Waiting a week before using a new version is probably good enough. A government specifically targetting you? Likely nowhere near good enough. There's a lot in between of course.
  - 41b696ef1113 5y ago
    >...Walmart talk on Node.js and how they vet every single update to every single module... Most organizations are not as big as Walmart? However, if the Walmarts/FANGS/etc with huge mega teams would publish their audited versions, that would be something. However, that seems like a liability without any potential gain for the mega teams.
rosndo 5y 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.
- deleted 5y ago
  [deleted]
- bastijn 5y 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.
  - rosndo 5y 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. “FOSS developer” is hardly a career. Nobody is losing out on income by you blacklisting their projects.
    - ahelwer 5y ago
      Lots of FOSS developers support themselves with lucrative jobs or contracts they received on the basis of their reputation within the FOSS community (conference circuit, online forums, professional network, etc.) and otherwise mainly develop for the clout. Social consequences can be very effective in this way. It isn't quite like being blackballed but you really can't piss too many people off before those contracts start disappearing. Network effects work in reverse too.
ugh123 5y 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)
- kevinsundar 5y ago
  Waiting months means you don't get security fixes for months.
  - userbinator 5y ago
    It's known knowns vs unknown unknowns. I'd much rather have the former.
hughrr 5y 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 5y 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.
progval 5y 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 5y 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.
  - progval 5y ago
    > 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. Then you may need to reconsider using this kind of framework. If enough people do it, they may have to be more careful about what dependencies they have themselves.
    - Ekaros 5y ago
      It should have been clear from outset that pulling any number of transitive dependencies is horrible idea from security viewpoint. Ofc, it is fast and cheap in the moment... But, long term it clearly is not the best way.
Gravyness 5y 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.
- UncleMeat 5y 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.
  - mindri0t 5y ago
    This plus when a vulnerability is discovered and you are a million versions behind facing practically a ground up rewrite to get back to API compatible it is extremely hard to deal with. There is some balance to be had by waiting for things to become tested and stable rather than always defaulting to the bleeding edge, and maintaining a reasonable cadence of dependency management. You don’t always need to be on the latest version but you always need to be ready to be on the latest version
UncleMeat 5y 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 5y ago
  Also, don’t gitignore your node_modules directory.
jddil 5y 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.
- rsstack 5y 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.
- ahelwer 5y 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 https://www.theguardian.com/world/2002/nov/24/theobserver
  - filleduchaos 5y ago
    > And you cover this call to purposeless cruelty with emotional garbage about fathers burying daughters. On top of that, if there is anybody on the planet I would even entertain that kind of argument/"activism" from, it would definitely not be somebody from the US.
CJefferson 5y 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 5y 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.
  - fragmede 5y ago
    Never mind enforcement, getting people to pay for things in the first place is actually really hard. Just look at Docker. They only charge for companies with more than $10 million of revenue or greater than 250 employees, yet every time they come up, they're accused of rug-pulling, and few people actually want to pay them for saving them time. Or maybe it's just a vocal minority. At the other end of the enforcement spectrums is an enterprise-y place like Oracle and their army of lawyers. They may not be popular, but developer goodwill doesn't pay the bills, paying customers do. Sun never learned that lesson. At the end of the day, if it's useful enough, IT can make a hole in the firewall. Just look at Splunk.
freeqaz 5y 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 https://www.lunasec.io/docs/blog/node-ipc-protestware
- UncleMeat 5y 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.
  - moltke 5y ago
    I personally really like the way wasm modules work. The modules all have a particular interface so you know exactly what they can do to the outside world, it's very clean.
Vinnl 5y 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 5y 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)
throwaway984393 5y 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.
- Gigachad 5y 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..
  - throwaway984393 5y ago
    You can also check the CVE and see if it's critical (or if it even affects your application) and wait if it's not. Security literacy makes your life easier.
    - UncleMeat 5y ago
      This works for OSS code but not for all dependencies in general. That SDK or whatever you are using likely isn't getting CVEs filed on it.
Gigachad 5y ago
The maintainer needs to go to jail. They knowingly distributed malware.
the42thdoctor 5y 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 5y ago

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

kodah 5y 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-node-ipc-wipe-russia-belraus-computers https://www.vice.com/en/article/dypeek/open-source-sabotage-...

tgv 5y 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 5y 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.
  - corobo 5y ago
    Presumably a person taking my belongings is doing so in person The difference is the possibility of actual bodily harm vs restoring a pc from a backup Also for the record no please don’t bust out the swat team for a burglar, bit much
    - behnamoh 5y ago
      How can you be sure that deleting files doesn’t put someone’s life in danger?

SodiumMerchant0 5y ago

rossmohax 5y ago

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

tentacleuno 5y 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%3Aissue+is%3Aclosed https://github.com/RIAEvangelist/node-ipc/issues?q=is%3Aissu... [1]: https://news.ycombinator.com/item?id=21400526 https://news.ycombinator.com/item?id=21400526 [2]: https://notepad-plus-plus.org/news/v833-make-apps-not-war/ https://notepad-plus-plus.org/news/v833-make-apps-not-war/

jddil 5y 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.
- ahelwer 5y 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.

lizardactivist 5y ago

davidmurdoch 5y 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 5y ago
How did you accomplish this practically? using '=' in package.json + shrinkwrap or vendoring in dependencies?
- davidmurdoch 5y 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 5y ago
Do you regret using node/npm on such a high-risk installation?
- davidmurdoch 5y ago

thenerdhead 5y 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?

userbinator 5y ago
I suspect it's just the fact that there are a lot more SJW types doing software than there used to be.
- deleted 5y ago
  [deleted]
- TobyTheDog123 5y 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.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

Artur96 5y 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.

deleted 5y ago

[deleted]

4oo4 5y 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 5y 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 5y 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.

inopinatus 5y 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/ http://dbad-license.org/ [2] https://github.com/RIAEvangelist/node-ipc/commit/9a1ad86d17af6343b144b2e8435d3d3318aa3503 https://github.com/RIAEvangelist/node-ipc/commit/9a1ad86d17a...