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

61–70 of 241 posts

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

#61

Post by eviks »

wasabi991011 wrote: post #56
kid64 wrote: post #9

Earlier quoted context omitted.

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.

If you want to use a niche, academic definition of "usable", that's fine but you better be ready to explain yourself. Because in general, "usable" means "people use it". Which they do for Obsidian without community plugins without issues.

To make an actual counter, you need numbers. If only a tiny niche of users use it without community plugins, then yes, it's unusable (in a practical definition of the term)

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

#62

Post by Groxx »

ImPostingOnHN wrote: post #59
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.

> That covers probably literally a majority of all software on your computer If you're running GNU/Linux, chances are you'll have hundreds, if not thousands, of pieces of software that run totally unsandboxed. Yes, a very small minority of applications are unfortunately primarily distributed via flatpak or snap, and the distributors don't care about the user experience, so it's error-ridden and problem-ridden, but ch…

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.

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

#63

Post by stingraycharles »

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.

These types of problems usually only get fixed when it’s too late.

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

#64

Post by stingraycharles »

eviks wrote: post #60

What are the reasons behind the fact that almost all of these plugin systems are so poorly engineered? Is it too much work (ie, there are no good plugin development frameworks that already enable proper isolation/permission capabilities) or "simply" a widespread lack of knowledge of what is needed, so devs learn only after their own system has been abused? Both? Something else?

You’ll need to define the security framework and building blocks that all plugins may need, which takes time to design, implement, verify and maintain.

Much easier to just skip that part.

So yes, it’s too much work (in the sense that you need to have a security-focused leadership that understands that this is a lot of work but the right thing to do).

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

#65

Post by Groxx »

AlienRobot wrote: post #25
kid64 wrote: post #9

Earlier quoted context omitted.

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.

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.

Krita: that is a decision by Krita(/GIMP) and not anything inherent in "plugins" or "python" - it could be a bubblewrap/firejail contained process, for example (other OSes have similar-ish options but there's always something, e.g. don't use cpython). They have chosen to continue to put their users at risk by not doing anything at all like that.

There are of course complications, costs, and downsides associated with doing that. It might not be worth it currently, or performance costs might be too high, or the community might be overwhelmingly using abandoned plugins that won't be updated, etc. It's still a decision to remain complacent until forced by attacks though, it's well beyond common knowledge that these things happen so you can't really call it ignorance.

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

#67

Post by kepano »

dsp_person wrote: post #58
kepano wrote: post #54

Earlier quoted context omitted.

The recommended way to do this is via artifact attestation: https://docs.github.com/en/actions/how-tos/secure-your-work/...

Thanks that's interesting. The docs are aimed at developers, but I'm curious about the use case for the end user. So would a user have to do some kind of `gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY ...`? (assuming the plugin dev provides an sbom?)

In the near term artifact attestation will be visible to users in the directory, and part of the overall scorecard of a plugin.

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

#68

Post by brusselsprout »

I hope I'm speaking as a minority but when I first started using Obsidian the Youtube videos I watched encourage the usage of community plugins, even with these warnings I would enable the community plugins. You may very well have good actors that eventually turn bad for these plugins and users won't know.

Maybe I just also have a higher personal risk appetite, but even as a dev and knowing these risks I would have enabled the community plugin option. Again, hope I'm just the minority here and not most user behaviour.

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

#69

Post by 3eb7988a1663 »

badcryptobitch wrote: post #36

My worse fear has materialized. This is why I've never used an external Obsidian plugin and only my own plugins. It was only a matter of time before some malicious code ended up in one.

Brother, we are vindicated! There are indeed many cool bits and blobs out there, but I am already trusting one entity to secure my private notes, no way I am taking a pinky-promise from extension XYZ to behave.

(I actually use LogSeq, but same idea applies).

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

#70

Post by [deleted] »

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…

[deleted]
Post reply on HN