Hacker News new | ask | show | jobs
by lozenge 1011 days ago
The yarn.lock includes checksums, if yarn is not checking checksums properly then that affects every project in Node.js, not just this one.

Malicious code with the correct checksum? VSCode team is not auto updating dependencies but I also doubt they are reviewing the source code of every package they update. I've never worked anywhere that does. So yeah, "gulp-vinyl-zip" (or any other package used at build time) could add some code that secretly triggers when run in the VSCode repository and makes some malicious source code changes. But, it's still going to be the same code in VSCode and VSCodium. Unless the attacker decides to use specific logic to target one or the other.
1 comments
danpalmer 1011 days ago
It's possible, and common, for NPM packages to download additional binaries at install and/or run time. These would not be included in the hashes, and are essentially untrusted, often hosted on random S3 buckets. I'd hope there are checks in the official project to ensure these aren't being used, but there aren't any checks in this project.
link
patrakov 1010 days ago
How would you write such a check?
link
lozenge 1010 days ago
My employer uses artifactory as a mirror of npm and one step of adding a package to the mirror is installing it on a VM/container with no network access. If the package has a "postinstall" script requiring internet access then it will fail. There's also code scanning that will find at least casual attacks like "download and run this crypto ransomware".

I think the idea MS has deployed this is over optimistic. Look at this with Google. https://giraffesecurity.dev/posts/google-remote-code-executi...

Also, it depends how determined your attacker is. If they write code to detect whether they're being installed in the vscode project, have access to commercially available security scanning tools to ensure they evade detection, etc...

link
benatkin 1010 days ago
Using socket.dev is one way!

As for writing such a check manually, you would just need to check "bin" in */package.json after installing everything, and verify each script.

Trusting a big company seems to be another suggestion I see in this thread too. I don't agree with that one.

link