Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Thursday May 03 2018, @03:35PM   Printer-friendly

Submitted via IRC for SoyCow8317

The Node Package Manager (npm) team avoided a disaster today when it discovered and blocked the distribution of a cleverly hidden backdoor mechanism inside a popular —albeit deprecated— JavaScript package.

The actual backdoor mechanism was found in "getcookies," a relatively newly created npm package (JavaScript library) for working with browser cookies.

The npm team —who analyzed this package earlier today after reports from the npm community— says "getcookies" contains a complex system for receiving commands from a remote attacker, who could target any JavaScript app that had incorporated this library. The npm team explains:

The backdoor worked by parsing the user-supplied HTTP request.headers, looking for specifically formatted data that provides three different commands to the backdoor. [...] We can see here that the headers are stringified and the result searched for values in the format of: gCOMMANDhDATAi

Source: https://www.bleepingcomputer.com/news/security/somebody-tried-to-hide-a-backdoor-in-a-popular-javascript-npm-package/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Thursday May 03 2018, @04:39PM (5 children)

    by Anonymous Coward on Thursday May 03 2018, @04:39PM (#675138)

    It is a different paradigm that has worked pretty well for the vast majority of projects. You could make the exact same accusations against Microsoft for all the backdoors they put in there, or any of the many linux packages people install without building from source after fully auditing the code of course.

    I don't like the NPM system myself, hell just to build a site theme often pulls in hundred of MB of node packages WTF? However, the idea was quite interesting and I hope a lot of devs are learning some valuable lessons now.

    The single lesson I truly hope people learn is to not use auto-building projects that rely on downloading dependencies. Bundle your software together into one package!! NO it IS NOT cool to have a single text file you can send someone which will build your program. It may seem cool up until the packages are not available, break some API call you relied on, or someone injects a backdoor and your stupid auto-update of packages opens the front door to the malicious repair man.

  • (Score: 2) by JNCF on Thursday May 03 2018, @06:21PM (4 children)

    by JNCF (4317) on Thursday May 03 2018, @06:21PM (#675201) Journal

    The single lesson I truly hope people learn is to not use auto-building projects that rely on downloading dependencies. Bundle your software together into one package!!

    So if I use two packages that rely on the same dependency at exactly the same version I need two copies of the dependency? That sounds efficient.

    NO it IS NOT cool to have a single text file you can send someone which will build your program. It may seem cool up until the packages are not available, break some API call you relied on, or someone injects a backdoor and your stupid auto-update of packages opens the front door to the malicious repair man.

    This is (part of) what versioning is for. I do think that it would be clever for our text files to optionally contain hashes of dependencies at their given versions, so that we can verify no meddling has taken place.

    • (Score: 0) by Anonymous Coward on Thursday May 03 2018, @07:17PM (1 child)

      by Anonymous Coward on Thursday May 03 2018, @07:17PM (#675250)

      We have this already in the form of yarn.lock and package.lock files

      • (Score: 3, Interesting) by JNCF on Thursday May 03 2018, @07:52PM

        by JNCF (4317) on Thursday May 03 2018, @07:52PM (#675271) Journal

        Good to see that npm adopted yarn's lock files! I like their JSON layout with hashes separated from file locations more than the yarn way of storing that data. I considered bringing up yarn, but I was worried it might be a bit off-topic since we're discussing issues arising from public repos. Yarn can solve your issues, or my issues, but not our issues.

    • (Score: 1, Informative) by Anonymous Coward on Thursday May 03 2018, @07:18PM (1 child)

      by Anonymous Coward on Thursday May 03 2018, @07:18PM (#675253)

      So if I use two packages that rely on the same dependency at exactly the same version I need two copies of the dependency? That sounds efficient.

      You spelled secure wrong.

      • (Score: 2) by JNCF on Thursday May 03 2018, @07:53PM

        by JNCF (4317) on Thursday May 03 2018, @07:53PM (#675272) Journal

        You ignored half my comment, or failed to read it.