There's no reason to believe that [0] has anything to do with WASM, [1] and [2] are runtime implementation bugs, [3] is a vulnerability in a "weak" sandboxing library VM2 - it has nothing to do with WASM as such, and [4] is another implementation bug in an experimental WASI feature of that specific runtime which is gated behind a build flag.
> vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment.
> JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult.
> Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited?
(Different person here) I don't have data and I don't think I need it. You either have a process to push security-critical updates out very rapidly or you don't.
If you have that process then nothing changes for you because that cooldown won't be used in that context.
If you don't have that process then nothing changes for you because you weren't pushing out those time-sensitive patches to begin with. But now you won't get hit by drive-by supply chain attacks.
The vast majority of "high severity vulnerabilities" in your dependencies are just noise by the virtue of not being exploitable in the manner that they're used in your project.
Unsurprising, agents' solution to everything is writing more code. They'll happily reinvent the universe (a really crappy one).
Bug? More code. Unexpected behavior - read the docs? Couldn't find anything. Let's try another 1000 lines of workarounds. Still doesn't work? Write another 1000 lines to monkey-patch behavior. It sort of works now.
The actual solution is removing those 2000 lines and passing the correct argument on line 25 which is clearly documented. Most humans would never do that because we're too lazy but it's so easy to generate slop at an exponential rate and blow up the LOC metrics.
I think that in my career I have absolutely seen multiple times people making absolutely horrible architectural approaches where passing a parameter would suffice. Inventing and building basically whole universe instead of doing a bit of research.
With LLM coding I already have seen agent pointing out easier solutions because agent is not scared of or tired by reading existing code. Whereas most of developers want to write „their code” not read someone’s else’s code.
Malware running on your computer can engineer a situation where you would naturally press that without suspecting anything.
1. Malware logs you out of github.com
2. It waits for you to navigate to the login page
3. It initiates an SSH/signing operation requiring physical touch
4. You hit login on github.com, a 2nd FIDO operation is queued up
5. You press the yubikey button, confirming the SSH operation
6. "Nothing happens", so you press it again to log in
7. You're now logged in, and your SSH credentials have just been hijacked.
Or it could just inject itself into your shell profile, and do this the next time you ssh anywhere. You never really know what you're confirming so Yubikey's threat model implicitly depends on the host device being trustworthy.
This is why hardware wallets for crypto have a physical display to confirm the address and the amount before signing the transaction.
As long as you're fine with the types being semantic gibberish because all agents I've used take the lowest effort approach to make the error go away.
You probably have the same logical type duplicated in 3+ different places (at least partially), including inline casts using type literals like "maybeCat as { meow(): void }"
Do you update your dependencies and push to production every single day? Saturdays and sundays too?
What are the chances that your code is using a vulnerable dependency AND doing so in an exploitable manner AND the vulnerability being serious enough to warrant immediate attention? The likelihood of that is extremely low unless you're high-profile enough to have a team dedicated to this.
99.9% of vulnerabilities in your dependencies aren't actually exploitable in your project. Most exploitable vulnerabilities probably aren't that serious. And even if it's serious, it's unlikely that you would be targeted immediately.
On the other hand you have a constant stream of unreviewed dependency updates, each one having a small chance of containing malicious code.
The most pragmatic approach, IMO, is to set up alerts for high severity CVEs, cooldown of at least 24h, and only execute code in per-project sandboxes (VMs or containers).
1 day is short enough that it would practically never be a problem, regardless of severity. It's historically been long enough to discover the vast majority of these supply chain attacks, and alerting for high severity CVEs is something you should be doing anyway if you're worried about security.
A keyboard doesn't "do" the work. In other words, the more work you outsource to AI, the lower your value-add becomes, the easier your are to replace by someone doing the same thing for cheaper.
> but NPM makes it dangerous to merely open a project up in an IDE.
It does not. Opening a project in an IDE has always been dangerous because there are about a thousand language server and analysis tools that run in the background. This is why IDEs ask you whether you trust the contents of a repository.
An even if some automated background execution initiated by the IDE doesn't get you, running `npm run test` 15 seconds later will.
> since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.
Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly.
The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it obviously.
A lot of packages are pulled in to call minimal bits of the actual library. I obviously don't have any statistics on this but my instinct would say that for the average application only 5% of an average package is actually used.
So not running package installation scripts is a huge, massive problem.
It doesn't matter how much of the package you use. Here, you can use literally 0% of Koa and get pwned by one of its transitive dependencies (koa > cookies > keygrip > tsscmp) by simply importing the parent package:
mkdir demo && cd demo
npm install --save koa@3.2.0
echo 'console.log("--- pwned by a transitive dependency ---")' >> node_modules/tsscmp/lib/index.js
node -e "import 'koa'"
So what? Packages can just put their backdoors in some initialisation code that is always used.
It is possible that not running package installation scripts could improve security, but for that you need really good sandboxing/compartmentalisation of library code, e.g. with CHERI, WASI component model, or if all of your code must run in a secure context it probably helps.
But those situations are unfortunately rare in my experience.
Most of them? Ruby gems have hooks, Python has setup.py, deb, rpm have them too (relevant if you're installing from 3rd party sources). Elixir/Mix doesn't technically execute code on install, but your language server builds the dependencies as soon as you open the project, which can execute arbitrary code.
Either way it misses the point, nobody just fetches code and removing post-install scripts wouldn't change much because you're going to run `npm run something` 5 seconds after you run `npm install`.
------
[Re: 3] https://github.com/patriksimek/vm2
> vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment.
> JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult.
[Re: 4] https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-m...
reply