Live data from Hacker News

Npm install could be dangerous

github.com

81–90 of 100 posts

Re: Npm install could be dangerous

#81
post #7

This applies to pretty much every pkg manager ever created. That's why it's important to have end-to-end package signing with a reasonable UI, so people can choose to selectively trust the sources they need and get alerted before new dependencies get pulled in. Sadly I don't know of any pkg manager that implements this correctly.

I find the apt package model to be very good (add trusted keys & repositories explicitly). What do you see as the shortcomings of apt compared to your ideal?

Yes, apt is indeed one of the best we have (the one-eyed amongst the blind).

Sadly it's still using a flawed[1] trust model where you trust repositories rather than publishers. And the UI-shim over GnuPG is 'basic' at best (to put it politely).

To add insult to injury deb/dpkg itself actually does contain a mechanism for package-level signing. But as far as I know no distro is using it.

To add even more insult to injury, all mobile platforms and both Windows and OSX have more reasonable package security models than Linux today.

[1] This is fine for guarding against compromised mirrors - and not much else.

Re: Npm install could be dangerous

#82
post #20

npmjs still contains the package: https://www.npmjs.com/search?q=rimrafall https://www.npmjs.com/package/rimrafall '0 downloads in the last month' There is no 'report package' button. The support link goes to a 'we are hiring' contact form. Report bad packages as security issues? https://www.npmjs.com/security Package signing. Review process. Scanning tools for dangerous packages. As a user, don't trust anything and…

"Scanning tools for dangerous packages" This seems like an impossible problem (essentially the halting problem). On Linux perhaps you could build packages in a container then copy the results to the installation directory, but there's no guarantee require("rimrafall") won't just "child_process.exec('rm -rf /')".

At the very least, they could install packages in a VM and check that the VM can be rebooted.

Re: Npm install could be dangerous

#83
post #78

Earlier quoted context omitted.

Yep. RFC2606 It is what they should use. And if you need to specify 2 hosts, you can use example.net and .org as well. Unfortunately, the example domains don't convey context very well, so we see things like target.com, victim.com, etc

This can be corrected by target.example.com and victim.example.com. Conveys the context while remaining safe as an example.

That generally works, although in some cases it makes a difference whether two hosts are on the same tld; at the very least, it implies a connection between the two that may not always make sense (why is aggressor.example.com attacking victim.example.com?).

Re: Npm install could be dangerous

#85
post #42
post #20

npmjs still contains the package: https://www.npmjs.com/search?q=rimrafall https://www.npmjs.com/package/rimrafall '0 downloads in the last month' There is no 'report package' button. The support link goes to a 'we are hiring' contact form. Report bad packages as security issues? https://www.npmjs.com/security Package signing. Review process. Scanning tools for dangerous packages. As a user, don't trust anything and…

I had the same thing - they have an abuse@ email in the Code of Conduct link that appears on every page. The email is the first thing listed. I've contacted them.

The package has now been removed.

Re: Npm install could be dangerous

#86
It's always been amateur hour over there. The 'official' install was `curl http://npmjs.org/install.sh | sh`[1], package checksums aren't uniformly checked, the list goes on.

But don't worry guys, they had a security audit[2].

[1] http://web.archive.org/web/20101228041356/http://npmjs.org/ [2] http://blog.npmjs.org/post/80277229932/newly-paranoid-mainta...

Re: Npm install could be dangerous

#87
post #80
post #49

Earlier quoted context omitted.

Any site that serves up content that will be interpreted by `sh`. Meaning, what happens if someone decides they want you to lose your home directory? They serve up the content "rm -rf ~". That doesn't even require privilege escalation, but it might ruin your day.

Let me rephrase: Is dangerous.com a website with fame for such trick or it's just a name example?

It's a name example.

Re: Npm install could be dangerous

#88

Earlier quoted context omitted.

"Scanning tools for dangerous packages" This seems like an impossible problem (essentially the halting problem). On Linux perhaps you could build packages in a container then copy the results to the installation directory, but there's no guarantee require("rimrafall") won't just "child_process.exec('rm -rf /')".

At the very least, they could install packages in a VM and check that the VM can be rebooted.

Then someone could just craft a package that deletes every file except the ones required for booting...

Re: Npm install could be dangerous

#89
post #81

Earlier quoted context omitted.

I find the apt package model to be very good (add trusted keys & repositories explicitly). What do you see as the shortcomings of apt compared to your ideal?

Yes, apt is indeed one of the best we have (the one-eyed amongst the blind). Sadly it's still using a flawed[1] trust model where you trust repositories rather than publishers. And the UI-shim over GnuPG is 'basic' at best (to put it politely). To add insult to injury deb/dpkg itself actually does contain a mechanism for package-level signing. But as far as I know no distro is using it. To add even more insult to inj…

The signing used by pacman (on arch) seems relatively nice, in that individual packages are signed by the maintainer rather than the repository.

Whether or not this buys you any extra security, I'm not sure. In reality I don't think many users check maintainer keys when asked if they want to trust them, but they could.

Re: Npm install could be dangerous

#90

Earlier quoted context omitted.

How would it catch something like cp /bin/rm ponies ; ./ponies -rf /

The same way checkinstall detects which files have been installed - it overrides the relevant syscalls when running the program/script: http://asic-linux.com.mx/~izto/checkinstall/installwatch.htm... Of course, not everything is as obvious to detect as deleting files :)

Well, checkinstall acts at the dynamic linking level. If you use ASM to call the syscall directly (or more generally, a statically linked binary) then checkinstall will not even see it (strace/DTrace/ktrace would.)
Post reply on HN