Hacker News Reader

Comment by Jupe | Hacker News Reader

The fact that this is the top-voted item here scares the hell out of me.

eval() should be removed from the language. Period. Dynamic code like this is a gaping security hole. There an infinite number of ways to get around eval() detection (see some comments below).

eval() combined with a hole-ridden package manager is the perfect storm; the equivalent of an open door for hackers to manipulate a potentially huge number of code bases.

And the top-voted comment is how they used a stats counter to stuff the hijacked creds... WTF.

View on HN

Removing eval wouldn't help— you could always just write a tiny interpreter to do the same thing. This is a problem in any Turing complete programming language (with Reflection), although JS makes it easier.

True, it wouldn't solve the problem entirely, but I'd guess a 'tiny' interpreter would stand out more than a one liner like this one, possibly making detection easier.

On the contrary, `eval` is used so little in real code that it's easy to detect. A tiny, obfuscated VM would be much more difficult.

‘eval’ is not trivial to detect when it’s

window[rot13("riny")]("console.log('lol')");

or one of the many other ways to obfuscate eval

Removing eval doesn't fix anything here. In fact you can eval in other methods in JS (setTimeout and setInterval).

I think this issue is a good reminder that installing thousands of dependencies for a hello world app is dangerous and could ultimately be very costly. We need to handle modules better.

> I think this issue is a good reminder that installing thousands of dependencies for a hello world app is dangerous You are obviously making an embellishment, but even if you only install 10 dependencies for a large app, the same problem exists.

If you don't have the resources to security+quality vet every single module in the entire dependency graph of your project, you will be susceptible to the same issue.

The problem lies in the fact that modern development requires that you trust unlicensed strangers to write code for your supply chain. You don't authenticate them and the extent of authorization is just that you choose their library over all of the alternatives.

Edit: I realize after writing this that it sounds like I'm apologizing for _npm_'s basic security mistakes. I recognize they exist, but I'm trying to highlight that this isn't really a solved issue for other package managers, even though many of them have solved the basic security hygiene that npm hasn't.

> The problem lies in the fact that modern development requires that you trust unlicensed strangers to write code for your supply chain

Yup, I agree but I think npm makes this issue significantly worse than any other package manager. In most languages you can download a few packages to add the necessary functionality you're looking for and sometimes they include additional dependencies but it usually isn't very many (at least in my experience).

But node / npm? Good luck installing some basic setup for webpack or other common frameworks and _not_ find yourself installing 1,000+ packages.

I don't know exactly _why_ it's like this but there are a large amount of entries for getting malicious code into an application nowadays and with JavaScript running on almost everything it's hard to imagine this not happening to something that could cause a major disruption.

When I did work for the DoD in one specific agency you couldn't just include any npm module. You had to go through a list of approved modules and versions. Then if you requested a version update or a new module it had to be reviewed by a security team before being included. Granted this won't find everything but this is a well understood issue that many in the government are well aware of and I wonder when the private sector is going to come up with their own, hopefully better, solution.

> You had to go through a list of approved modules and versions.

I was actually talking about this with coworkers at lunch.

I think this is too expensive for individual developers/small companies, but there's really nothing stopping a wider open source community from marking specific modules+versions as more likely to be secure.

I think there should be some opt-in system for objectively predicting code quality and developer/maintainer opsec. Apply some rubric for {secure programing techniques, static+dynamic analysis, CI deploy toolchain, basic security hygiene of the developers} and recursively apply it to the upstream dependencies. Display the score according to that rubric on the project page -- this would be far more useful of a metric than "number of downloads" or "I used it at my last company".

It doesn't protect against malicious insiders, but not having a high score could act like the "Scarlett Letter" we need for low quality repo-modules.

Everyone gives C's library distribution model shit, but at the end of the day installing through a distribution's repos is still much more secure than the alternatives.

You can do that for javascript too, but you'll be getting older versions of everything. That will also be true if you're using a C package under active development. Distros, by design, aren't as quick to update as npm.

Reply on news.ycombinator.com