Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious crossenv package on npm

twitter.com

Post reply on HN
Print view View original

61–70 of 237 posts

Re: Malicious crossenv package on npm

#61

Post by [deleted] »

KirinDave wrote: post #42
danjoc wrote: post #31

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shas…

> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. But they're right. What exactly would PKI do here? Someone is generating confusion. You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM…

[deleted]

Re: Malicious crossenv package on npm

#62

Post by KirinDave »

slackingoff2017 wrote: post #56
KirinDave wrote: post #42

Earlier quoted context omitted.

> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. But they're right. What exactly would PKI do here? Someone is generating confusion. You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM…

Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access…

Maybe I just don't understand, so could you explain to me how gpg signatures actually fix this problem? Would they fix this problem for npm?

I'm asking about the specific attack detailed in the tweet.

Re: Malicious crossenv package on npm

#64

Post by skywhopper »

danjoc wrote: post #31

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shas…

I agree that npm et al should support code signing but genuine question: how would package signing solve this particular issue? This was not a code integrity attack. Presumably the author of the malicious package can sign his code as well. I suspect if the malicious author had made the package proxy the desired package's exports it would have been a lot longer before this was noticed if it ever was.

Re: Malicious crossenv package on npm

#65

Post by jnbiche »

iamakulov wrote: post #41
danjoc wrote: post #31

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shas…

npm is working on a solution for misspellings through: https://twitter.com/maybekatz/status/892501201551368192

They should first get package signatures implemented, it's a bigger threat to the npm community. At worst, the mispelled packages effect a handful of people who don't double check the package name for the package they're installing. If someone compromises the integrity of an ultra popular package, it threatens thousands, perhaps even millions of people (counting all people consuming the code downstream, ie users). And the npm repo has been shown to be vulnerable to compromise multiple times over the past few years. Here's a writeup of just some of the more egregious security weaknesses of NPM packages in recent history: https://www.bleepingcomputer.com/news/security/52-percent-of...

Re: Malicious crossenv package on npm

#66

Post by chii »

detaro wrote: post #58
slackingoff2017 wrote: post #56

Earlier quoted context omitted.

Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access…

How does "You need my private key to sign the cross-env package" stop someone from creating a "crossenv" package? What does the specific workflow look like that makes sure I don't add the wrong thing to my project?

It doesn't. They's not the problem being solved by signing. In all likelihood, if an end user got socially engineered to download the wrong package, there's very little to be done. Perhaps the install process can do a search and display similarly named packages, and the users could be more alert to irregularly named ones?

Re: Malicious crossenv package on npm

#67

Post by skywhopper »

slackingoff2017 wrote: post #56
KirinDave wrote: post #42

Earlier quoted context omitted.

> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. But they're right. What exactly would PKI do here? Someone is generating confusion. You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM…

Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access…

I'm guessing maven feels safer because its packages must be compiled against a specific interface and few if any execute any code during setup. Maven is rarely if ever used to install interactive tools like npm very often is. Maven is not a reasonable analog here.

Re: Malicious crossenv package on npm

#68

Post by derefr »

skywhopper wrote: post #64
danjoc wrote: post #31

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shas…

I agree that npm et al should support code signing but genuine question: how would package signing solve this particular issue? This was not a code integrity attack. Presumably the author of the malicious package can sign his code as well. I suspect if the malicious author had made the package proxy the desired package's exports it would have been a lot longer before this was noticed if it ever was.

The usual way code-signing is used here is that code for a platform is signed with keys issued by the platform manager acting as a CA, who does identity verification at time of issuance. Thus, if the platform-as-CA revokes someone's code-signing cert, they're effectively banning that person (rather than just that pseudonymous identity) from ever publishing on their platform again.

It not only works after-the-fact, but is usually also quite effective as a deterrent to stop people from publishing malware in the first place (except state-level actors who can afford to create and burn real identities for the sake of cyberwar.)

Re: Malicious crossenv package on npm

#69

Post by KirinDave »

chii wrote: post #66
detaro wrote: post #58

Earlier quoted context omitted.

How does "You need my private key to sign the cross-env package" stop someone from creating a "crossenv" package? What does the specific workflow look like that makes sure I don't add the wrong thing to my project?

It doesn't. They's not the problem being solved by signing. In all likelihood, if an end user got socially engineered to download the wrong package, there's very little to be done. Perhaps the install process can do a search and display similarly named packages, and the users could be more alert to irregularly named ones?

What's to be done is remove the package and try and dox the perpetrator to kingdom come, in hopes that law enforcement and social reputation can make an example of of them.

Re: Malicious crossenv package on npm

#70

Post by Chyzwar »

tedunangst wrote: post #32
eropple wrote: post #18

Earlier quoted context omitted.

Your QA teams are looking up every entry in your package.json files, your Maven poms, your Gemfiles, your requirements.txt files? They're making sure that something that builds completely cleanly and shows no external errors doesn't have a typo in it? Of course they're not.

My QA team, upon a request to add a package called "crossenv" to the npm repo, would say "this is suspiciously similar to the existing cross-env package. Request denied." Alas, npm has no such team.

npm host half a million packages. It is impossible to manually QA anything. People also rename and re-publish unmaintained packages pretty often.

The problem is JS that lack sensible standard library. Node is at fault.

Post reply on HN