Live data from Hacker News

Obsidian plugin was abused to deploy a remote access trojan

cyber.netsecops.io

101–110 of 241 posts

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

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

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

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

#103
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…

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.

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

#104
post #94

Earlier quoted context omitted.

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…

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

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

#106
post #51

Earlier quoted context omitted.

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

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

#107
post #43

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

Releasing the source code to the clients would also address many of our concerns.

you’re basically hijacking this post. this is almost entirely irrelevant. CERTAINLY highly tangential.

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

#108
post #81

Earlier quoted context omitted.

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

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.

[flagged]
Post reply on HN