Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Open Source

Node.js Event-Stream Hack Reveals Open Source 'Developer Infrastructure' Exploit (arstechnica.com) 82

"[O]n Nov. 26 it was publicly revealed that a widely deployed open-source Node.js programming language module known as event-stream had been injected with malicious code that looked to steal cryptocurrency wallets," reports eWeek, adding "The event-stream library has over two million downloads."

An anonymous reader quotes Ars Technica: The backdoor came to light [November 20th] with this report from Github user Ayrton Sparling. Officials with the NPM, the open source project manager that hosted event-stream, didn't issue an advisory until six days later.... "This compromise was not targeting module developers in general or really even developers," an NPM official told Ars in an email. "It targeted a select few developers at a company, Copay, that had a very specific development environment set up. Even then, the payload itself didn't run on those developers' computers; rather, it would be packaged into a consumer-facing app when the developers built a release. The goal was to steal Bitcoin from this application's end users...."

According to the Github discussion that exposed the backdoor, the longtime event-stream developer no longer had time to provide updates. So several months ago, he accepted the help of an unknown developer. The new developer took care to keep the backdoor from being discovered. Besides being gradually implemented in stages, it also narrowly targeted only the Copay wallet app. The malicious code was also hard to spot because the flatmap-stream module was encrypted. The attack is the latest to exploit weaknesses in a widely used supply chain to target downstream end users... The supply-chain attacks show one of the weaknesses of open source code. Because of its openness and the lack of funds of many of its hobbyist developers and users, open source code can be subject to malicious modifications that often escape notice.

"The time has come," concludes Ars Technica, "for maintainers and users of open source software to devise new measures to better police the millions of packages being used all around us." Sophos' security blog also asks why so many developers "immediately and blindly trusted the new maintainer," and shared a concerned comment from developer named Chris Northwood.

"Nothing's stopping this happening again, and it's terrifying."
This discussion has been archived. No new comments can be posted.

Node.js Event-Stream Hack Reveals Open Source 'Developer Infrastructure' Exploit

