(Bug report) Scripts can overwrite files in application install dir

[maphew]

TriliumNext Version

0.90.7-beta

What operating system are you using?

Windows

What is your setup?

Local (no sync)

Operating System Version

win 11 pro (10.0.22631 N/A Build 22631)

Description

Scripts executed within Trilium have full write abilities to the Trilium application folder (on Windows, linux not tested).

Demonstration

Create a Code note of type JS Backend:

// export the current note and branch to zip file
api.exportSubtreeToZipFile(
   api.currentNote.id,
   'html', // or 'markdown'
   'trilium-export.zip')

Execute with ctrl-enter.

On my machine af ile is written to A:\apps\trilium-windows-x64\trilium-export.zip, which is my trilium application dir.

So if the zip filename were changed to, say, trilium-safe-mode.bat or resources.pak bad stuff happens. I've verified that doing so quietly overwrites existing files.

Not tested, but I presume creativity with other paths can overwrite files anywhere the trilium.exe executing user has write access to.

Mitigation

These are just ideas. I don't know what's best.

• Before executing any script, ensure the current dir is user or system temp, at very least not application dir
• disallow overwriting existing files
• Alter exportSubtreeToZipFile to only accept fully qualifed path
  • repeat for any other functions that write to disk

---

Allowing arbitrary code execution is always going to be a security problem, that's not going away, it's too useful, but some relatively small changes could make it safer.

Error logs

No response

[perfectra1n]

Yeah this is a slippery slope, and in my opinion why it's important to run it in a container. Zadam had originally stated that Trilium was meant to hold a trusted user's notes - and that things like XSS and the sort weren't an issue if someone wanted to RCE themselves.

Now might be a good time to rehash that discussion though.

[maphew]

Running in a container doesn't prevent footgunning one's own install, which is what was in the neighbourhood of doing when I learned this. :) I wrote a script to export note tree, it ran successfully but I couldn't find the file, until I looked in the application dir. So some level of protection could be added, even before starting to look at things like cross domain exploits and remote code execution. I think we could/should do that too, but would be a different set of issues and discussion.

[perfectra1n]

If you run it in a container, and "footgun" yourself (causing the container to crash), the underlying container runtime should restart the container (unless you don't have restart policy set to always) causing the "footgunned" files to come back 👀

And you also can't overwrite binaries (to then be malicious, in theory) on the host OS if you're using a container.

But yes, if you overwrite any key files in a mounted volume (e.g. document.db, config.ini) - that wouldn't be a good time and is a different story.

[perfectra1n]

Yeah it'll definitely be interesting to try and sandbox the JavaScript provided by the user, changing how user's scripts execute.