Live data from Hacker News

Obsidian plugin was abused to deploy a remote access trojan

cyber.netsecops.io

31–40 of 241 posts

Re: Obsidian plugin was abused to deploy a remote access trojan

#31
post #9

Earlier quoted context omitted.

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.

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"

Re: Obsidian plugin was abused to deploy a remote access trojan

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

Re: Obsidian plugin was abused to deploy a remote access trojan

#34
post #11

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…

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

Re: Obsidian plugin was abused to deploy a remote access trojan

#35
post #30

Earlier quoted context omitted.

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.

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

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.

Re: Obsidian plugin was abused to deploy a remote access trojan

#37

Earlier quoted context omitted.

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 comm…

The same is true for all software on your machine.

Re: Obsidian plugin was abused to deploy a remote access trojan

#38
post #33

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 a…

[deleted]

Re: Obsidian plugin was abused to deploy a remote access trojan

#40
post #8

Earlier quoted context omitted.

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.

"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
Post reply on HN