Comment by eviks
3 days ago
What are the reasons behind the fact that almost all of these plugin systems are so poorly engineered? Is it too much work (ie, there are no good plugin development frameworks that already enable proper isolation/permission capabilities) or "simply" a widespread lack of knowledge of what is needed, so devs learn only after their own system has been abused? Both? Something else?
At the core, there is the tradeoff between ability and security. You can give the users power and enable them doing fancy shit, or you can make it secure, stripping any meaningful ability. Usually, people prefer ability over security.
The other problem is that security is hard, and just giving generic access and adding some basic guards is simple.
The first trade-off is not precisely stated, you can do "both" with user choice. In this case it would be: no plugin has "all filesystem access" unless user explicitly approves it, and that approval steers the user to a very narrow "plugin folder only" path by the way UI is done. Think this is "secure by default"? You don't undermine any ability here because most plugins don't need any filesystem access, so you get extra security "for free" for most of the users and with only some friction (but still not removing the ability altogether) for the rest.
You’ll need to define the security framework and building blocks that all plugins may need, which takes time to design, implement, verify and maintain.
Much easier to just skip that part.
So yes, it’s too much work (in the sense that you need to have a security-focused leadership that understands that this is a lot of work but the right thing to do).
Web stack plus lack of resources to architect the proper interfaces is my guess. These are software written in high level js frameworks, thus using poor dataflow patterns by default, mostly just following what is actually possible instead of employing intentional design, which would require going down some levels of abstraction and maintaining a custom fork of said frameworks. So they probably just architect plug-ins like you would instantiate a library passing a subset of the context the app uses. Basically the simplest workable thing possible. Although the disclosed hack does not mention any particular “vulnerability”. Plug-ins in obsidian are always in god mode, and the alleged hackers just tricked people in using them. Funny how an RCE waiting to happen behind a few popups is ultimately blamed on users. Shame on the developers.
"Worse is better" remains relevant as ever.
https://www.jwz.org/doc/worse-is-better.html
Why does a plugin system immediately imply sandboxing?
Because a box is an intuitive way to limit the blast radius of arbitrary code? But the wasn't a requirement, I'd be fine with sandbox-free secure plugin systems
There are tons and tons of successful plugin systems out there that do not have such ridiculous requirements. I have thousands of VSTs installed and have never been RAT'ed. What happened to practicing internet hygiene?
At some point we need to acknowledge the problem is cultural, and address accordingly. I realize that the business objective for many is to make computing as brainless as possible but we need to be pushing back on that.
Instead we have forums full of really smart people demanding a nanny state. Yuck -- what a sad and pathetic state of affairs.
1 reply →
even chrome browser plugins have security issues similar to this case. there are billions of dollars and many smart developers working on it. It's similar to building an app store inside your app. For the Apple app store, they reduce malicious apps by being very strict who/what people can publish and it's behind a paywall.