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

41–50 of 86 posts

Re: Embedded Malware in Coa

#41

Post by jacques_chester »

inbx0 wrote: post #34

Reminder that people should seriously consider disabling the install-scripts. Personal system-wide config: npm/yarn config set ignore-scripts true -g and add & commit a .npmrc/.yarnrc file with ignore-scripts true Yes, this will cause headaches in some (increasingly rare) cases where some package actually needs those scripts. You can fix this with custom install scripts that take care of running install for those spe…

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

Re: Embedded Malware in Coa

#42

Post by jacques_chester »

peanut_worm wrote: post #39

Why can’t there just be multiple curated repositories like how Linux distros do it? Having NPM just be a free-for-all is a ticking time bomb. It is only a matter of time before an event like this results in something very serious.

Scale, basically. There are too many packages to fully curate.

Re: Embedded Malware in Coa

#43

Post by avereveard »

Kiro wrote: post #36
0xdeadb00f wrote: post #25

Earlier quoted context omitted.

This is a really odd comment. Npm, and the strange, insecure JavaScript packaging ecosystem is the reason this happened in the first place.

What makes npm more insecure than other packaging systems?

authors cannot revoke their compromised keys to immediately halt all distribution, and you don't have any process to verify packageauthor ownership beyond the upload secrets.

Re: Embedded Malware in Coa

#44

Post by notpublic »

inbx0 wrote: post #34

Reminder that people should seriously consider disabling the install-scripts. Personal system-wide config: npm/yarn config set ignore-scripts true -g and add & commit a .npmrc/.yarnrc file with ignore-scripts true Yes, this will cause headaches in some (increasingly rare) cases where some package actually needs those scripts. You can fix this with custom install scripts that take care of running install for those spe…

You can find out which packages require postinstall scripts and then run them manually:

  $ grep postinstall node_modules/*/package.json
  node_modules/esbuild/package.json:    "postinstall": "node install.js"
  $ cd node_modules/esbuild
  $ npm run postinstall

Re: Embedded Malware in Coa

#45

Post by r6203 »

Are other languages/runtimes also that risky as Node with npm?

npm packages seem like a cardhouse.

I know that the node_modules folder is often times criticized for its sheer amount of 3rd party libraries. Is it because of JavaScripts "missing" standard library?

Re: Embedded Malware in Coa

#46

Post by Ginden »

loa44hh100 wrote: post #30

This makes me appreciate Deno's focus on security. Having things like file and network access 'opt in' seems like a no brainer when we see how easy it is to simply install an npm package and find yourself vulnerable to malware.

Any protection offered by Deno isn't robust. Only OS-level protection is secure. Any tooling will require access to file system - and file system access is enough to compromise developer system.

Let's assume that you have Deno compiler for other language. You run it through seemingly innocent deno run "https://..." --allow-write=. src/ (you use optional parameter to --allow-write, right?).

Unfortunately, webpage hosting script was compromised. Now our compiler can write to .git/hooks, .npmrc (npm can do arbitrary script execution in version 6 or lower, even on npm --version), .idea/ etc.

Re: Embedded Malware in Coa

#47

Post by __void »

cloudbonsai wrote: post #15

For anyone interested, the malicious code can be found in the following link: https://github.com/veged/coa/issues/99#issuecomment-96153687... TLDR: The attacker injected an attack code as coa's `preinstall` script, which executes an obscurely-named file ("compile.bat"). This file is fully obfuscated, but what it does is basically to pull exploit DLLs from the attacker's server and install 'em. I think the fortunate p…

ahhh nice, it's been years since i've seen a obfuscated .bat!

very nice use of substring, but a bit too linear... with some input redirects and nested spaced variables it would have become more robust and unpredictable, but i suppose nowadays batch chiselers are rare.

edit: by the way in the article is missing a -useless- decoded line (n.4)

Re: Embedded Malware in Coa

#48

Post by inbx0 »

notpublic wrote: post #44
inbx0 wrote: post #34

Reminder that people should seriously consider disabling the install-scripts. Personal system-wide config: npm/yarn config set ignore-scripts true -g and add & commit a .npmrc/.yarnrc file with ignore-scripts true Yes, this will cause headaches in some (increasingly rare) cases where some package actually needs those scripts. You can fix this with custom install scripts that take care of running install for those spe…

You can find out which packages require postinstall scripts and then run them manually: $ grep postinstall node_modules/*/package.json node_modules/esbuild/package.json: "postinstall": "node install.js" $ cd node_modules/esbuild $ npm run postinstall

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'
    ...

Re: Embedded Malware in Coa

#49

Post by ricksunny »

My read of the headline was that this was malware in embedded hardware electronics systems, or describing some exploit / attack surface for same.

May I suggest that a clearer phrasing would be ‘Malware embedded in Coa’? Or is ‘embedded malware’ a somewhat confusing term-of-art in the cybersec community?

Re: Embedded Malware in Coa

#50

Post by d3nj4l »

strogonoff wrote: post #14
d3nj4l wrote: post #9

Earlier quoted context omitted.

This should be a top-level comment, if not a post in its own right - it explained the entirety of the situation way better than TFA.

That post doesn’t say much about `coa`, besides “new versions started appearing and builds started failing”. The bug report linked from GitHub advisory does a good job of describing the issue, though: https://github.com/veged/coa/issues/99

That's fair, but it describes the change in great detail, and makes it easier to figure out that the primary issue was only on Windows systems.
Post reply on HN