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: 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."