Live data from Hacker News

Obsidian plugin was abused to deploy a remote access trojan

cyber.netsecops.io

201–210 of 241 posts

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

#201
post #89
post #78

Earlier quoted context omitted.

I remember reading that page sometime pre-COVID, and being surprised at just how ridiculous it was. It started strong with “The Obsidian team takes security seriously”, but then almost everything else on the page led me to believe they didn’t actually take security very seriously. I agree with the claim of negligence. I think they were more than happy to reap the benefits of a thriving community plugin ecosystem, and…

I use only one plugin because I am aware of the security model (or lack thereof). I only use one because I read the source and am convinced it’s safe. It would be foolish to blindly install many plugins.

Agreed, but also they prominently feature that they support plugins. Currently it's the second paragraph on the home page: https://obsidian.md/

They're trying to get all the benefits while pushing the extremely-obvious-to-them downsides into subpages. Not hidden, but not shown along-side the feature. It's intentionally misleading for non-technical users.

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

#203
post #178

Earlier quoted context omitted.

Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.

https://learn.microsoft.com/en-us/windows/security/applicati...

Microsoft has refused to allow any kind of persistence of these sandboxes making them absolutely worthless. Such a waste of an otherwise good feature.

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

#204
post #128

Earlier quoted context omitted.

Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.

AppContainer (e.g. used in uwp or msix)

Can you configure that as a user for an unsafe program you want to run such as an online game? I think not.

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

#205

Earlier quoted context omitted.

Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.

Maybe it isn't built-in, but most Windows user I've worked with, including myself, have been using Sandboxie for probably two decades at this point, probably hard to find any Windows software that is more ubiquitous than Sandboxie in developer circles.

Sandboxie is essentially a giant pile of fragile hacks on top of a Windows API that does not want to be used this way. Does it seem like it works most of the time? Sure. Has it had bypasses? Also yes. I've used it in the past but I don't truly trust it.

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

#206

Earlier quoted context omitted.

Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.

Windows has had that feature for 9 years. https://learn.microsoft.com/en-us/defender-endpoint/controll...

This is implemented the wrong way around. Each program should only have access to its own folders by default, with it being possible to grant additional access. Also, I don't believe Endpoint stuff is included in the normal Windows license.

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

#207
post #196

Earlier quoted context omitted.

The insecurity is part of the benefit. Obsidian being so open, allowing easy customizing is what makes it great. They should add some more bells, whistles and guards to prevent sneaky social attacks, but they can't close Obsidian all together, or it would kill the app.

There's open, and then there's "full disk access, even outside the vault" open.

What do you propose? Even if they configure node's lowest level file APIs to block any access to paths outside the vault, plugins can still execute arbitrary shell commands who will have access to the entire OS.

And before you say it's useless and should be stopped too, well, that's a fine opinion! But then you lose plugins providing git integration, automated backups, document conversion using pandoc, etc. Many users might value that greatly.

A permission system for their plugins might be the only solution, annoying permission request popups and all.

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

#208

Earlier quoted context omitted.

What dispute? The parent comment says that Obsidian is not usable without plugins and it's simply nonsense. It would be very charitable to call this a "dispute." Could Obsidian handle plugin permission better? I guess so. But that doesn't mean the users have to use plugins. It's ultimately the user's choice. Blender has zero security guards over the addons besides the OS's and the ecosystem thrives . So does Minecraf…

> What dispute? The discussion about the plugin-system, and the people who need it to which degree. > The parent comment says that Obsidian is not usable without plugins and it's simply nonsense. Sure, fair. But the comment happened in the context of talking about the plugin-system, and parent comment seems on the side that for them obsidian is worthless without plugins. Saying that other people have no need for them…

I think if the wording had been something like "I, one person out of billions, personally find Obsidian to be unusable without plugins", there probably would have been no disagreement and this discussion would be moot.

The disagreement was because the actual claim made was far broader, and in that far broader context, opposite to reality. We can assume good faith and an honest mistake in wording, but we can also forgive respondents for reasonably taking the words at face value.

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

#209

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

Because no plugin is affected. This isn't a supply chain attack. The headline is deliberately obtuse. Here's the breakdown:

1. Plugins are stored inside your vault.

2. If you open a vault from an untrusted source, it could contain custom/malicious plugins that will run things on your computer.

3. Then end.

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

#210
post #62

Earlier quoted context omitted.

And tons won't be part of e.g. root, or dialout (to pick one I've had to deal with a lot lately), or many other more-privileged-than-default groups, yes. That's a permissions system working as intended. Besides. They said "all software on your machine". That is trivially false, to a significant degree.

I was pointing out that the claim that "literally a majority of all software on your computer" runs sandboxed is also trivially false, to a significant degree

A majority have more access controls than obsidian plugins, yes. I think that's fairly safe to say, given that new system installs often have hundreds of processes already running.

Sandboxing, at least in the sense of easily configurable access with default deny on most even somewhat sensitive things: agreed, sandboxing is fairly uncommon in general, definitely not a majority on most systems. When ignoring the elephant in the room: mobile OSes.

Post reply on HN