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

51–60 of 241 posts

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

#51

Post by Groxx »

Ferret7446 wrote: post #37
guiambros wrote: post #24

Earlier quoted context omitted.

Yes, in this specific case . Obsidian Plugins are still incredibly vulnerable. A compromised plugin will essentially take over your machine. There's no sandboxing of any kind. It's even more insecure than browser extensions (that could steal your auth tokens, but at least don't have unfettered access to your filesystem). This is really unfortunate. I love Obsidian and am a paid subscriber for many years, but the comm…

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.

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

#52

Post by Groxx »

Ferret7446 wrote: post #40
Groxx wrote: post #8

Earlier quoted context omitted.

"Hey users: don't do insecure things. Here's a button to do cool insecure things!" is not a plugin security model.

Meanwhile that is exactly what a lot of people here want for Android with side loaded apps

Sideloading bypasses nothing at all except Google's thumbs-up, Android's permission system doesn't work that way.

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

#53

Post by dsp_person »

One thing that bugged me when I made a community plugin was that you have to attach non-git-controlled files to the release (e.g. main.js).

To check if any community plugin is safe, it seems like you'd have to not only review the code on github, but also analyze the github release files to be sure nothing malicious packed in there.

Maybe I'm misunderstanding something about the process, I'd appreciate if anyone could confirm or explain otherwise.

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

#54

Post by kepano »

dsp_person wrote: post #53

One thing that bugged me when I made a community plugin was that you have to attach non-git-controlled files to the release (e.g. main.js). To check if any community plugin is safe, it seems like you'd have to not only review the code on github, but also analyze the github release files to be sure nothing malicious packed in there. Maybe I'm misunderstanding something about the process, I'd appreciate if anyone could…

The recommended way to do this is via artifact attestation:

https://docs.github.com/en/actions/how-tos/secure-your-work/...

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

#55

Post by Groxx »

pdpi wrote: post #30
AlienRobot wrote: post #25

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

Thanks! I've been meaning to read up on taint systems, looks interesting :)

I'm somewhat convinced that taint-influenced capabilities is a good future model to pursue. Computers are fast, I'm fairly confident that it chould be done at whole-computer scale and still be reasonable... though probably not with a million electron apps. Which is likely a good thing in aggregate (I say as a fan of web tech and the very compelling features such things offer. Great for minor or PoC, not for major pieces of software).

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

#56

Post by wasabi991011 »

kid64 wrote: post #9
pointlessone wrote: post #7

Earlier quoted context omitted.

It does give full access but Obsidian does tell you that. Community plugins are not enabled by default, you have to enable them manually. Same happens with a shared vault: once you get it you still have to manually enable plugins. So far no one managed to sneak in a plugin completely unnoticed.

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.

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

#57

Post by coffeefirst »

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.

That’s basically how I’m using it since I got wary about how the community plugins were being vetted. Core plugins and settings cover a lot. There’s one or two things I miss, but not enough to fork and review them myself so it’s clearly not essential.

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

#58

Post by dsp_person »

kepano wrote: post #54
dsp_person wrote: post #53

One thing that bugged me when I made a community plugin was that you have to attach non-git-controlled files to the release (e.g. main.js). To check if any community plugin is safe, it seems like you'd have to not only review the code on github, but also analyze the github release files to be sure nothing malicious packed in there. Maybe I'm misunderstanding something about the process, I'd appreciate if anyone could…

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

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

#59

Post by ImPostingOnHN »

Groxx wrote: post #51
Ferret7446 wrote: post #37

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.

> 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 chances are you can get a "normal computer program" version of it unencumbered by such grossness.

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

#60

Post by eviks »

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?
Post reply on HN