Arbitrary Code Execution via JavaScript Queries (CVE-2021-42057)

[tivey-scwx]

Describe the bug

I discovered a way to craft malicious markdown files that will cause the obsidian-dataview plugin to execute arbitrary commands on users’ systems. This is due to the unsafe use of eval within the evalInContext function located in src/api/inline-api.ts.

This has been assigned a CVE of CVE-2021-42057 for tracking.

To Reproduce

The following proof-of-concept can be used to display a file on a user’s system by executing the cat command:

```dataviewjs
require("child_process").exec("cat /etc/passwd",(_0,stdout,_1) => dv.span(stdout));""
```

A malicious user could leverage this vulnerability to execute arbitrary code on other users' systems by getting them to open an untrusted markdown file. This is especially dangerous in environments where users share vaults.

Expected behavior

DataviewJS should not make an unsafe call to eval using user supplied input.

Additional Context

Shortly after we privately disclosed this issue, @blacksmithgu promptly changed the default behavior of Dataview to no longer enable JavaScript Queries by default (see release 0.4.13). This helps protect new dataview users and provides a way for existing dataview users to mitigate this issue by disabling the JavaScript Query functionality when opening untrusted markdown.

@blacksmithgu is currently working on additional solutions and provided permission for us to open a public issue here for tracking.

[KjellConnelly]

Holy crap lol. Didn't realize it was that easy to run pure node functions. Could definitely be deadly.

[blacksmithgu]

DataviewJS blocks run with the same permissions that Dataview-the-plugin has, which apparently is much more than I initially expected - you can access node functions and various other libraries which plugins probably shouldn't have access too!

I am looking at improved sandboxing for DataviewJS blocks via the vm2 library, which will incur a performance overhead and block all external require calls (except through possibly a whitelisted list of modules / other user scripts). Another alternative would be for Obsidian to prevent plugins from using these scary APIs in the first place.

[blacksmithgu]

As for risk, the main takeaway is: be careful with what DataviewJS code you copy-paste from the internet into your vault. Don't run minified code or code that looks like gibberish, and make sure any shared code has been vetted by others (or you understand it yourself).

The main risk is through requiring node packages or making suspicious HTTP calls (through the Obsidian API) to URLs you don't recognized.

[kurtharriger]

From my perspective js execution is a significant feature that I don't want to see removed.

I do not agree that arbitration execution of dataview queries within trusted markdown code is a security vulnerability.

Downloading a bash script or any from the internet is not in itself harmful as it wont do anything until you execute it. And you should only execute code from trusted sources.

The question then becomes do I trust the markdown files in my vault.

Yes, I wrote them and if I find a snippet of obsidian markdown online containing dataviewjs I am certainly going to review it before copying it into my vault.

However, it is not generally expected that markdown files contain executable code and thus I fully agree that it should be disabled by default.

The user has already acknowledged that enabling plugins allows arbitrary code execution and starts with plugins disabled.

The plugin also requires enabling js explicitly.

Could more be done? perhaps. It might be a good idea to create a .dataview/trusted file with list of markdown files. If dataview detects js in a file not in this list it could prompt the user.

But I personally don't want to be prompted every time I generate a new markdown file from my daily notes template.

Enabling this feature does require the user to be mindful of the code he adds to his vault but that in itself does not make it a bug.

I also do not want the js to be "sandboxed" in fact I want to call http endpoints to import tasks from jira and execute a shell script to pull in my google calendar.

I could potentially make these into plugins, but I love the ability to use dataviewjs to prototype these things.

[KjellConnelly]

I agree with @kurtharriger - arbitrary code should not be protected. The only caviat I would say is that if you did want to address this issue, it should be in the README.md. Something basically saying,

Warning! As with all community Obsidian plugins, this plugin uses third party code. Due to the nature of this plugin, you as the user of the plugin must be aware of the new level of potential arbitrary code being run with dataviewjs. Be careful to understand the code you run, as code run is not sandboxed. This means that if you run malicious code (hypothetically by copying/pasting), not only could your vault be compromised, but any data on your computer may be as well.

[blacksmithgu]

@kurtharriger @KjellConnelly I agree with both of your points. To be clear, I am absolutely not removing JS functionality (I use it for everything personally), and I am also trying to avoid annoying security popups since people will just always press "Yes" on them anyway by the time they reach them (if you don't trust the code, you wouldn't copy it into your vault in the first place!).

The sandboxing will be toggleable with a "I know what I'm doing"-type setting that turns it off; it will still allow AJAX and full use of Obsidian/Dataview APIs, it just blocks node library requires() by default.

The README notice is a good idea - I will add that as a disclaimer in the README.

[KjellConnelly]

@blacksmithgu Great idea with just blocking requires. I personally hate how difficult it is to deal with permissions sometimes. It can get quite convoluted. And require() is basically the tip of the iceberg when it comes to node. So beginners won't have too much trouble understanding how to use node vs much more.

By the way, just to let you know, developers can access many node features directly from window.app within obsidian. For instance, fs is one module I use without require. I don't know if it's a full port or a wrapper or what, but I do use it to generate non .md files.