Obsidian plugin was abused to deploy a remote access trojan

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

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

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.

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.

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.

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

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

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

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

Obsidian sounds like a nightmare security wise in general.

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.

You say Trojan.

I say shiny horse statue.

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 use the plugin for Git, and the one for tasks. Hope those are safe!

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.

[dead]

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.