Comments Filter:
  • Many eyes (Score:3, Insightful)

    by Anonymous Coward on Saturday December 01, 2018 @06:24PM (#57733380)

    Many eyes mean nothing if they aren't looking.

  • by phantomfive ( 622387 ) on Saturday December 01, 2018 @06:27PM (#57733388) Journal
    Good thing they used a safe language like Javascript so exploits can't happen.
    • Javascript as a server language.

      If you said that 10 years ago, people would've looked you like you just said that the president ... bad example.

    • Re:Good thing (Score:5, Insightful)

      by AuMatar ( 183847 ) on Saturday December 01, 2018 @07:02PM (#57733496)

      Language had nothing to do with it. This could have occurred in any language. Its the culture of using random libraries found off the web without doing security audits that's the culprit.

      • It's often the case where something is included into an application without the long view... If you are on a two week sprint, and need it done, including a functioning component is the easy answer. Two, or Three years later the person who made that selection is long gone. In this case it was the "worst-case-scenario", a library that was on the verge of being abandoned rescued by a nefarious helper. THIS IS JUST ONE OF MANY...
  • by El Cubano ( 631386 ) on Saturday December 01, 2018 @06:33PM (#57733410)

    The supply-chain attacks show one of the weaknesses of open source code. Because of its openness and the lack of funds of many of its hobbyist developers and users, open source code can be subject to malicious modifications that often escape notice.

    Every time I read something like this I have to imagine it was written by someone who works for or owns stock in one of those companies that produces "compliance" tools/services targeted at businesses that use open source.

    I mean, come on. This exact same problem exists for closed source software. Face it, you know about as much about the developers of any random closed source application or library as you do about any random open source application or library. In fact, it is less likely that a malicious change will be discovered if you do not have access to the source code.

    • by Anonymous Coward

      I believe that the grandparent was on to something. If you think about how Node.js and other javascript framework libraries work, they're frequently configured to pull the latest updates for all of their dependencies and the dependencies of those dependencies and so on. You can imagine this as a large tree of dependencies with many sub-trees. Furthermore, because Node.js pulls in many "utility" and other libraries either directly or indirectly, and many utility libraries are maintained by a small group of d

    • by sad_ ( 7868 )

      indeed, in every argument against open source software, the same argument can always be used against proprietary software too.

  • by Anonymous Coward

    A sure sign that development is being taken over by normies and retards

    • by Opportunist ( 166417 ) on Saturday December 01, 2018 @06:55PM (#57733484)

      The main problem with node starts way earlier. First, 100 packages doing the same. Well, not really. Just kinda. Say you need a package that deals with a certain database. You'll find 5. And no matter which one you eventually choose randomly (because asking google is like asking a bunch of /. users which Linux distri to get, you'll get 5 answers telling you the merits of 6 different solutions), it will be the one that you eventually realize doesn't have that one crucial feature you actually needed, won't play nice with whatever other middleware you have to use or has simply not been updated for 2 years because whoever wrote it lost interest.

      Which leads to the next thing: Abandoned packages. Most of those solutions depend on a single maintainer. And his whims. When he doesn't feel like maintaining it anymore, poof. Try to maintain that code now that some crucial part of it simply isn't updated anymore, the technology it communicated with did move on and becomes incompatible and you're SOL.

      I mean, I get it, it's a toy for people who learned web design, can't be assed to learn a real language and also want to do shit with servers. Ok. But ... seriously, python is not THAT hard...

      • by Anonymous Coward

        I love Python, even though I only used it to work with Zope.

        But Python, AFAIK, does not offer the same full stack tool chains now available via JS.

        JS has become PHP, except with even fewer obstacles to keep people from getting in way over their head.

        I suspect that if Python were as accommodating, the state of Python would plummet as well. The problem isnâ(TM)t the language, the problem is that there are too many people programming who do not have the wisdom or experience to do it competently.

        That, and

        • The problem is people making packages that have no business doing so. Half of them are sorta-kinda working with glaring security holes that make even newbie programmers cringe.

      • It's not a language problem - it's an economic problem. There's no money in being an open source developer. I suspect more than 50% of packages on NPM are de facto abandoned.

        The old model for FOSS development went like this: write some Free Software that many people use. Build up you cred as a developer. Land sweet consulting gigs and collect big bucks.

        But that model has failed. Companies (for the most part) don't care what software you wrote. All they care about is price. So now a developer can waste a bu

        • by Opportunist ( 166417 ) on Sunday December 02, 2018 @05:55AM (#57735508)

          This is actually a language problem in a roundabout way.

          I've been wondering who on earth thought that javascript, of all the available languages on the planet, would be a good choice for a server language. Then it hit me: Nobody thought it would be a good language, but we have a shitload of unemployed frontend developers that have zero experience with anything BUT javascript. And the same cheap bastard companies that went and hired the so-so skilled, self-taught frontend devs during the high times of the dot.com boom now hire exactly the same people for backend development.

          These people have been bullshitted the first time when everyone was doing stuff "on the internet" and got rich (well... kinda...) off it that this is the next big thing, now they get bullshitted into believing that they get rich developing backend stuff. In the end, in both cases what you're dealing with is cheap companies trying to cash in by jumping the bandwagon of whatever is the hot cake in IT with the cheapest personnel they can get.

          Of course you can't land a nice consulting job in such an environment. These people that hire the same code monkeys they hired before for frontend won't hire you for consulting for the same reason: They want cheap, not good.

          It still works quite fine with other Open Source projects, and you'll notice that the key OSS-products have very active and fairly well doing developers, just not in node.js.

        • Possibly Tidelift [tidelift.com]?

          Whether Tidelift will "fly" (cringing at metaphor mixing), I have no idea....

  • by L_R_Shaw ( 5544684 ) on Saturday December 01, 2018 @06:44PM (#57733450)

    Thank god WebAssembly is rapidly advancing with the fever of someone trapped in an elevator with fat guy who ate nothing but beans for lunch and the entire clusterfuck that is Javascript/Node is about to be dumped on the garbage heap of dead tech.

    • Yeah, Javascript kind of sucks unless its used by the same team all the time and they can keep the code bug free. Random Javascript on a new project or occassional/sudden use/transition to Javascript? That's a nightmare waiting to happen.
    • by anss123 ( 985305 )

      These sorts of attacks have been conducted against more than just NPM.

      Meanwhile Javascript is getting more popular, not less, to the extent is had started to to challenge other languages outside the safety of the browser. Not at all the sign of a dying language, IOW WebAssembly may end up having less impact than you think.

      • You poor stockholm syndrome suffering bastard.

        • by anss123 ( 985305 )

          I'm not poor, and I've done most of my programming in other languages.

          That does not change the fact that Javascript is going from strength to strength. You may not like it, but that doesn't mean it is dying.

  • by Anonymous Coward on Saturday December 01, 2018 @07:13PM (#57733536)

    This problem is far more prevalent in certain language communities, most notably JavaScript (but there are others). Communities where, to put it bluntly, most developers don't understand or care how their stack works, they just toss another dependency on the giant pile and fetch the newest version from github every time they build and deploy. Communities where it's considered normal to install something by piping a wget into a root shell. Without even pausing to think, they automatically cargo-cult the first monkeyman who touched the monolith and wrote a library.

    Here's a pro tip, kids: don't add dependencies you don't need (and you probably don't). But if you have to, import them into your local source tree so that you have a predictable, reliable build that's also resilient against github going down. Unless you just enjoy being fucked unpredictably by a thousand possible events outside your control.

    • by sjames ( 1099 )

      I have seen what should have been static pages with a form use javascript to generate the HTML for absolutely no good reason. This is nothing more or less than people who have no clue what they're doing.

  • by Anonymous Coward

    This is what happens when you BLINDLY use another persons code without looking at it once.
    If you yourself cannot understand the code of others, don't fucking use it, it will bite you in the ass.
    If it has barely any contributors, or even one, trust it even less so!
    I don't care who the person claims to be, or if they were even a deity in human form, their code ain't going on any of my systems, no way.
    And if any sudden changes just came out of the blue for no reason other than chaaaaange, it can go to 10 kinds

  • The dare devil driver jumps in the car, rips the mirror out, and screams "I don't need it! What's behind me is of no concern!"

    Move Fast! Break Things! Disrupt!!!

    gack

    • Gumball Rally (1976)

      Franco: And now my friend, the first-a rule of Italian driving.
      [Franco rips off his rear-view mirror and throws it out of the car]
      Franco: What's-a behind me is not important.
      • Yea, I was trying to avoid the all too sensitive reference. I'm tired of getting yelled at this week.

  • by ffkom ( 3519199 ) on Saturday December 01, 2018 @08:26PM (#57733852)
    what could possibly go wrong? The ridiculously oversized dependency-trees of node.js software, along with the lack of any decent web-of-trust structure backed by cryptographic signatures, makes this a "will happen again and again" event.

    Before irresponsible "programmers" started to include even 5-lines-of-code snippets from unknown authors from the Internet, it was common sense to only depend on sizeable libraries of significant complexity, and only a few of them.

    With the insane fragmentation of node.js code, there is no chance anyone can reasonably rule out that parts of that code come from an adversary.
  • The malicious code was also hard to spot because the flatmap-stream module was encrypted.

    What does this mean?

  • "The malicious code was also hard to spot because the flatmap-stream module was encrypted."
    Seems like a problem here is the code was not in fact by any rational definition, "open".

The most important early product on the way to developing a good product is an imperfect version.

Working...