Comment by slowmover
3 days ago
> The victim is prompted to enable the "Installed community plugins" synchronization feature.
Obsidian has the proper protections in place to prevent this type of attack, and the victims are being convinced to ignore them. This is just a successful social engineering event. I hate to see Obsidian dragged down by this headline, since this attack is not exploiting a vulnerability in it or its plugin system.
Ehm. No? https://obsidian.md/help/plugin-security#Plugin+capabilities
>Due to technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels. This means that plugins will inherit Obsidian's access levels. As a result, consider the following examples of what community plugins can do:
Obsidian has no protection at all. Installing a plugin gives it full access to your computer.
This was only a matter of time, and honestly I think it's inexcusably negligent that they shipped a plugin system like this at all since about 2010 (or arguably much earlier).
It does give full access but Obsidian does tell you that. Community plugins are not enabled by default, you have to enable them manually. Same happens with a shared vault: once you get it you still have to manually enable plugins. So far no one managed to sneak in a plugin completely unnoticed.
That's horse hockey. Obsidian is not a usable system without community plugins.
Folks will reply "but I use it every day without plugins".
That position disregards software usability as a formal discipline, along with decades of UX research and standards.
42 replies →
"Hey users: don't do insecure things. Here's a button to do cool insecure things!" is not a plugin security model.
3 replies →
A program one runs on one's computer can and should be able to do computer things. The alternative road you're advocating for ends in hardware attestation https://news.ycombinator.com/item?id=48086190
There are in-between models, such as:
* Android's permissions model where the user must approve specific potentially undesirable classes of actions (separate from the 24H delay, etc controversy)
* Optional sandboxing
I remember reading that page sometime pre-COVID, and being surprised at just how ridiculous it was. It started strong with “The Obsidian team takes security seriously”, but then almost everything else on the page led me to believe they didn’t actually take security very seriously.
I agree with the claim of negligence. I think they were more than happy to reap the benefits of a thriving community plugin ecosystem, and were hoping this page would provide enough CYA when security breaches inevitably occurred.
> TIP: If you're working with sensitive data and wish to install a community plugin, we recommend that you perform an independent security audit on the plugin before using it.
I wonder just how many plugins received a security audit.
I use only one plugin because I am aware of the security model (or lack thereof). I only use one because I read the source and am convinced it’s safe. It would be foolish to blindly install many plugins.
1 reply →
Obsidian seems like a perfect candidate for a WASM/WASI based plugin system that would properly sandbox plugin code.
For at least the vast majority, yes definitely. I'm fine with full bypasses existing (say a webgl thing, or web previews, custom VCS integration, there are tons of legitimate reasons to escape a sandbox), but they should be an abnormality with heavy warnings and proportionate community attention to watch for issues, not the only option.
I don't think they meant it this way, but I honestly consider unsafe official plugin systems to be negligent to the point of being actively malicious. By releasing one, if you ever become successful you have explicitly chosen to screw over an unknown number of your users to save yourself a relatively small amount of work in the short term. It might be single digit users, or it might be septuple digit users - is it really worth it?
(Unsafe unofficial plugins, like most games? Mildly unfortunate but I think that's fine. Though a healthy modding community around your stuff should be a VERY STRONG sign that you should introduce a safe version to protect your users, if it won't cause you to implode (it definitely can)).
Has WASM/WASI DOM-access? When I last read about the architecture, there was a strict separation between WASM, Javascript and the app, but also a movement to allow UI-customization from WASM-space. Many Obsidian-plugins are adding heavy UI-changes, so without that, it would be kinda pointless.
1 reply →
Seems like the same risks of downloading plugins/packages for various text editors.
> Community plugins can access files on your computer. Community plugins can connect to internet. Community plugins can install additional programs.
That's what make obsidian plugins useful. It it's just for having themes , there is no need for them
Right, I'm a heavy Obsidian user myself, and love it.
I think the value of this disclosure is more in spreading awareness about plugins, and demonstrating the vector. Where less sophisticated users may think, "Oh, this is just a collection of markdown files. I don't need to be too worried about malicious code."