8 ms·

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 g

• 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.