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

231–240 of 241 posts

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

#231

Post by wiseowise »

kepano wrote: post #165
gejose wrote: post #129

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

> More batteries-included Can I ask, what basic functionality is Obsidian missing in 2026? (I work on the app)

Better task management, todo lists, reminders, powerful macros/templates.

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

#232

Post by dspillett »

flashman wrote: post #34
dspillett wrote: post #17

Earlier quoted context omitted.

> 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

A more mature response would be to mention the case you are talking about, perhaps linking to further details, rather than repeating the attack on a hobby that many share.

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

#233

Post by brazukadev »

ApolloFortyNine wrote: post #197

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…

There is no architectural limitation that makes it impossible for a plugin to not have full filesystem access.

The fact that creating a good plugin system is difficult does not give them a free pass to not implement a good one, it is a for profit company that has a considerable revenue.

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

#234

Post by jon-wood »

embedding-shape wrote: post #147
jon-wood wrote: post #112

Earlier quoted context omitted.

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.

Does that help in this case though? I think the worry is that a rogue Obsidian plugin does bad stuff with your Obsidian vault, not just do stuff to the rest of the computer. But that vault/those notes live in the same sandbox as the (rogue) 3rd party plugin, which doesn't help with that, they really need to be isolated away from the notes themselves.

In this case, no, not really because the plugin is running within the same sandbox. I was addressing the more general point in the grandparent post.

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

#235

Post by deafpolygon »

kepano wrote: post #169
deafpolygon wrote: post #166

Earlier quoted context omitted.

What’s misleading? "Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT” It’s novel (new), an abuse of Obsidian, specifically targeting a group of people.. and the RAT is embedded in the vault.

The headline on HN is different: "Obsidian plugin was abused to deploy a remote access trojan". It's not a plugin that was abused, but the ability for shared vaults to contain plugins.

Isn’t that nearly the same thing? It depends on the presence of a particular plugin which was abused to run remote commands.

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

#236

Post by kepano »

deafpolygon wrote: post #235
kepano wrote: post #169

Earlier quoted context omitted.

The headline on HN is different: "Obsidian plugin was abused to deploy a remote access trojan". It's not a plugin that was abused, but the ability for shared vaults to contain plugins.

Isn’t that nearly the same thing? It depends on the presence of a particular plugin which was abused to run remote commands.

No. The attack does not depend on the presence of a specific plugin. The ones listed in the article are just the ones that were used in the POC. Any plugin could be modified by the attacker if the user trusts the attacker and accepts 1. the vault, 2. the shared plugins, 3. disables restricted mode.

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

#237

Post by kepano »

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…

An update:

https://obsidian.md/blog/future-of-plugins/

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

#238

Post by Groxx »

Flimm wrote: post #106
Groxx wrote: post #51

Earlier quoted context omitted.

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…

fwiw blocking access to anything except my notes folder (and denying internet, among other things) is my very first step when installing Obsidian. Flatseal makes that quite simple.

Flatpak could of course be significantly better... but it's still a massive step in a better direction.

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

#239

Post by Groxx »

PurpleRamen wrote: post #151
Paul-E wrote: post #18

Earlier quoted context omitted.

Obsidian seems like a perfect candidate for a WASM/WASI based plugin system that would properly sandbox plugin code.

Has WASM/WASI DOM-access? When I last read about the architecture, there was a strict separation between WASM, Javascript and the app, but also a movement to allow UI-customization from WASM-space. Many Obsidian-plugins are adding heavy UI-changes, so without that, it would be kinda pointless.

Not generally / as many would hope, but that's partly because both WASM and WASI are not targeting being a full javascript-in-browser replacement - they're lower level, larger APIs are built on top, not defined by them. It's fairly easy to build an unsafe and unstable DOM access layer (a little bit of eval or string key accessers), but the web changes rapidly and isn't a stable target - exposing that in a stricter environment is tricky, and no one approach is likely to solve all needs.

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

#240

Post by exceptione »

jedimastert wrote: post #144
exceptione wrote: post #120

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 (tha…

> 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 Serious question: do you think it is actually obvious and technically accessable to everyday people to have the thought "I should run this in a sandbox" and do it? Like no th…

  > Serious question: do you think it is actually obvious and technically accessable to everyday people to have the thought "I should run this in a sandbox" and do it?
I meant the HN crowd ofc. I assume the non-technical obsidian user would not be present here.

You have a point though that non-technical people are screwed, but they have always been. Their whole lives and biometrics rest on Google and Apple servers anayways, while a good part of their identity is being traded by non-scrupulous commercial predators under the veil of advertising purposes. They are so beyond f*cked that I did not include their concerns wrt Obsidian plugins.

Post reply on HN