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

Embedded Malware in Coa

github.com

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Embedded Malware in Coa

#71

Post by qwertox »

Kiro wrote: post #37
qwertox wrote: post #26

Earlier quoted context omitted.

I just can't agree with this. The problems npm has are not new, surprising ones. They are happily letting people upload malware. https://my.diffend.io/npm/coa/2.0.3/2.0.4/ In 2021, why on earth does such a change not trigger a review before release?

Trigger a review where and by who?

The receiving server would trigger it. The first review should be done by the owner, who should be contactable via email and authenticate via 2FA and acknowledge the modification.

Then I'd guess that Microsoft has enough information with NPM's history to train an AI. Specially the modifications made in these versions could easily trigger suspicious activity.

Did you look at the diffs?

Also, three years of inactivity and then a sudden upload should easily trigger a manual review, even if it is by automatically opening an issue with a review request on that project's GitHub page.

Re: Embedded Malware in Coa

#72

Post by dustyharddrive »

notpublic wrote: post #63
inbx0 wrote: post #48

Earlier quoted context omitted.

And to clarify, you should run this once by hand to collect the list, don't add the grepping to the actuall installation script or you are back to square one :D Here's what I use with yarn, install.sh: #!/usr/bin/env bash yarn function run_install() { local dependency="node_modules/$1" if [[ -d "$dependency" ]]; then yarn --cwd "$dependency" run postinstall fi } run_install 'esbuild' run_install 'other_package' ...

Good point and nice script. I am going to use it in my projects. I wish package.json had an option where I could explicitly mark which packages can run postinstall scripts.

> explicitly mark which packages can run postinstall scripts

Here's an RFC on exactly that: https://github.com/npm/rfcs/discussions/80

Re: Embedded Malware in Coa

#74

Post by jacques_chester »

salzig wrote: post #52
jacques_chester wrote: post #41

Earlier quoted context omitted.

I think NPM should consider flipping the default on this. Code that requires an install script should be the odd case that draws scrutiny.

or, cause enabled is the default right now, it's way easier to spot malicious packages right now?

I disagree. We don't know how many such packages run installation scripts without noticeably breaking.

Re: Embedded Malware in Coa

#76

Post by chakkepolja »

heurisko wrote: post #57
chakkepolja wrote: post #54

Earlier quoted context omitted.

I will be downvoted to hell for saying this. But javascript ecosystem is where most newbies come. (Low barrier to entry and it also seems hip). With no regards to security, maintainability or reliability, fashion chasing blog-happy hipsters. The amount of churn in JS ecosystem, security incidents like this and general crappiness of websites can be generally explained by how immature these hipsters are.

PHP has a similarly low barrier to entry, but doesn't seem to suffer as much as JS. Perhaps because dependencies are more curated in PHP due to clusters of dominant frameworks, rather than a proliferation of smaller libraries.

Not disagreeing with organization around frameworks in PHP, but apparently PHP suffered a lot from low barrier, in terms of security especially. That was the time package management wasn't that widespread yet, which IMO limited this kind of stuff. But there were, for sure, many applications where PHP could be blamed for security incidents and general unreliability. PHP improved quite well though.

Now PHP isn't hip anymore, node js is super popular hip thing, and every tom dick and harry from art school in US or 3rd tier engineering college in India will slap together three todo list applications on Resume and wants to call himself full stack developer. Internet is fast, hardware is fast, no one cares about pile of dependencies sitting beneath them.

Add to that resume driven development where every JS wants to write libraries and become github-famous. 30-line libraries will be considered a joke and it will be shameful to brag about such things in any other ecosystem.

Re: Embedded Malware in Coa

#78

Post by sanbor »

heurisko wrote: post #57
chakkepolja wrote: post #54

Earlier quoted context omitted.

I will be downvoted to hell for saying this. But javascript ecosystem is where most newbies come. (Low barrier to entry and it also seems hip). With no regards to security, maintainability or reliability, fashion chasing blog-happy hipsters. The amount of churn in JS ecosystem, security incidents like this and general crappiness of websites can be generally explained by how immature these hipsters are.

PHP has a similarly low barrier to entry, but doesn't seem to suffer as much as JS. Perhaps because dependencies are more curated in PHP due to clusters of dominant frameworks, rather than a proliferation of smaller libraries.

In 2019, 11% of all vulnerabilities listed by the National Vulnerability Database were linked to PHP; historically, about 30% of all vulnerabilities listed since 1996 in this database are linked to PHP. [1]

Also early this year there were news that git.php.net was compromised and a backdoor was introduced into PHP, but lucky enough the backdoor was catch before a production release.[2][3]

1: https://en.wikipedia.org/wiki/PHP#Security

2: https://arstechnica.com/gadgets/2021/03/hackers-backdoor-php...

3: https://flast101.github.io/php-8.1.0-dev-backdoor-rce/

Re: Embedded Malware in Coa

#79

Post by heurisko »

sanbor wrote: post #78
heurisko wrote: post #57

Earlier quoted context omitted.

PHP has a similarly low barrier to entry, but doesn't seem to suffer as much as JS. Perhaps because dependencies are more curated in PHP due to clusters of dominant frameworks, rather than a proliferation of smaller libraries.

In 2019, 11% of all vulnerabilities listed by the National Vulnerability Database were linked to PHP; historically, about 30% of all vulnerabilities listed since 1996 in this database are linked to PHP. [1] Also early this year there were news that git.php.net was compromised and a backdoor was introduced into PHP, but lucky enough the backdoor was catch before a production release.[2][3] 1: https://en.wikipedia.org/…

I was referring to security issues regarding dependency management.

The git.php.net server was also not compromised, as far as I know, from a PHP vulnerability that was active at the time.

Re: Embedded Malware in Coa

#80

Post by heurisko »

chakkepolja wrote: post #76
heurisko wrote: post #57

Earlier quoted context omitted.

PHP has a similarly low barrier to entry, but doesn't seem to suffer as much as JS. Perhaps because dependencies are more curated in PHP due to clusters of dominant frameworks, rather than a proliferation of smaller libraries.

Not disagreeing with organization around frameworks in PHP, but apparently PHP suffered a lot from low barrier, in terms of security especially. That was the time package management wasn't that widespread yet, which IMO limited this kind of stuff. But there were, for sure, many applications where PHP could be blamed for security incidents and general unreliability. PHP improved quite well though. Now PHP isn't hip an…

I was also thinking that the "blast radius" for PHP was lower, as there wasn't the same culture around creating packages.

Until composer, there wasn't much of a culture around creating packages full stop, apart from PEAR, which beginners didn't create packages for.

Post reply on HN