A long time ago I figured that "nasty Obsidian plugins" were not a matter of if, but when.
So I did the (imho) only sensible thing, and run Obsidian in a sandbox (bwrap). By doing so, I also made sure it runs in a separate networking namespace. For now, I disallow any internet access.
The amount of rage I see here is a bit strange, the whole attraction of Obsidian is that you can turn it into a Swiss army knife (that can hurt you too ofc).
@kepano: you would greatly help me if you could force plugin authors to list the urls they want to access inside the manifest, then let the user per url decide if they want to enable it. I still see some stupid plugin authors download their assets from a CDN or a vague website, from deeply buried in their code. Making url depencies explicit helps firewall automation at a first step. Maybe you could revoke direct network access from plugins, but i am not too knowledgeable about Electron.
Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it.
That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I haven't seen any reports of users being affected by this attack.
lol we told you plugins were insecure years ago. I distinctly remember getting flamed in your discord because I said that they had full disk access. Too little too late.
In 2026, applications, third or even first party, don't need to have full-disk access, and are not given either. They see a jailroot environment. I give full disk access to the terminal app, and a handful of others. 90% of them, nope.
At least that's the case in macOS, I'm pretty sure Windows can do that too. Linux of course has had such capability since forever, but I guess most distros you need to manually take care of it.
This hardening is enabled by default with Gatekeeper. That includes Homebrew apps, unless you disable it.
When an app tries to access something outside of its sandbox, you get a notification asking to approve or deny. Full Disk Access I think needs to be explicitly given on System Settings (Privacy & Security -> Full Disk Access).
I've never tried to do this or similar in Windows (obviously easy in unix-like environments) but I'm going to bet it's far more trouble than it's worth for 99% of users
On macOS at least those 99% of users are probably installing from the App Store, where apps are sandboxed by default and need to explicitly ask for access to paths outside that sandbox. Even when not installed from the App Store a permission dialogue is popped if an application tries to read from sensitive paths like your photo library.
Lol it's a social engineering attack. What are you talking about. Don't run programs you don't trust, especially when being asked to do so by strangers on the line.
Get real, kepano. You’re overestimating the consciousness of most casual users. Having godmode, RCE-capable plug-ins behind few safety warnings that most people will happily ignore to get shit done is not good engineering. I understand the constraints. In your shoes I would at minimum make a different version of the app in which you could allow these plug-ins and not put them under trivial banners within the canonical version of the app. You say you have banners, but these sit in the natural flow of the user journey, the options are clearly available and these banners are merely to exempt you from any liability, not to protect the users.
Chrome gutted extension capabilities for safety and now it is so useless, politically unwanted extensions have "lite" versions and every big project and their dog ship their own chromium browser.
I use Obsidian because it does not treat me like a child. They can add more nags and banners for normies, but the capabilities should remain.
> Tags and banners do not work. Completely understandable that someone as dismissive and seemingly isolated as you wouldn’t understand that.
One can reduce every tool to a toy and justify it with some hand-wavy security slop, but removing capabilities destroys use cases.
The ability to control your tools is good. You should be able to run anything on your devices. Therefore, those who propose the toyification of tools should carry the burden of justifying the change.
The same infantilization of users currently happens with Signal, where high-level decision makers are asked by strangers to share their deepest secrets. Since these strangers introduce themselves very nicely, users start blurting out their secrets. ... now everyone is pretending this is a Signal problem. It is not. The world is not a kindergarten and people have agency.
A good compromise is to set a safe mode as the default and include an option that lets users confirm they know what they are doing. Obsidian already does this. Given that, I do not understand why anyone would demand to make the entire tool worse.
I wonder: What level of user effort would make you comfortable with users exiting safe modes? Would you want users to be able to run software with full permissions at all?
LMAO. That won't happen in a million years. They are bending over backwards not to give proper file access on iOS so they can sell subscriptions. Do you think they would do such a crazy thing? I bet you my life savings it won't happen.
Is this like a popup? which most people actively accept without blinking
I think plugin/extensions should be a bit harder to run by default. I get the user friction from extra hurdles before using their plugins etc., but I don't think there is an actually safe way to execute arbitrary code, unaudited, without sandboxing, or other restrictions.
The pop-ups and "social engineering" in question are things that any users in HN likely already accepted, which is to enable community plugins.
These community plugins are the backbone of Obsidian and where a lot of the meat is behind its fame come from.
There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.
As someone who doesn't use shared vaults - would the warning popup, 'to enable the "Installed community plugins" synchronization feature', not be on a per shared vault basis? Is trusting a single shared vault for plugin sync going to mean I sync my plugins for every shared vault?
IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.
Since we have your attention here, let me go on an unrelated note and ask whether you could look into Noteplan's workflow and see if you can add some of the required functionalities to enable replication of its workflow (https://help.noteplan.co/article/160-weekly-planning)?
Plugins like Tasks do offer a Query functionality that allows me to list e.g. weekly tasks on my daily template, replicating most of Noteplan's workflow, except Noteplan relies on being able to easily link those tasks into daily template by drag and dropping them, which internally assigns a unique but hidden by default ID in ^129abz notation (https://help.noteplan.co/article/138-synced-blocks). The latter is already supported by Obsidian, it's just not as "clean" and, AFAIK, impossible to get done when drag and dropping.
I really like Obsidian. I use it every day and I don't use any community plugins because the permissions aren't up to snuff. I hope for a day where a plugin defines what it will need and that gets presented to me as a user.
I have to imagine the Obsidian team is going to respond seriously to this and I look forward to seeing what they do. They have my full confidence. I'm surprised the system was initially designed as it is without those better permissions and sandboxing, though.
I started using it too when I got sick of using VS Code to look at md. Glad I never had the need to install any plug-ins! Very poor form on their part from what I can tell.
> 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.
>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:
Community plugins can access files on your computer.
Community plugins can connect to internet.
Community plugins can install additional programs.
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.
To make an actual counter, you need numbers. If only a tiny niche of users use it without community plugins, then yes, it's unusable (in a practical definition of the term)
I rely on Advanced URI, which opens certain functionality up to external apps. I use Raycast and with Cmd+Space, it lets me open vaults or daily notes.
And Obsidian_to_Anki, but that's probably just me because I have no clue how to use Anki otherwise.
All I want is a top-notch Markdown editor with a mobile app and trustworthy sync, and that's what Obsidian gives me. And if ever Obsidian goes away or is enshittified, I'll still have a perfectly good folder of Markdown documents that I can take elsewhere.
Seriously though, I agree with your sentiment that community plugin security can and needs to be improved, but how does someone saying they use it every day "disregard software usability as a formal discipline, along with decades of UX research and standards"
The attack here requires not just enabling community plugins, but also syncing the attacker's vault to your computer, and also separately enabling the synchronization of the attacker's plugins with yours.
Obsidian Plugins are still incredibly vulnerable. A compromised plugin will essentially take over your machine. There's no sandboxing of any kind. It's even more insecure than browser extensions (that could steal your auth tokens, but at least don't have unfettered access to your filesystem).
This is really unfortunate. I love Obsidian and am a paid subscriber for many years, but the community plugins needs a security overhaul asap, before someone gets hurt.
Not even slightly. Browser extensions are a trivial counter-example, as are all flatpacks, and anything restricted by user/group. That covers probably literally a majority of all software on your computer, because people have been voluntarily restricting their software to protect you from their potential accidents for decades.
In practise, Flatpak packages have many more permissions than you might expect, and the sandbox feature gives a false sense of security. For example, the Obsidian Flatpak package [0] is given all of the following abilities without explicit permission from the user (the user has to know where to look to find out about them):
- Home folder read/write access
- System folder media
- System folder mnt
- Microphone access and audio playback
- And more...
The Obsidian snap [1] is installed with the --classic flag, which also grants access to the whole home directory, but at least you have to consciously specify the --classic flag to grant this permission.
> That covers probably literally a majority of all software on your computer
If you're running GNU/Linux, chances are you'll have hundreds, if not thousands, of pieces of software that run totally unsandboxed.
Yes, a very small minority of applications are unfortunately primarily distributed via flatpak or snap, and the distributors don't care about the user experience, so it's error-ridden and problem-ridden, but chances are you can get a "normal computer program" version of it unencumbered by such grossness.
And tons won't be part of e.g. root, or dialout (to pick one I've had to deal with a lot lately), or many other more-privileged-than-default groups, yes. That's a permissions system working as intended.
Besides. They said "all software on your machine". That is trivially false, to a significant degree.
I think that's especially important to point out because it reminded me of a blog post by Obsidian that also was discussed here[1], where they talked about reducing supply chain risk by not relying on dependencies, but people quickly pointed out that this is only possible because users depend so heavily on extensions. Just look at that top comment and here we are now.
This combination of software relying on third parties without security seems to be untenable. Personally I've gotten rid of just about as many extensions as I can anywhere and switched to batteries included software.
Krita: that is a decision by Krita(/GIMP) and not anything inherent in "plugins" or "python" - it could be a bubblewrap/firejail contained process, for example (other OSes have similar-ish options but there's always something, e.g. don't use cpython). They have chosen to continue to put their users at risk by not doing anything at all like that.
There are of course complications, costs, and downsides associated with doing that. It might not be worth it currently, or performance costs might be too high, or the community might be overwhelmingly using abandoned plugins that won't be updated, etc. It's still a decision to remain complacent until forced by attacks though, it's well beyond common knowledge that these things happen so you can't really call it ignorance.
Software engineers at large would benefit from playing World of Warcraft, and seeing the ongoing fight between Blizzard and add-on authors.
WoW's whole UI is built in the same Lua environment as add-ons, and Blizzard has implemented some interesting restrictions (like the taint system[0]) to prevent add-ons from completely automating gameplay.
If you happen to use the WoW example in the future, the wiki efforts moved from the fandom one to wiki.gg[0], as voted by maintainers and contributors in late 2023[1].
Thanks! I've been meaning to read up on taint systems, looks interesting :)
I'm somewhat convinced that taint-influenced capabilities is a good future model to pursue. Computers are fast, I'm fairly confident that it chould be done at whole-computer scale and still be reasonable... though probably not with a million electron apps. Which is likely a good thing in aggregate (I say as a fan of web tech and the very compelling features such things offer. Great for minor or PoC, not for major pieces of software).
World of Warcraft is one of the most popular MMO's ever made.
You simply can't expect every software that wants a plugin system to have the same security practices as the most used software in the world.
In fact, there are many reasons why you might want a plugin to have full filesystem and internet access, such as batch processing or simply adding things directly from webpages. Sandboxing this will just make plugins less useful.
In the end it's a problem of trust. You're installing software from untrustworthy developers because you trust the name of the application those plugins are associated with.
You could fix the problem in Obsidian, but the same problem will happen in other software. Some of which simply can't justify bothering with sandboxing plugins. This is just the way plugins are.
> You simply can't expect every software that wants a plugin system to have the same security practices as the most used software in the world.
I'm not saying that I think they should, or that I expect them to. I'm saying that it's one particular implementation of sandboxing that has a bunch of interesting properties, and that makes it worth studying.
I'm not sure I agree or understand where you're coming from.
Side-loaded Android apps are still bound by all the same permission restrictions as any app installed by the Play Store. The only difference is Google didn't review it (for what little good that does) and that I didn't get the app from Google.
If I side-load a camera app, it still has to ask for camera privileges the same way any Play store app does.
Is there something in your message I missed about how it relates to this article or is this just being uninformed about side-loading?
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.
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)).
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
* Android's permissions model where the user must approve specific potentially undesirable classes of actions (separate from the 24H delay, etc controversy)
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."
I run Obsidian with restricted capabilities: no network access, and no filesystem access outside its own directory. I only enable network access when updating plugins/themes.
Same way I run any other application that could potentially execute untrusted code.
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?
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.
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).
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.
Even being social engineering, the design of the plugin system allowing this means the platform is completely unusable as a sharing tool. It's good to know but to me this is not "I need to remember to have these settings correct to use a shared Obsidian vault", this for is instead "never accept a shared Obsidian vault, demand a plaintext export".
My worse fear has materialized.
This is why I've never used an external Obsidian plugin and only my own plugins.
It was only a matter of time before some malicious code ended up in one.
Brother, we are vindicated! There are indeed many cool bits and blobs out there, but I am already trusting one entity to secure my private notes, no way I am taking a pinky-promise from extension XYZ to behave.
I hope I'm speaking as a minority but when I first started using Obsidian the Youtube videos I watched encourage the usage of community plugins, even with these warnings I would enable the community plugins. You may very well have good actors that eventually turn bad for these plugins and users won't know.
Maybe I just also have a higher personal risk appetite, but even as a dev and knowing these risks I would have enabled the community plugin option. Again, hope I'm just the minority here and not most user behaviour.
One thing that bugged me when I made a community plugin was that you have to attach non-git-controlled files to the release (e.g. main.js).
To check if any community plugin is safe, it seems like you'd have to not only review the code on github, but also analyze the github release files to be sure nothing malicious packed in there.
Maybe I'm misunderstanding something about the process, I'd appreciate if anyone could confirm or explain otherwise.
Am I the only one who thinks Obsidian is perfect without plugins? Half the reason I switched to it from Anytype was that it was rather spartan in its offerings. If they announced tomorrow they would ban plugins, I would not care.
I wouldn't say "perfect", but to me it's clear that adding plugins could only make it worse, even without considering the security issues.
What I want from Obsidian is something that "just works". Adding third-party plugin would break this immediately since the plugins can either be straight up buggy, create conflicts with each other or simply become incompatible with new Obsidian releases.
And what I've seen from the community, with people having dozens of plugins installed, is giving me nightmares.
I can see why some would feel the appeal of plugins, and adding two or three can be fine, as long as you do your due diligence.
Otherwise it's straight shooting you in the foot.
That’s basically how I’m using it since I got wary about how the community plugins were being vetted. Core plugins and settings cover a lot. There’s one or two things I miss, but not enough to fork and review them myself so it’s clearly not essential.
I'm also switching back to Obsidian after a few-year stint on Anytype, and the Notebook Navigator plugin is the only one I have installed. This is (I assume) a UI-only plugin, which shouldn't need access to external network or processes, so a quite good candidate for sandboxed plugins.
You are safe. The way this hack works is that someone online would contact you, share a obsidian valut with you, you open the vault, you download & install a plugin the hacker tells you to install to open the vault.
It's all described in the article if you would like to read it.
The obsidian vault is to already have the chosen plugin pre-selected and is part of the social engineering effort, that's not the main problem.
The issue is that this could happen to anyone who just searches the malicious plugin's name and installs it. Worse if it's a popular one that gets compromised.
Obsidian does not have auto update for community plugins. The steps for updating them right now is checking for updates and then updating all or individually.
A bad update to one of the popular plugins could compromise lot of systems.
I think it’s fundamentally wrong to base your plugin architecture on running user code in the same space as the application. The proper way is to evaluate plugin scripts in an interpreter running in the application, where you expose functionality through functions and state exposed to the script runtime. This means you can A) sandbox everything and B) check for things like permissions or even request permissions at runtime. It’s harder if you use a language like JavaScript for the application since you essentially have a runtime inside a runtime, but it’s possible to run something like Lua inside JS. Since I use an actually good language like Rust I have many good options for scripting, like Rhai. Lua is also a good option. Go also has multiple options including a couple good Lua libraries. These libraries tend to have performance comparable to Python which is more than enough for most plugins in most apps.
Yet another reason to not install anything third-party made. Favor batteries, built-in functionality and reject “Unix philosophy” or whatever bullshit people use to ship incomplete software under guise of.
This is just the first detected and reported instance, in all likelyhood such attacks have been happening for some time. When will the fanatic userbsse finally admit that using Obsidian in any enterprise setting is just plain malpractice?
It takes 5 minutes in their Discord channel to see the founders are D&D nerds, not competent engineers. It was never meant for serious work.
> the founders are D&D nerds, not competent engineers
The two are not mutually exclusive. What would you trust more than a nerd? A jock? A spod? An MBA?
Any evidence of other examples if bad engineering you can point to, or are your thoughts on the pluggin system and throwing shade at random groups of people all you've got?
[FYI: I know little of obsidian other than planning to look into it at some point as people I know use and like it. I stepped into this set of comments in case there was something useful I should be passing on to those people]
The attack relies on social engineering to get the victim to disable protections and could just as easily have happened with a plugin for any code editor.
Anyway,
What I like about obsidian is that it can handle a truly huge amount of notes without slowing down, and the notes are just markdown files on disk, so there's no lock in.
I have used evernote, ms one note and zoho notebook before, and had issues with all of them.
That isn't a response to my post, it is a bit of information already present in the thread that isn't relevant to my question followed by a positive review. This suggests that a shill brigade has been attracted to these comments. I suggest you don't do that, it isn't a good look.
well there was this previous issue in the crypto community where it turned out someone was not a competent engineer and should have stuck to their online exchange for magic: the gathering
A long time ago I figured that "nasty Obsidian plugins" were not a matter of if, but when.
So I did the (imho) only sensible thing, and run Obsidian in a sandbox (bwrap). By doing so, I also made sure it runs in a separate networking namespace. For now, I disallow any internet access.
The amount of rage I see here is a bit strange, the whole attraction of Obsidian is that you can turn it into a Swiss army knife (that can hurt you too ofc).
@kepano: you would greatly help me if you could force plugin authors to list the urls they want to access inside the manifest, then let the user per url decide if they want to enable it. I still see some stupid plugin authors download their assets from a CDN or a vague website, from deeply buried in their code. Making url depencies explicit helps firewall automation at a first step. Maybe you could revoke direct network access from plugins, but i am not too knowledgeable about Electron.
Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it.
That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I haven't seen any reports of users being affected by this attack.
lol we told you plugins were insecure years ago. I distinctly remember getting flamed in your discord because I said that they had full disk access. Too little too late.
These types of problems usually only get fixed when it’s too late.
"Sorry we got caught" reactiveness.
You better delete all third-party applications for they are having full disk access.
Hello, 2010s called.
In 2026, applications, third or even first party, don't need to have full-disk access, and are not given either. They see a jailroot environment. I give full disk access to the terminal app, and a handful of others. 90% of them, nope.
At least that's the case in macOS, I'm pretty sure Windows can do that too. Linux of course has had such capability since forever, but I guess most distros you need to manually take care of it.
Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.
Interesting. Do I get this sandboxing out of the box when I install apps with Homebrew? Or do I need to do something specific?
Would love to enable this for all apps, and add exceptions for the ones that need more access.
I installed Lulu and BlockBlock recently, and want to do more to harden my Mac.
This hardening is enabled by default with Gatekeeper. That includes Homebrew apps, unless you disable it.
When an app tries to access something outside of its sandbox, you get a notification asking to approve or deny. Full Disk Access I think needs to be explicitly given on System Settings (Privacy & Security -> Full Disk Access).
In the scenario where you take care of it yourself the rogue plugin would not be an issue either.
I have no idea how to do that in Windows though.
I've never tried to do this or similar in Windows (obviously easy in unix-like environments) but I'm going to bet it's far more trouble than it's worth for 99% of users
On macOS at least those 99% of users are probably installing from the App Store, where apps are sandboxed by default and need to explicitly ask for access to paths outside that sandbox. Even when not installed from the App Store a permission dialogue is popped if an application tries to read from sensitive paths like your photo library.
Lol it's a social engineering attack. What are you talking about. Don't run programs you don't trust, especially when being asked to do so by strangers on the line.
Get real, kepano. You’re overestimating the consciousness of most casual users. Having godmode, RCE-capable plug-ins behind few safety warnings that most people will happily ignore to get shit done is not good engineering. I understand the constraints. In your shoes I would at minimum make a different version of the app in which you could allow these plug-ins and not put them under trivial banners within the canonical version of the app. You say you have banners, but these sit in the natural flow of the user journey, the options are clearly available and these banners are merely to exempt you from any liability, not to protect the users.
Chrome gutted extension capabilities for safety and now it is so useless, politically unwanted extensions have "lite" versions and every big project and their dog ship their own chromium browser.
I use Obsidian because it does not treat me like a child. They can add more nags and banners for normies, but the capabilities should remain.
Tags and banners do not work. Completely understandable that someone as dismissive and seemingly isolated as you wouldn’t understand that.
> Tags and banners do not work. Completely understandable that someone as dismissive and seemingly isolated as you wouldn’t understand that.
One can reduce every tool to a toy and justify it with some hand-wavy security slop, but removing capabilities destroys use cases.
The ability to control your tools is good. You should be able to run anything on your devices. Therefore, those who propose the toyification of tools should carry the burden of justifying the change.
The same infantilization of users currently happens with Signal, where high-level decision makers are asked by strangers to share their deepest secrets. Since these strangers introduce themselves very nicely, users start blurting out their secrets. ... now everyone is pretending this is a Signal problem. It is not. The world is not a kindergarten and people have agency.
A good compromise is to set a safe mode as the default and include an option that lets users confirm they know what they are doing. Obsidian already does this. Given that, I do not understand why anyone would demand to make the entire tool worse.
I wonder: What level of user effort would make you comfortable with users exiting safe modes? Would you want users to be able to run software with full permissions at all?
Releasing the source code to the clients would also address many of our concerns.
How would that make a difference for plugin security? Almost all plugins are already open source.
If you mean for the security of the app without plugins you can currently inspect the app's code in app.js and review third-party audits:
https://obsidian.md/security
you’re basically hijacking this post. this is almost entirely irrelevant. CERTAINLY highly tangential.
LMAO. That won't happen in a million years. They are bending over backwards not to give proper file access on iOS so they can sell subscriptions. Do you think they would do such a crazy thing? I bet you my life savings it won't happen.
> actively reject multiple safety warnings
Is this like a popup? which most people actively accept without blinking
I think plugin/extensions should be a bit harder to run by default. I get the user friction from extra hurdles before using their plugins etc., but I don't think there is an actually safe way to execute arbitrary code, unaudited, without sandboxing, or other restrictions.
The pop-ups and "social engineering" in question are things that any users in HN likely already accepted, which is to enable community plugins. These community plugins are the backbone of Obsidian and where a lot of the meat is behind its fame come from.
There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.
As someone who doesn't use shared vaults - would the warning popup, 'to enable the "Installed community plugins" synchronization feature', not be on a per shared vault basis? Is trusting a single shared vault for plugin sync going to mean I sync my plugins for every shared vault?
IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.
This. Make it like a vim mode, input “I know what I’m doing” or even require some basic fizz buzz.
Your product rules. Thanks.
Since we have your attention here, let me go on an unrelated note and ask whether you could look into Noteplan's workflow and see if you can add some of the required functionalities to enable replication of its workflow (https://help.noteplan.co/article/160-weekly-planning)?
Plugins like Tasks do offer a Query functionality that allows me to list e.g. weekly tasks on my daily template, replicating most of Noteplan's workflow, except Noteplan relies on being able to easily link those tasks into daily template by drag and dropping them, which internally assigns a unique but hidden by default ID in ^129abz notation (https://help.noteplan.co/article/138-synced-blocks). The latter is already supported by Obsidian, it's just not as "clean" and, AFAIK, impossible to get done when drag and dropping.
I really like Obsidian. I use it every day and I don't use any community plugins because the permissions aren't up to snuff. I hope for a day where a plugin defines what it will need and that gets presented to me as a user.
I have to imagine the Obsidian team is going to respond seriously to this and I look forward to seeing what they do. They have my full confidence. I'm surprised the system was initially designed as it is without those better permissions and sandboxing, though.
I started using it too when I got sick of using VS Code to look at md. Glad I never had the need to install any plug-ins! Very poor form on their part from what I can tell.
> 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.
If you want to use a niche, academic definition of "usable", that's fine but you better be ready to explain yourself.
Because in general, "usable" means "people use it". Which they do for Obsidian without community plugins without issues.
To make an actual counter, you need numbers. If only a tiny niche of users use it without community plugins, then yes, it's unusable (in a practical definition of the term)
As one of those people that uses Obsidian without plugins, what plugins do you consider essential?
I rely on Advanced URI, which opens certain functionality up to external apps. I use Raycast and with Cmd+Space, it lets me open vaults or daily notes. And Obsidian_to_Anki, but that's probably just me because I have no clue how to use Anki otherwise.
Me too.
All I want is a top-notch Markdown editor with a mobile app and trustworthy sync, and that's what Obsidian gives me. And if ever Obsidian goes away or is enshittified, I'll still have a perfectly good folder of Markdown documents that I can take elsewhere.
Same here, zero plugins for me.
But I use it every day without plugins.
Seriously though, I agree with your sentiment that community plugin security can and needs to be improved, but how does someone saying they use it every day "disregard software usability as a formal discipline, along with decades of UX research and standards"
The attack here requires not just enabling community plugins, but also syncing the attacker's vault to your computer, and also separately enabling the synchronization of the attacker's plugins with yours.
Yes, in this specific case.
Obsidian Plugins are still incredibly vulnerable. A compromised plugin will essentially take over your machine. There's no sandboxing of any kind. It's even more insecure than browser extensions (that could steal your auth tokens, but at least don't have unfettered access to your filesystem).
This is really unfortunate. I love Obsidian and am a paid subscriber for many years, but the community plugins needs a security overhaul asap, before someone gets hurt.
The same is true for all software on your machine.
Not even slightly. Browser extensions are a trivial counter-example, as are all flatpacks, and anything restricted by user/group. That covers probably literally a majority of all software on your computer, because people have been voluntarily restricting their software to protect you from their potential accidents for decades.
In practise, Flatpak packages have many more permissions than you might expect, and the sandbox feature gives a false sense of security. For example, the Obsidian Flatpak package [0] is given all of the following abilities without explicit permission from the user (the user has to know where to look to find out about them):
- Home folder read/write access
- System folder media
- System folder mnt
- Microphone access and audio playback
- And more...
The Obsidian snap [1] is installed with the --classic flag, which also grants access to the whole home directory, but at least you have to consciously specify the --classic flag to grant this permission.
[0] - https://flathub.org/en/apps/md.obsidian.Obsidian
[1] - https://snapcraft.io/obsidian
> That covers probably literally a majority of all software on your computer
If you're running GNU/Linux, chances are you'll have hundreds, if not thousands, of pieces of software that run totally unsandboxed.
Yes, a very small minority of applications are unfortunately primarily distributed via flatpak or snap, and the distributors don't care about the user experience, so it's error-ridden and problem-ridden, but chances are you can get a "normal computer program" version of it unencumbered by such grossness.
And tons won't be part of e.g. root, or dialout (to pick one I've had to deal with a lot lately), or many other more-privileged-than-default groups, yes. That's a permissions system working as intended.
Besides. They said "all software on your machine". That is trivially false, to a significant degree.
Yeah, but these attacks are possible without any of that complexity.
I think that's especially important to point out because it reminded me of a blog post by Obsidian that also was discussed here[1], where they talked about reducing supply chain risk by not relying on dependencies, but people quickly pointed out that this is only possible because users depend so heavily on extensions. Just look at that top comment and here we are now.
This combination of software relying on third parties without security seems to be untenable. Personally I've gotten rid of just about as many extensions as I can anywhere and switched to batteries included software.
[1]https://news.ycombinator.com/item?id=45307242
The real problem is people believing "plugins" are not full software.
If you install a dozen mini-apps from random developers you never heard about, you can't complain if one is malware.
Krita also has a plugin system based on Python. Any "plugin" has the same level of access as running a python script.
Personally I blame operating systems for not providing a way to isolate how programs interact with user files.
Krita: that is a decision by Krita(/GIMP) and not anything inherent in "plugins" or "python" - it could be a bubblewrap/firejail contained process, for example (other OSes have similar-ish options but there's always something, e.g. don't use cpython). They have chosen to continue to put their users at risk by not doing anything at all like that.
There are of course complications, costs, and downsides associated with doing that. It might not be worth it currently, or performance costs might be too high, or the community might be overwhelmingly using abandoned plugins that won't be updated, etc. It's still a decision to remain complacent until forced by attacks though, it's well beyond common knowledge that these things happen so you can't really call it ignorance.
Software engineers at large would benefit from playing World of Warcraft, and seeing the ongoing fight between Blizzard and add-on authors.
WoW's whole UI is built in the same Lua environment as add-ons, and Blizzard has implemented some interesting restrictions (like the taint system[0]) to prevent add-ons from completely automating gameplay.
0. https://wowpedia.fandom.com/wiki/Secure_Execution_and_Tainti...
If you happen to use the WoW example in the future, the wiki efforts moved from the fandom one to wiki.gg[0], as voted by maintainers and contributors in late 2023[1].
0. https://warcraft.wiki.gg/wiki/Secure_Execution_and_Tainting
1. https://wowpedia.fandom.com/wiki/Wowpedia:About_the_wiki#Bac...
Thanks! I've been meaning to read up on taint systems, looks interesting :)
I'm somewhat convinced that taint-influenced capabilities is a good future model to pursue. Computers are fast, I'm fairly confident that it chould be done at whole-computer scale and still be reasonable... though probably not with a million electron apps. Which is likely a good thing in aggregate (I say as a fan of web tech and the very compelling features such things offer. Great for minor or PoC, not for major pieces of software).
World of Warcraft is one of the most popular MMO's ever made.
You simply can't expect every software that wants a plugin system to have the same security practices as the most used software in the world.
In fact, there are many reasons why you might want a plugin to have full filesystem and internet access, such as batch processing or simply adding things directly from webpages. Sandboxing this will just make plugins less useful.
In the end it's a problem of trust. You're installing software from untrustworthy developers because you trust the name of the application those plugins are associated with.
You could fix the problem in Obsidian, but the same problem will happen in other software. Some of which simply can't justify bothering with sandboxing plugins. This is just the way plugins are.
> You simply can't expect every software that wants a plugin system to have the same security practices as the most used software in the world.
I'm not saying that I think they should, or that I expect them to. I'm saying that it's one particular implementation of sandboxing that has a bunch of interesting properties, and that makes it worth studying.
"Hey users: don't do insecure things. Here's a button to do cool insecure things!" is not a plugin security model.
Meanwhile that is exactly what a lot of people here want for Android with side loaded apps
I'm not sure I agree or understand where you're coming from. Side-loaded Android apps are still bound by all the same permission restrictions as any app installed by the Play Store. The only difference is Google didn't review it (for what little good that does) and that I didn't get the app from Google.
If I side-load a camera app, it still has to ask for camera privileges the same way any Play store app does.
Is there something in your message I missed about how it relates to this article or is this just being uninformed about side-loading?
Sideloading bypasses nothing at all except Google's thumbs-up, Android's permission system doesn't work that way.
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.
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)).
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
Seems like the same risks of downloading plugins/packages for various text editors.
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."
I run Obsidian with restricted capabilities: no network access, and no filesystem access outside its own directory. I only enable network access when updating plugins/themes.
Same way I run any other application that could potentially execute untrusted code.
Could you share how you're sandboxing it?
Why the hell doesn't the article say WHICH plugins were affected so users can know if they were likely affected?
It does.
> It enables malicious versions of legitimate Obsidian plugins ('Shell Commands' and 'Hider') that are present in the shared vault.
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?
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.
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).
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.
Why does a plugin system immediately imply sandboxing?
Even being social engineering, the design of the plugin system allowing this means the platform is completely unusable as a sharing tool. It's good to know but to me this is not "I need to remember to have these settings correct to use a shared Obsidian vault", this for is instead "never accept a shared Obsidian vault, demand a plaintext export".
Reading the content the problem does not start with a plugin in Obisidian store but rather with a malicious vault they lure you to open.
My worse fear has materialized. This is why I've never used an external Obsidian plugin and only my own plugins. It was only a matter of time before some malicious code ended up in one.
Brother, we are vindicated! There are indeed many cool bits and blobs out there, but I am already trusting one entity to secure my private notes, no way I am taking a pinky-promise from extension XYZ to behave.
(I actually use LogSeq, but same idea applies).
I hope I'm speaking as a minority but when I first started using Obsidian the Youtube videos I watched encourage the usage of community plugins, even with these warnings I would enable the community plugins. You may very well have good actors that eventually turn bad for these plugins and users won't know.
Maybe I just also have a higher personal risk appetite, but even as a dev and knowing these risks I would have enabled the community plugin option. Again, hope I'm just the minority here and not most user behaviour.
One thing that bugged me when I made a community plugin was that you have to attach non-git-controlled files to the release (e.g. main.js).
To check if any community plugin is safe, it seems like you'd have to not only review the code on github, but also analyze the github release files to be sure nothing malicious packed in there.
Maybe I'm misunderstanding something about the process, I'd appreciate if anyone could confirm or explain otherwise.
The recommended way to do this is via artifact attestation:
https://docs.github.com/en/actions/how-tos/secure-your-work/...
Thanks that's interesting. The docs are aimed at developers, but I'm curious about the use case for the end user.
So would a user have to do some kind of `gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY ...`? (assuming the plugin dev provides an sbom?)
In the near term artifact attestation will be visible to users in the directory, and part of the overall scorecard of a plugin.
Hopefully this improves workflow for installing plugins offline. It's not bad already but it's not as good as the connected experience.
Am I the only one who thinks Obsidian is perfect without plugins? Half the reason I switched to it from Anytype was that it was rather spartan in its offerings. If they announced tomorrow they would ban plugins, I would not care.
I wouldn't say "perfect", but to me it's clear that adding plugins could only make it worse, even without considering the security issues.
What I want from Obsidian is something that "just works". Adding third-party plugin would break this immediately since the plugins can either be straight up buggy, create conflicts with each other or simply become incompatible with new Obsidian releases.
And what I've seen from the community, with people having dozens of plugins installed, is giving me nightmares.
I can see why some would feel the appeal of plugins, and adding two or three can be fine, as long as you do your due diligence. Otherwise it's straight shooting you in the foot.
This. I only use official Obsidian plugins. Security + not depending on OSS maintainer are the main reasons.
That’s basically how I’m using it since I got wary about how the community plugins were being vetted. Core plugins and settings cover a lot. There’s one or two things I miss, but not enough to fork and review them myself so it’s clearly not essential.
I'm also switching back to Obsidian after a few-year stint on Anytype, and the Notebook Navigator plugin is the only one I have installed. This is (I assume) a UI-only plugin, which shouldn't need access to external network or processes, so a quite good candidate for sandboxed plugins.
You say Trojan.
I say shiny horse statue.
Obsidian sounds like a nightmare security wise in general.
How is it any worse than say, VSCode in this regard?
I use the plugin for Git, and the one for tasks. Hope those are safe!
You are safe. The way this hack works is that someone online would contact you, share a obsidian valut with you, you open the vault, you download & install a plugin the hacker tells you to install to open the vault. It's all described in the article if you would like to read it.
The obsidian vault is to already have the chosen plugin pre-selected and is part of the social engineering effort, that's not the main problem.
The issue is that this could happen to anyone who just searches the malicious plugin's name and installs it. Worse if it's a popular one that gets compromised.
Obsidian does not have auto update for community plugins. The steps for updating them right now is checking for updates and then updating all or individually.
A bad update to one of the popular plugins could compromise lot of systems.
I think it’s fundamentally wrong to base your plugin architecture on running user code in the same space as the application. The proper way is to evaluate plugin scripts in an interpreter running in the application, where you expose functionality through functions and state exposed to the script runtime. This means you can A) sandbox everything and B) check for things like permissions or even request permissions at runtime. It’s harder if you use a language like JavaScript for the application since you essentially have a runtime inside a runtime, but it’s possible to run something like Lua inside JS. Since I use an actually good language like Rust I have many good options for scripting, like Rhai. Lua is also a good option. Go also has multiple options including a couple good Lua libraries. These libraries tend to have performance comparable to Python which is more than enough for most plugins in most apps.
Yet another reason to not install anything third-party made. Favor batteries, built-in functionality and reject “Unix philosophy” or whatever bullshit people use to ship incomplete software under guise of.
This is just the first detected and reported instance, in all likelyhood such attacks have been happening for some time. When will the fanatic userbsse finally admit that using Obsidian in any enterprise setting is just plain malpractice?
It takes 5 minutes in their Discord channel to see the founders are D&D nerds, not competent engineers. It was never meant for serious work.
> the founders are D&D nerds, not competent engineers
The two are not mutually exclusive. What would you trust more than a nerd? A jock? A spod? An MBA?
Any evidence of other examples if bad engineering you can point to, or are your thoughts on the pluggin system and throwing shade at random groups of people all you've got?
[FYI: I know little of obsidian other than planning to look into it at some point as people I know use and like it. I stepped into this set of comments in case there was something useful I should be passing on to those people]
The attack relies on social engineering to get the victim to disable protections and could just as easily have happened with a plugin for any code editor.
Anyway, What I like about obsidian is that it can handle a truly huge amount of notes without slowing down, and the notes are just markdown files on disk, so there's no lock in. I have used evernote, ms one note and zoho notebook before, and had issues with all of them.
That isn't a response to my post, it is a bit of information already present in the thread that isn't relevant to my question followed by a positive review. This suggests that a shill brigade has been attracted to these comments. I suggest you don't do that, it isn't a good look.
well there was this previous issue in the crypto community where it turned out someone was not a competent engineer and should have stuck to their online exchange for magic: the gathering
> It takes 5 minutes in their Discord channel to see the founders are D&D nerds, not competent engineers.
I know absolutely nothing about Obsidian but I'd expect quite a few competent engineers to also be D&D nerds no!?
Are you saying the two are mutually exclusive?
No I'm not. But I'd encourage you to visit and see for yourself why these outcomes are completely predictable.
For uninitiated, why?
What software do you use that would be immune to a scenario where you disable all protections to take some action?
One whose protections can’t be disabled.
So locked up platform where vendor owns your ass and fucks it the way they want to, à la Chrome.
So i assume you dont use an android device, github, etc? Everything is vulnerable to social engineering.