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
(Score: 2, Insightful) by Anonymous Coward on Thursday May 03 2018, @04:15PM (16 children)
This is just another symptom of the wider problem. Remember leftpad? That was the same thing:
People don't think about building software anymore, they just glue stuff together without fully understanding anything. npm makes this even worse because it's so "easy" to pull in a dependency and it hides the secondary, tertiary, ..., n-ary dependencies.
Unless you know what is in your software, you cannot make any, ANY statements about whether it works or not.
I'm sure other environments have similar problems (has anyone done an audit on pip or homebrew?) but the javascript 'ecosystem' seems very prone to these kinds of problems because the people operating in it are nitwits.
(Score: 0) by Anonymous Coward on Thursday May 03 2018, @04:39PM (5 children)
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)
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.
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)
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
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)
You spelled secure wrong.
(Score: 2) by JNCF on Thursday May 03 2018, @07:53PM
You ignored half my comment, or failed to read it.
(Score: 2) by bob_super on Thursday May 03 2018, @05:18PM (1 child)
> just glue stuff together without fully understanding anything
They keep forgetting to add the train and audit tasks in the Sprint.
(Score: 2) by Freeman on Thursday May 03 2018, @05:43PM
There's no A in SPRINT (Some Program Rapidly Integrated No Takebacks). They just got a couple words wrong in their Agile development process.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 1, Interesting) by Anonymous Coward on Thursday May 03 2018, @05:43PM
Your comment is very timely: https://xkcd.com/1988/ [xkcd.com]
(Score: 2) by DannyB on Thursday May 03 2018, @06:12PM
It is probably only fair to also mention various Java package and build systems.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Insightful) by DannyB on Thursday May 03 2018, @06:14PM (2 children)
You are talking about using pre-built software libraries, packages, etc.
Your statement is equally true of the fact that many people today don't really know how to think. Don't understand the software. They just search the intarweb-tubes and copy/paste code into the project until it seems like it works. At least until it passes the tests.
And hied insultants only care that it works until their contract is paid.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Thursday May 03 2018, @07:08PM
And full time employees only care that it works until they get a new job or retire.
(Score: 2) by Bot on Thursday May 03 2018, @07:50PM
> "consultants" autocorrected to "insultants"
good news everybody, skynet is alive.
Account abandoned.
(Score: 4, Informative) by JNCF on Thursday May 03 2018, @06:46PM (2 children)
The leftpad debacle was different. NPM revoked a package author's namespace to give it to a corporation, and the author pulled the rest of his packages (including leftpad) from NPM in protest. Two things could have been done to prevent this:
1) Don't let anybody other than the owner of a namespace change ownership of that namespace (thus solving the political problem).
2) Don't let anybody, including the owner of a namespace, change already published versions of a package.
By contrast, backdoors in packages are a more fundamental problem with using other people's code. There is currently no substitution for vetting dependencies.
Of course I can. All statements must be at least implicitly probabilistic -- only a Sith deals in absolutes -- but if I run tests on a piece of code 1000 times, and it always gives the same expected output for a given input, I can say with a pretty high level of certainty that it works for that input. If a lot of people are using it, and there are bug reports covering known edge cases where it doesn't work, and people discussing the inner workings of it, and the parts of the code I dig into seem reasonable, I can say with some certainty that it probably works for the cases it was clearly intended to work with. There are only probablies, friend.
Do you ever write software that relies on code you haven't read every line of? Think carefully before answering that one.
(Score: 0) by Anonymous Coward on Friday May 04 2018, @11:49AM (1 child)
I'm not the GP but I want to jump in and defend, I feel like JNCF is oblivious to agreeing with GP.
GPAC >> Unless you know what is in your software
JNCF > Of course I can. ...1000 times, and it always gives the same expected output
right, one way to know something is empirically.
JNCF > Do you ever write software that relies on code you haven't read every line of? Think carefully before answering that one.
What? The GP never claimed to know. If anything the claim was it's unknowable, or knowable only hazily, as you yourself also say...
(Score: 2) by JNCF on Friday May 04 2018, @12:50PM
There are many ways to write a program that gives the same output a thousand times, and knowing the output does not mean I know what is in the software. In fact, I shouldn't have to know what is in the software if I believe in the competency of the maintainer. The maintainer of a package should be able to change the inner workings, say to make it more efficient, without breaking my use of their interface.
Note that OP uses not only the phrase "unless you know what is in your software," but also speaks of "fully understanding." Maybe I'm just being a literalist pedant, but I don't think OP has thought out their position on this subject very deeply. I think that a little bit of self-examination should prompt OP to reevaluate whether or not fully understanding complex software and knowing what is inside of it is even an obtainable goal. We don't always walk how we talk, and as the end of my post made clear, I doubt OP lives up to the standards stated.
I think you're projecting your views onto OP. OP literally says "fully understanding."