Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Obsidian plugin was abused to deploy a remote access trojan

cyber.netsecops.io

Post reply on HN
Print view View original

111–120 of 241 posts

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

#111

Post by wiether »

hresvelgr wrote: post #23

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.

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

#112

Post by jon-wood »

finghin wrote: post #104
coldtea wrote: post #94

Earlier quoted context omitted.

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

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.

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

#113

Post by eneveu »

coldtea wrote: post #94
enoch2090 wrote: post #87

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…

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.

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

#114

Post by fwn »

UqWBcuFx6NV4r wrote: post #108
fwn wrote: post #81

Earlier quoted context omitted.

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]

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

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

#115

Post by rithdmc »

Daedren wrote: post #93
hackermanai wrote: post #72

Earlier quoted context omitted.

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

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

#116

Post by graynk »

coldtea wrote: post #94
enoch2090 wrote: post #87

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…

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.

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

#117

Post by cassianoleal »

eneveu wrote: post #113
coldtea wrote: post #94

Earlier quoted context omitted.

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…

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

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

#118

Post by redsocksfan45 »

ibash wrote: post #44
kepano wrote: 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…

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.

[dead]

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

#119

Post by deafpolygon »

amipwndidunno wrote: post #110

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.

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

#120

Post by exceptione »

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.

Post reply on HN