Comment by jmyeet
8 hours ago
Maybe I'm a dinosaur in this regard but I don't like nor trust any of these desktop application that are really just Web technologies with an embedded browser eg Discord.
They're resource hogs and the attack surface is huge. You're basically betting that automatic code that's run won't find a vulnerability and escape the sandbox from an entire browser.
I have way more trust in Jetbrains IDEs and the JVM as a sandbox vs HTML/CSS/JS.
Still, I'm always impressed at the ingenuity of the people who come up with these attacks and the people who find them.
Won’t IDEA automatically index/execute some Gradle code when possible? As soon as you execute an arbitrary binary/script from the project directory, the isolation of the JVM doesn’t matter.
This particular vulnerability relied upon passing the require function to a scope to allow the loading and running of arbitrary code. This is what I tend to call a blacklist approach. You're saying in this sandbox certain features can't be used because they will allow escape.
The alternative is a whitelist approach. Instead of disallowing dangerous features you're enabling only the features you need.
So a build system like Gradle or Maven (same thing really) has a limited set of primitives it is allowing access to. It's not loading, say, the entire JVM and all the Java core libraries and then listing all those you can't use.
You see the difference? If nothing else, the blacklist approach is going to fail when the virtual machine (or whatever) adds a new API call upstream and it's added without intent to the sandbox by simply doing an update where nobody has thought to disable it.
Another way of looking at this is Gradle isn't being compiled into Java bytecode and run in the same environment as the IDE (sandboxed or otherwise). That is inherently riskier.
Same here, I only use VSCode because in some scenarios I have no choice, from regulated IT environments, or product SDKs with plugins only for it.
When I can avoid it, the better.
Yep. You’d think using web tech would make it really easy to sandbox any 3rd party JavaScript that gets run. But I suppose sandboxing is simply too inconvenient.
Because that isn't how it happens, the plugin model relies on external processes with OS IPC, most of them rely on basic process security model, and aren't even implemented in JavaScript due to performance.