Obsidian plugin was abused to deploy a remote access trojan (opens in new tab)

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.

I don't know when Obsidian gathered the hate I'm seeing here, but 'bad plugins' is a failure mode of most everything that has plugins.

Personally it feels similar to being mad at Windows if you were to install an exe someone emailed you and it turned out to be a virus.

You can install bad chrome plugins, bad wow addons, basically anything that's purpose is to run user code can be used to run bad code.

Personally I'm glad the _note taking app_ prioritized allowing for custom plugins over pushing back features so they could spend an extra year locking down user plugins. They can put some additional effort in but running unknown code will always be a risk.

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.

This is a misleading headline. It makes it seem like another supply chain attack where some good plug-in was taken over and used to deliver malware. Thats not the case here. Victims are invited to collaborate on a synced vault which comes preloaded with a non official plug-in that delivers the rat. Very very different story

> 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.

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?

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".

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.

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.

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.

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.

This is becoming a bit of an epidemic. Not every attack or exploit (and especially not a social engineering one) needs a name out of Metal Gear or a website.

Why the hell doesn't the article say WHICH plugins were affected so users can know if they were likely affected?

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.

Whoever taught LLMs to design webpages to look like that? I find myself telling agents to specifically not design like that.

It's so a distracting and unfocused

A very relevant article: "On the security of plugins" (in notes app)

https://standardnotes.com/blog/on-the-security-of-plugins

This is why I NEVER install any obsidian plugins - EVER. Obsidian itself is good. Obsidian plugins = security nightmare.

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.

Seems like a nice place to plug my Mac app that syncs your obsidian tasks to Reminders.app: https://turquoisehexagon.co.uk/remindersync (for me the only thing obsidian is missing on a fresh install).

It’s sandboxed; can’t make network connections and can only read the directory you select. I’m surprised Apple haven’t added OS level functionality to block network connections / folder access for non sandboxed apps, similar to running an un-notarised binary.

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.

Love Obsidian but I've previously commented about the security model for plugins here: https://news.ycombinator.com/item?id=45308131. TLDR: your entire vault (and possibly filesystem) is exposed to every single plugin you install.

I really do think Obsidian needs 2 things to have any reasonable security:

1. It needs to be a lot more batteries-included. A user shouldn't need a plugin for basic functionality.

2. It needs a granular permission system, where each plugin should have to declare and prompt you to allow or reject specific permissions, just like on iOS and Android. The system should enforce that a plugin cannot bypass this.

Hopefully this improves workflow for installing plugins offline. It's not bad already but it's not as good as the connected experience.

You say Trojan.

I say shiny horse statue.

I use the plugin for Git, and the one for tasks. Hope those are safe!

https://plugin.observer would come in handy for this.

Obsidian sounds like a nightmare security wise in general.

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.

What is this vibe-coded site? Why does it reiterate the same point 20 time? What are the actual plugins that I need to be on alert for? Chop chop, get to it.

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.

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.